Contexte

Je développe un serveur d'application pour certains jeux téléphoniques avec Python et Django, et j'utilise uWSGI comme serveur Web. uWSGI a trop de paramètres et il est difficile de savoir lequel choisir.

En fait, j'ai fait un test de charge, modifié divers paramètres et maintenant je peux obtenir des performances stables. Je voudrais partager comment je l'ai mesuré à ce moment-là et quels paramètres j'ai changé.

environnement

python: 2.7.10
uWSGI: 2.0.11.1
criquet: outil de test de charge. Nous avons créé un scénario utilisateur et testé diverses charges d'API sur le serveur d'applications.
EC2: c4.2xlarge 8 cœurs

Outil de mesure du rendement

"Ne devine pas, mesure"

Il y a un mot, mais si vous ne pouvez pas le mesurer quoi qu'il arrive, vous ne savez pas s'il s'est amélioré. Les outils suivants ont été principalement utiles cette fois.

Nouvelle relique: vous la connaissez. Parce que c'est une version payante, vous pouvez voir les détails
uwsgitop: outil de statistiques de performances uWSGI qui peut être introduit avec PyPI
vmstat

À propos d'uwsgitop

Les données de statistiques de performances peuvent être sorties sur le socket comme suit dans les paramètres du côté uWSGI.

stats = /var/run/uWSGI/projectname.stats.sock
memory-report = true

Si vous exécutez uWSGI top installé avec pip etc. comme suit, vous pouvez voir les statistiques en temps réel comme la commande unix top.

$ uwsgitop /var/run/uWSGI/projectname.stats.sock

Voici un exemple d'exécution. Dans cet état, il s'agit d'une unité de traitement, mais si vous appuyez sur a sur le clavier, vous pouvez également la voir dans une unité de thread.

Paramètres UWSGI efficaces pour le réglage des performances définis cette fois

Options uWSGI a des valeurs pour divers fichiers de paramètres, mais il y a trop de paramètres à définir. Il est difficile de savoir au début si vous pouvez le faire. De plus, l'explication des options est simple, et l'auteur de uWSGI lui-même vous demande de regarder la source, donc ce sera difficile si vous ne l'avez jamais utilisé.

Ici, je voudrais augmenter les paramètres qui étaient efficaces lorsque je les ai réellement définis.

processes, threads

uWSGI peut spécifier le nombre de processus et de threads qui acceptent les demandes. L'uWSGI que nous développons a les paramètres suivants.

processes = 16
threads = 1

Je l'ai testé avec diverses combinaisons de processus et de threads, mais lorsque j'ai augmenté le nombre de threads, le nombre de changements de contexte a augmenté et le RPS géré était inférieur à la moitié.

À propos, lorsque le nombre de threads est égal à 1, même si les processus sont augmentés, il n'y a pas beaucoup de différence lorsque le nombre de cœurs est de 8 ou plus.

thunder-lock

Si vous utilisez un serveur Linux, vous devez d'abord définir cette option sur true comme indiqué ci-dessous.

thunder-lock = true

Pour plus de détails, voir ici, mais s'il est faux, il s'agit d'une requête à traiter dans plusieurs processus uWSGI. Sera biaisé.

max-requests, max-requests-delta

max-requests est un paramètre pour le nombre de requêtes que le processus recevra avant le rechargement. Il est défini comme suit.

max-requests = 6000

Au début du test de charge, cette valeur était une valeur élevée, elle n'a pas été rechargée et l'état d'utilisation de la mémoire était le suivant.

En regardant comment la mémoire du processus uWSGI augmente, 6000 est approprié, donc je l'ai configuré de cette façon. Je pense qu'il est nécessaire de rechercher pourquoi la mémoire augmente, mais comme elle est rechargée une fois toutes les 6000 fois, il est jugé qu'il n'y a pas d'effet et elle est définie. Une fois rechargée, la mémoire sera libérée et elle sera dans le même état que lors de son démarrage initial.

J'ai oublié de prendre chaque processus, mais s'il est réglé correctement, la mémoire se stabilisera dans une certaine période comme indiqué ci-dessous.

Cependant, notez que lorsque le processus redémarre, il ne pourra pas recevoir de nouvelles demandes pendant quelques secondes. Si vous appliquez la même valeur de max-requests à tous les processus, ils redémarreront presque tous en même temps et le serveur entier ne recevra pas de demandes pendant quelques secondes.

Pour éviter cela, la valeur max-requests-delta est définie comme suit.

max-requests-delta = 300

Il redémarrera avec cette différence pour chaque processus. Par exemple, si un processus redémarre à 6000, le processus suivant redémarre lorsqu'il reçoit 6300 demandes. En supposant que le RPS est d'environ 16 et que le processus est défini sur 16, un processus reçoit une demande toutes les secondes, il redémarre donc toutes les 300 secondes. Cela limitera le nombre de processus pouvant être redémarrés en même temps, évitant ainsi que le serveur dans son ensemble ne puisse recevoir de requêtes.

touch-reload, lazy-apps

Vous pouvez spécifier le chemin du fichier dans touch-reload et recharger uWSGI chaque fois que le paramètre est touché. Cependant, si vous le faites, le serveur entier ne pourra pas recevoir de demandes, vous pouvez donc définir des applications paresseuses afin qu'il puisse être rechargé séquentiellement.

Si lazy-apps est spécifié dans notre environnement, il ne convient pas pour la mise à jour immédiate, nous ne permettons donc pas d'attendre quelques secondes et de le configurer.

Résumé

Cette fois, nous avons vu les paramètres de uWSGI qui ont été réellement réglés. De plus, les paramètres suivants ont été définis, mais j'aimerais continuer à étudier plus avant et à améliorer les performances.

listen
harakiri
harakiri-verbose
limit-as
log-date