Test de performances du serveur cloud à l'aide de Dwarf Fortress

Dwarf Fortress est un jeu légendaire qui simule un monde fantastique en détail, et un joueur (dans l'un des modes) peut construire et gérer une colonie (forteresse) de gnomes (nains). Assez a été écrit sur le jeu, donc je n'entrerai pas dans les détails. Il est important qu'en raison de la grande taille du monde du jeu et des détails élevés de la simulation, le jeu soit assez exigeant en ressources - à la fois le processeur et la mémoire / cache. Le jeu prend en charge les trois principaux systèmes d'exploitation.

Il existe un projet DFHack pour le jeu, qui est engagé dans la rétro-ingénierie des structures de données de jeu et vous permet de créer des plugins et des scripts en C ++, Lua ou Ruby.

Je suis l'auteur de l'application et du code serveur qui implémente entièrement l'interface utilisateur du jeu sur les appareils iOS. Autrement dit, l'utilisateur met le jeu, le plug-in et l'application d'origine, et peut jouer à distance à partir d'un appareil mobile avec toutes les commodités.

Le serveur peut être installé à la maison et loué auprès de l'un des fournisseurs de cloud. Et l'idée de cette étude est née - premièrement, pour savoir lequel des services cloud est le mieux adapté et peut être recommandé aux utilisateurs en premier lieu, et deuxièmement, comparer réellement les performances du serveur en utilisant quelque chose de différent des serveurs Web et des utilitaires spéciaux .

Pour les tests, la version de Dwarf Fortress / DFHack 0.43.03-r1 a été utilisée. J'ai une image publique pour Docker, y compris le jeu lui-même et la version minimale de DFHack (ainsi que le code serveur lui-même pour le jeu distant, mais dans ce cas, il n'est pas utilisé). Un script a été écrit en Lua pour exécuter des tests et envoyer les résultats à un serveur Web. Également pour l'automatisation, le script suivant a été utilisé, spécifié dans les données utilisateur lors de la configuration des serveurs. Autrement dit, vous aviez juste besoin de créer un serveur, attendez que les résultats arrivent et supprimez-le.

#!/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 server_name 

Les fournisseurs suivants ont été testés: Digital Ocean, Amazon Lightsail, Amazon EC2, Vultr, Linode, Google Compute Engine et Macbook Pro Fin 2013 2Ghz Core i7.

Si le service cloud prend en charge la création d'un serveur avec Docker en un clic, alors cette fonctionnalité a été utilisée, sinon, la version d'Ubuntu 16.04 a été sélectionnée. Ainsi, seul Vultr n'a pas utilisé Ubuntu, mais CentOS 7. Pour les serveurs avec plus de 2 Go de mémoire, le fichier d'échange n'a pas été utilisé. Pour Google Compute Engine micro et petit, un lecteur SSD a été sélectionné.

Les options de serveur les moins chères ont été choisies, d'une part, car elles sont plus intéressantes pour ceux qui vont les utiliser pour le jeu, et d'autre part, parce que Dwarf Fortress n'utilise toujours qu'un seul cœur de processeur pour la simulation et (dans la version spécifiée) Application 32 bits.

Les tests


Le processus de jeu de Dwarf Fortress se compose de deux parties - la génération du monde et l'histoire initiale, dans laquelle vous pouvez spécifier la taille du monde et la longueur de l'histoire (et d'autres paramètres), et le processus de jeu lui-même. De manière cohérente, sans redémarrer le jeu, les tests suivants ont été effectués:

  1. Générer un monde de très petite taille avec une très longue histoire.
  2. Générer un monde de grande taille avec une courte histoire.
  3. Gameplay. Utilisé l'un des sauvegardes du «groupe» (quand beaucoup de gens jouent à tour de rôle) - gantée aimée (Anethadefíni, 254). Le choix n'est pas si important, tant qu'il y a une forteresse suffisamment grande, et rien qui arrêterait automatiquement le jeu ne se produit pendant le test, qui a duré 20 jours en jeu.

Le dernier test est le plus important, premièrement, parce que c'est le gameplay lui-même, pour lequel tout se passe, et deuxièmement, il est moins affecté par le hasard que la génération du monde (dans laquelle les civilisations, les colonies, le paysage, les événements et ainsi de suite).

Résultats


Voici l'horaire. Le temps d'exécution en secondes, respectivement, moins c'est mieux. Prix ​​mensuels en dollars américains.

image

Une diffusion non naturelle des résultats du premier test est immédiatement visible, je ne sais pas exactement à quoi cela est lié. Je crois, en partie avec la mise en cache, en partie avec les mauvaises performances du serveur nouvellement créé pour une raison quelconque. Par conséquent, les résultats sont triés par le dernier test, qui, comme indiqué, est le plus important. Le deuxième test est également généralement en corrélation avec les résultats du troisième.

En dehors de la première place attendue sur le serveur EC2 c4.large, qui est un type de C4 optimisé pour les performances, Amazon Lightsail s'est avéré être le plus rapide, ce qui, compte tenu du prix, est une très agréable surprise. Il est suivi par presque le même résultat du serveur et de l'ordinateur portable à processeur unique de Google. De plus, le Vultr inconnu, Linode, dont je m'attendais à mieux, s'est avéré bon. Le prix du public revient à Digital Ocean - plus lent, mais le plus simple et le plus rapide à utiliser. Les serveurs EC2 m3.medium plutôt chers sont étonnamment lents, et les serveurs GCE les moins chers sont vraiment mauvais même avec des SSD, je n'ai pas obtenu le résultat du test du serveur de micro-taille.

Séparément, il faut dire à propos des instances EC2 de type T2. Leur caractéristique est qu'avec un simple serveur reçoit des crédits de processeur (jusqu'à une certaine limite), qui sont dépensés sous charge. En dépensant des prêts, le serveur fonctionne à pleine capacité, lorsqu'ils sont épuisés - les performances tombent à 20%. D'une part, il est très bien adapté à nos besoins - les gens, en particulier à partir d'un appareil mobile, ne jouent pas en continu toute la journée, de plus la simulation dans le jeu s'arrête lorsqu'une personne fait quelque chose dans le menu, etc., c'est donc une bonne option pour obtenir haute performance pour peu d'argent. En revanche, il s'agit de «fausses» performances, donc je n'ai pas inclus d'instances de ce type dans les tests afin de ne dérouter personne. Par expérience, tant qu'il y a des prêts, ils sont assez rapides, lorsqu'ils s'épuisent - très lentement.

C’est tout.

Source: https://habr.com/ru/post/fr401485/


All Articles