Le serveur d'application uWSGI, qui peut gérer non seulement Python mais aussi Ruby, php et Perl, a un mode appelé moins cher. C'est une fonction qui ajuste dynamiquement le nombre de travailleurs en fonction de la charge.
Par défaut, il existait des algorithmes de contrôle appelés Spare, Backlog et busyness. Cependant, je n'ai aimé aucun d'entre eux, alors j'ai créé un algorithme appelé spare2 et l'ai fusionné dans la famille d'origine. Comme c'était la branche principale (version de développement) qui était incluse, nous avons également fourni une version stable de Plugins for uWSGI 2.0.
J'expliquerai l'algorithme de spare2 ajouté cette fois et pourquoi il était difficile d'adopter d'autres algorithmes existants. (Voir la documentation (http://uwsgi-docs.readthedocs.org/en/latest/Cheaper.html) pour plus d'informations sur d'autres algorithmes.)
spare2
L'explication est basée sur l'exemple de fichier de configuration.
[uwsgi]
...
processes=10
cheaper-algo=spare2
cheaper=2
cheaper-initial=2
cheaper-step=2
cheaper-idle=30
process = 10 est le nombre maximum de processus de travail. «moins cher = 2» est le nombre minimum de processus et sera ajusté pendant ce temps. moins cher-initial = 2 est le nombre de travailleurs immédiatement après le démarrage.
L'algorithme de rechange2 tente de maintenir le nombre de travailleurs inactifs spécifié par moins cher. Par exemple, si le nombre de workers inactifs devient un, 2-1 = 1 worker sera démarré.
moins cher-step = 2 est le nombre maximum de processus pouvant être démarrés en même temps. Lorsque «moins cher» est important, vous pouvez ajuster «l'étape moins chère» pour ne pas lancer trop de processus à la fois.
Si le nombre de processus inactifs est supérieur à moins cher pour moins cher-idle = 30 secondes, un processus de travail est arrêté. En définissant cette valeur plus longtemps, vous pouvez empêcher les travailleurs de s'arrêter et de redémarrer en détail.
spare
[uwsgi]
...
processes=10
cheaper-algo=spare
cheaper=2
cheaper-initial=2
cheaper-step=2
cheaper-overload=5
L'algorithme de réserve compte lorsqu'il n'y a pas de processus inactifs (= surcharge) et lorsqu'il y a deux processus inactifs ou plus (= inactif). Si vous comptez un, l'autre sera réinitialisé, mais si vous n'avez qu'un seul processus inactif, aucun ne sera compté.
Lorsque le nombre de surcharges atteint moins cher-surcharge = 5, ajoutez les processus de travail moins cher-step = 2.
Lorsque le nombre d'inactivité atteint `` moins cher-surcharge = 5`, arrêtez un processus de travail.
Cet algorithme nécessite une petite «surcharge moins chère» et une grande «étape moins chère» pour augmenter rapidement le nombre de travailleurs, par exemple lorsqu'un serveur est ajouté sous la répartition de la charge. Même dans ce cas, le temps de réponse initial a tendance à être bien pire car les nouveaux travailleurs ne sont pas lancés tant que tous les processus de travail ne sont pas occupés.
De plus, si vous définissez `` moins cher-surcharge = 1`, le nombre de travailleurs a tendance à augmenter ou à diminuer petit à petit. Par exemple, si vous avez environ 40 travailleurs, il semble exagéré d'arrêter un travailleur avec seulement deux processus inactifs.
backlog
C'est similaire à Spare, mais cela prend une décision de surcharge en tirant parti de la capacité de Linux à surveiller le nombre de connexions dans le backlog TCP.
Il est hors de question car il hérite des faiblesses du spare et n'est pas disponible lorsque nginx et uWSGI sont connectés par des sockets unix.
busyness
L'occupation complique la réserve.
Soit «surcharge moins chère» la période de temps, et que l'occupation soit le pourcentage de travailleurs inactifs pendant cette période. Définissez les valeurs minimale et maximale de cette occupation, et si elle tombe en dessous de la valeur minimale, le nombre de travailleurs diminuera, et s'il dépasse la valeur maximale, le nombre de travailleurs augmentera.
D'autres options sont assez compliquées, telles que l'option de rendre difficile la réduction du nombre de travailleurs, et l'option de surveiller l'arriéré et d'ajouter des travailleurs sans attendre le délai, mais cela augmente également le nombre de travailleurs en douceur au début. Il est difficile de gérer la charge d'appel.
Recommended Posts