Для игры существует проект DFHack, занимающийся реверс-инжинирингом структур данных игры и позволяющий создавать плагины и скрипты на C++, Lua или Ruby.
Я же являюсь автором приложения и сопутствующего серверного кода, полностью реализующего пользовательский интерфейс игры на устройствах под управлением iOS. То есть пользователь ставит оригинальную игру, плагин и приложение, и может играть удалённо с мобильного устройства со всеми удобствами.
Сервер можно установить как у себя дома, так и арендовать у одного из облачных провайдеров. Так и родилась идея этого исследования — во-первых, узнать, какой из облачных сервисов лучше подходит и может быть рекомендован пользователям в первую очередь, и во-вторых, собственно сравнить производительность серверов, используя что-то отличное от веб-серверов и специальных утилит.
Для тестирования была использована версия Dwarf Fortress / DFHack 0.43.03-r1. У меня имеется публичный образ для Docker, включающий саму игру и минимальную версию DFHack (а так же собственно серверный код для удаленной игры, но в данном случае он не используется). Был написан скрипт на Lua, запускающий тесты и отсылающий результаты на веб-сервер. Также для автоматизации был использован следующий скрипт, указываемый в user-data при конфигурации серверов. То есть требовалось просто создать сервер, подождать, пока придут результаты и удалить его.
#!/bin/bash fallocate -l 4G /swp ; chmod 600 /swp ; mkswap /swp ; swapon /swp ; echo '/swp none swap sw 0 0' >>/etc/fstab apt-get update apt-get install -fy docker.io apt install unzip wget https://github.com/mifki/dfremote-cloud-benchmark/raw/master/benchmark.lua wget http://mifki.com/a/t/gloveloved.zip unzip gloveloved.zip -d save/ docker run --name=df -dt -v $PWD/save:/df_linux/data/save -v $PWD/benchmark.lua:/df_linux/hack/scripts/benchmark.lua mifki/dfremote sleep 5 docker exec df /df_linux/dfhack-run benchmark df
Тестировались следующие провайдеры: Digital Ocean, Amazon Lightsail, Amazon EC2, Vultr, Linode, Google Compute Engine, и Macbook Pro Late 2013 2Ghz Core i7.
Если облачный сервис поддерживает создание сервера с Docker в один клик, то использовалась эта возможность, если нет — то выбиралась версия Ubuntu 16.04. Таким образом, только у Vultr была использована не Ubuntu, а CentOS 7. Для серверов с больше, чем 2гб памяти, своп-файл не использовался. Для Google Compute Engine micro и small выбирался SSD диск.
Были выбраны наиболее дешевые варианты серверов, во-первых, потому что они более интересны тем, кто собирается использовать их для игры, а во-вторых, потому что Dwarf Fortress всё равно использует для симуляции только одно ядро процессора и (в указанной версии) является 32-битным приложением.
Тесты
Процесс игры в Dwarf Fortress состоит из двух частей — генерации мира и начальной истории, при которой можно указать размер мира и длину истории (и другие параметры), и собственно игрового процесса. Последовательно, без перезапуска игры, выполнялись следующие тесты:
- Генерация мира очень маленького (smaller) размера с очень длинной (very long) историей.
- Генерация мира большого (large) размера с короткой (short) историей.
- Игровой процесс. Использовался один из “групповых” (когда много человек играют по очереди) сэйвов — glovedloved (Anethadefíni, 254). Выбор не так важен, покуда в нем достаточно большая крепость, и ничего, чтобы автоматически остановило игру, не происходит за время теста, который длился 20 внутриигровых дней.
Последний тест наиболее важен, во-первых, потому что это собственно игровой процесс, ради которого всё и происходит, а во-вторых, он менее подвержен влиянию случайностей, чем генерация мира (при которой случайным образом генерируются цивилизации, поселения, ландшафт, события и так далее).
Результаты
Вот график. Время выполнения в секундах, соответственно, меньше — лучше. Цены за месяц в долларах США.
Сразу виден неестественный разброс в результатах первого теста, не знаю точно, с чем это связано. Полагаю, отчасти с кэшированием, отчасти с низкой производительностью только что созданного сервера по каким-то причинам. Поэтому результаты отсортированы по последнему тесту, который, как отмечалось, наиболее важный. Второй тест тоже в целом соотносится с результатами третьего.
Не считая ожидаемого первого места у сервера EC2 c4.large, относящегося к оптимизированному для производительности типу C4, Amazon Lightsail оказался быстрее всех, что, учитывая цену, довольно приятная неожиданность. За ним практически с таким же результатом следует однопроцессорный сервер от Google и ноутбук. Далее хорош оказался до этого мне неизвестный Vultr, Linode, от которого я ожидал большего. Приз зрительских симпатий получает Digital Ocean — медленнее, но наиболее простой и быстрый в использовании. Довольно дорогие сервера EC2 m3.medium на удивление медленные, а самые дешевые сервера GCE совсем плохие даже с SSD дисками, результата тестирования сервера размера micro я не дождался.
Отдельно надо сказать о EC2 инстансах типа T2. Их особенностью является то, что при простое сервер получает процессорные кредиты (до определенного лимита), которые расходуются под нагрузкой. Расходуя кредиты, сервер работает с полной производительностью, когда они заканчиваются — производительность падает до 20%. С одной стороны, это очень хорошо подходит для наших целей — люди, особенно с мобильного устройства, не играют непрерывно весь день, плюс симуляция в игре останавливается, когда человек что-то делает в меню и т.п., поэтому это хороший вариант получить высокую производительность за небольшие деньги. С другой стороны, это “ненастоящая” производительность, поэтому я не включил инстансы этого типа в тестирование, дабы никого не путать. По опыту, пока есть кредиты, они довольно быстрые, когда они кончаются — очень медленные.
На этом всё.
Источник