[Из песочницы] Использование Dwarf Fortress для тестирования производительности облачных серверов

Dwarf Fortress — легендарная игра, детально симулирующая фэнтезийный мир, а игрок (в одном из режимов) может строить и управлять поселением (крепостью) гномов. Про игру написано достаточно, поэтому я не буду вдаваться в подробности. Важно, что из-за большого размера игрового мира и высокой детализации симуляции, игра довольно требовательна к ресурсам — как процессору, так и памяти/кэшу. Игра поддерживает все три основные операционные системы.

Для игры существует проект 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 состоит из двух частей — генерации мира и начальной истории, при которой можно указать размер мира и длину истории (и другие параметры), и собственно игрового процесса. Последовательно, без перезапуска игры, выполнялись следующие тесты:

  1. Генерация мира очень маленького (smaller) размера с очень длинной (very long) историей.
  2. Генерация мира большого (large) размера с короткой (short) историей.
  3. Игровой процесс. Использовался один из «групповых» (когда много человек играют по очереди) сэйвов — glovedloved (Anethadefíni, 254). Выбор не так важен, покуда в нем достаточно большая крепость, и ничего, чтобы автоматически остановило игру, не происходит за время теста, который длился 20 внутриигровых дней.


Последний тест наиболее важен, во-первых, потому что это собственно игровой процесс, ради которого всё и происходит, а во-вторых, он менее подвержен влиянию случайностей, чем генерация мира (при которой случайным образом генерируются цивилизации, поселения, ландшафт, события и так далее).

Результаты


Вот график. Время выполнения в секундах, соответственно, меньше — лучше. Цены за месяц в долларах США.

image

Сразу виден неестественный разброс в результатах первого теста, не знаю точно, с чем это связано. Полагаю, отчасти с кэшированием, отчасти с низкой производительностью только что созданного сервера по каким-то причинам. Поэтому результаты отсортированы по последнему тесту, который, как отмечалось, наиболее важный. Второй тест тоже в целом соотносится с результатами третьего.

Не считая ожидаемого первого места у сервера EC2 c4.large, относящегося к оптимизированному для производительности типу C4, Amazon Lightsail оказался быстрее всех, что, учитывая цену, довольно приятная неожиданность. За ним практически с таким же результатом следует однопроцессорный сервер от Google и ноутбук. Далее хорош оказался до этого мне неизвестный Vultr, Linode, от которого я ожидал большего. Приз зрительских симпатий получает Digital Ocean — медленнее, но наиболее простой и быстрый в использовании. Довольно дорогие сервера EC2 m3.medium на удивление медленные, а самые дешевые сервера GCE совсем плохие даже с SSD дисками, результата тестирования сервера размера micro я не дождался.

Отдельно надо сказать о EC2 инстансах типа T2. Их особенностью является то, что при простое сервер получает процессорные кредиты (до определенного лимита), которые расходуются под нагрузкой. Расходуя кредиты, сервер работает с полной производительностью, когда они заканчиваются — производительность падает до 20%. С одной стороны, это очень хорошо подходит для наших целей — люди, особенно с мобильного устройства, не играют непрерывно весь день, плюс симуляция в игре останавливается, когда человек что-то делает в меню и т.п., поэтому это хороший вариант получить высокую производительность за небольшие деньги. С другой стороны, это «ненастоящая» производительность, поэтому я не включил инстансы этого типа в тестирование, дабы никого не путать. По опыту, пока есть кредиты, они довольно быстрые, когда они кончаются — очень медленные.

На этом всё.

© Geektimes