Dwarf Fortress es un juego legendario que simula un mundo de fantasía en detalle, y un jugador (en uno de los modos) puede construir y gestionar un asentamiento (fortaleza) de gnomos (enanos). Ya se ha escrito lo suficiente sobre el juego, así que no entraré en detalles. Es importante que, debido al gran tamaño del mundo del juego y los altos detalles de la simulación, el juego requiera bastante recursos, tanto el procesador como la memoria / caché. El juego es compatible con los tres principales sistemas operativos.
Hay un proyecto DFHack para el juego, que se dedica a la ingeniería inversa de las estructuras de datos del juego y le permite crear complementos y scripts en C ++, Lua o Ruby.
Soy el autor de la aplicación y el código del servidor que lo acompaña que implementa completamente la interfaz de usuario del juego en dispositivos iOS. Es decir, el usuario coloca el juego original, el complemento y la aplicación, y puede jugar de forma remota desde un dispositivo móvil con todas las comodidades.
El servidor se puede instalar tanto en casa como alquilado de uno de los proveedores de la nube. Y nació la idea de este estudio: en primer lugar, para averiguar cuál de los servicios en la nube es más adecuado y se puede recomendar a los usuarios en primer lugar, y en segundo lugar, comparar el rendimiento del servidor utilizando algo diferente de los servidores web y utilidades especiales .
Para las pruebas, se utilizó la versión de Dwarf Fortress / DFHack 0.43.03-r1. Tengo una imagen pública de Docker, incluido el juego en sí y la versión mínima de DFHack (así como el código del servidor en sí para el juego remoto, pero en este caso no se usa). Se escribió un script en Lua para ejecutar pruebas y enviar los resultados a un servidor web. También para la automatización, se utilizó el siguiente script, especificado en los datos del usuario al configurar los servidores. Es decir, solo necesita crear un servidor, esperar hasta que lleguen los resultados y eliminarlo.
Se probaron los siguientes proveedores: Digital Ocean, Amazon Lightsail, Amazon EC2, Vultr, Linode, Google Compute Engine y Macbook Pro Late 2013 2Ghz Core i7.
Si el servicio en la nube admite la creación de un servidor con Docker con un solo clic, entonces se usó esta característica; de lo contrario, se seleccionó la versión de Ubuntu 16.04. Por lo tanto, solo Vultr no usó Ubuntu, sino CentOS 7. Para los servidores con más de 2 GB de memoria, no se usó el archivo de intercambio. Para Google Compute Engine micro y pequeño, se seleccionó una unidad SSD.
Se eligieron las opciones de servidor más baratas, en primer lugar, porque son más interesantes para quienes las van a usar para el juego, y en segundo lugar, porque Dwarf Fortress todavía usa solo un núcleo de procesador para la simulación y (en la versión especificada) Aplicación de 32 bits.
Pruebas
El proceso de jugar Dwarf Fortress consta de dos partes: la generación del mundo y la historia inicial, en la que puedes especificar el tamaño del mundo y la duración de la historia (y otros parámetros), y el proceso del juego en sí. Consistentemente, sin reiniciar el juego, se realizaron las siguientes pruebas:
- Generando un mundo de un tamaño muy pequeño con una historia muy larga.
- Generando un mundo de gran tamaño con una historia corta.
- Jugabilidad Usó uno de los "grupos" (cuando muchas personas juegan por turno) guarda - glovedloved (Anethadefíni, 254). La elección no es tan importante, siempre que haya una fortaleza lo suficientemente grande, y nada que detenga automáticamente el juego no suceda durante la prueba, que duró 20 días en el juego.
La última prueba es más importante, en primer lugar, porque es el juego en sí mismo, por lo que sucede todo, y en segundo lugar, se ve menos afectado por el azar que la generación del mundo (en el que civilizaciones, asentamientos, paisajes, eventos y etc.)
Resultados
Aquí está el horario. Tiempo de ejecución en segundos, respectivamente, menos es mejor. Precios mensuales en dólares estadounidenses.
Una propagación no natural en los resultados de la primera prueba es inmediatamente visible, no sé exactamente con qué está conectado. Creo, en parte con el almacenamiento en caché, en parte con el bajo rendimiento del servidor recién creado por alguna razón. Por lo tanto, los resultados se ordenan por la última prueba, que, como se señaló, es la más importante. La segunda prueba también generalmente se correlaciona con los resultados de la tercera.
Además del primer lugar esperado en el servidor EC2 c4.large, que está relacionado con el rendimiento optimizado tipo C4, Amazon Lightsail resultó ser el más rápido, lo que, teniendo en cuenta el precio, es una sorpresa bastante agradable. Le sigue casi el mismo resultado del servidor y la computadora portátil de procesador único de Google. Además, el previamente desconocido Vultr, Linode, del que esperaba más, resultó ser bueno. El Premio del Público es para Digital Ocean: más lento, pero el más fácil y rápido de usar. Los servidores EC2 m3.medium bastante caros son sorprendentemente lentos, y los servidores GCE más baratos son realmente malos incluso con SSD, no obtuve el resultado de probar el servidor de tamaño micro.
Por separado, hay que decir sobre las instancias EC2 de tipo T2. Su característica es que con un servidor simple recibe créditos de procesador (hasta cierto límite), que se gastan bajo carga. Al gastar préstamos, el servidor se ejecuta a plena capacidad cuando se agota: el rendimiento cae al 20%. Por un lado, es muy adecuado para nuestros propósitos: las personas, especialmente desde un dispositivo móvil, no juegan continuamente todo el día, además la simulación en el juego se detiene cuando una persona hace algo en el menú, etc., por lo que esta es una buena opción para obtener Alto rendimiento por poco dinero. Por otro lado, este es un rendimiento "falso", por lo que no incluí instancias de este tipo en las pruebas para no confundir a nadie. Por experiencia, siempre que haya préstamos, son bastante rápidos, cuando se agotan, muy lentos.
Eso es todo