Qu'est-ce que le Python GIL, comment il fonctionne et comment il affecte gunicorn.
Quel type de travailleur Gunicorn dois-je choisir pour l'environnement de production ?
Python a un verrou global (GIL) qui permet à un seul thread de s'exécuter (c'est-à-dire d'interpréter le bytecode). À mon avis, comprendre comment Python gère la concurrence est essentiel si vous souhaitez optimiser vos services Python.
Python et gunicorn vous offrent différentes façons de gérer la concurrence, et comme il n'existe pas de solution miracle qui couvre tous les cas d'utilisation, il est préférable de comprendre les options, les compromis et les avantages de chaque option.
Gunicorn expose ces différentes options sous le concept de « types de travailleurs ». Chaque type convient à un ensemble spécifique de cas d’utilisation.
Il s'agit du type de travail le plus simple où la seule option de concurrence est de créer N processus qui répondront aux requêtes en parallèle.
Ils peuvent bien fonctionner, mais ils entraînent beaucoup de surcharge (comme le changement de contexte de mémoire et de processeur) et ne s'adaptent pas bien si la majeure partie de votre temps de requête est en attente d'E/S.
gthread Worker améliore cela en vous permettant de créer N threads par processus. Cela améliore les performances d'E/S car vous pouvez exécuter plusieurs instances de votre code simultanément. C'est le seul des quatre concernés par GIL.
eventlet/gevent Workers tentent d'améliorer encore le modèle gthread en exécutant des threads utilisateur légers (c'est-à-dire des threads verts, des greenlets, etc.).
Cela vous permet d'avoir des milliers dedits greenlets à une fraction du coût par rapport aux threads système. Une autre différence est qu'il suit un modèle de travail collaboratif plutôt que préventif, permettant un travail ininterrompu jusqu'à ce qu'il se bloque. Nous analyserons d'abord le comportement du thread de travail gthread lors du traitement des requêtes et comment il est affecté par le GIL.
Contrairement à la synchronisation où chaque requête est servie directement par un processus, avec gthread, chaque processus dispose de N threads pour mieux évoluer sans la surcharge de plusieurs processus. Puisque vous exécutez plusieurs threads dans le même processus, le GIL les empêchera de s'exécuter en parallèle.
GIL n'est pas un processus ou un fil spécial. Il s'agit simplement d'une variable booléenne dont l'accès est protégé par un mutex, qui garantit qu'un seul thread est en cours d'exécution dans chaque processus. Son fonctionnement est visible dans l'image ci-dessus. Dans cet exemple, nous pouvons voir que nous avons 2 threads système exécutés simultanément, chaque thread gérant 1 requête. Le processus est le suivant :
Une autre option pour augmenter la concurrence sans utiliser de processus consiste à utiliser des greenlets. Ce travailleur génère des « threads utilisateur » au lieu de « threads système » pour augmenter la concurrence.
Bien que cela signifie qu'ils ne sont pas affectés par le GIL, cela signifie également que vous ne pouvez toujours pas augmenter le parallélisme car ils ne peuvent pas être planifiés en parallèle par le CPU.
Pour ce cas, il est évident qu'avoir un ouvrier de type greenlet n'est pas idéal. Nous finissons par faire attendre la deuxième requête jusqu'à ce que la première requête soit terminée, puis attendre à nouveau les E/S.
Dans ces scénarios, le modèle de collaboration greenlet brille vraiment car vous ne perdez pas de temps sur les changements de contexte et évitez la surcharge liée à l'exécution de plusieurs threads système.
Nous en serons témoins dans le test de référence à la fin de cet article. Maintenant, cela soulève la question suivante :
Pour répondre à ces questions, vous devez effectuer une surveillance pour collecter les métriques nécessaires, puis exécuter des benchmarks personnalisés par rapport à ces mêmes métriques. Il ne sert à rien d'exécuter des benchmarks synthétiques qui n'ont aucune corrélation avec vos modèles d'utilisation réels. Le graphique ci-dessous montre les mesures de latence et de débit pour différents scénarios pour vous donner une idée de la façon dont tout cela fonctionne ensemble.
Ici, nous pouvons voir comment la modification de l'intervalle/délai d'expiration du thread GIL affecte la latence des requêtes. Comme prévu, la latence des E/S s'améliore à mesure que l'intervalle de commutation diminue. Cela se produit parce que les threads liés au processeur sont obligés de libérer le GIL plus fréquemment et de permettre aux autres threads de terminer leur travail.
Mais ce n’est pas une panacée. La réduction de l’intervalle de commutation rendra l’exécution des threads liés au processeur plus longue. Nous pouvons également constater une augmentation de la latence globale et une diminution des délais d'attente en raison de la surcharge accrue liée à la commutation constante des threads. Si vous souhaitez l'essayer vous-même, vous pouvez modifier l'intervalle de commutation en utilisant le code suivant :
Dans l'ensemble, nous pouvons voir le benchmark reflète l'intuition dérivée de notre analyse précédente du fonctionnement des threads et des greenlets liés à GIL.
gthread a une meilleure latence moyenne pour les requêtes liées aux E/S en raison des intervalles de commutation forçant les threads de longue durée à se libérer.
Les requêtes liées au CPU gevent ont une meilleure latence que gthread car elles ne sont pas interrompues pour répondre à d'autres requêtes.
Les résultats ici reflètent également notre intuition précédente selon laquelle gevent a un meilleur débit que gthread. Ces références dépendent fortement du type de travail effectué et ne se traduisent pas nécessairement directement par votre cas d'utilisation.
L'objectif principal de ces benchmarks est de vous donner quelques conseils sur ce qu'il faut tester et mesurer afin de maximiser chaque cœur de processeur qui répondra aux requêtes.
Étant donné que tous les travailleurs gunicorn vous permettent de spécifier le nombre de processus qui seront exécutés, ce qui change est la façon dont chaque processus gère les connexions simultanées. Par conséquent, assurez-vous d’utiliser le même nombre de travailleurs pour rendre le test équitable. Essayons maintenant de répondre à la question précédente en utilisant les données collectées à partir de notre benchmark.
En effet. Cependant, pour la grande majorité des charges de travail, cela ne change pas la donne.
Comment choisir entre gevent/eventlet et gthread lorsque vous travaillez avec des E/S et CPU mixtes ? Comme nous pouvons le voir, ghtread a tendance à permettre une meilleure concurrence lorsque vous effectuez un travail plus gourmand en CPU.
Tant que vos benchmarks peuvent simuler un comportement de type production, vous verrez clairement des performances maximales, puis elles commenceront à se dégrader en raison d'un trop grand nombre de threads.
Dois-je simplement utiliser des sync Workers et augmenter le nombre de processus forkés pour éviter le GIL ?
À moins que vos E/S ne soient presque nulles, la mise à l'échelle avec uniquement des processus n'est pas la meilleure option.
Les coroutines/Greenlets peuvent améliorer l'efficacité du processeur car ils évitent les interruptions et les changements de contexte entre les threads. Les coroutines échangent la latence contre le débit.
Si vous mélangez des points de terminaison liés aux IO et au CPU, les coroutines peuvent provoquer une latence plus imprévisible - les points de terminaison liés au CPU ne seront pas interrompus pour répondre aux autres requêtes entrantes. Si vous prenez le temps de configurer correctement gunicorn, le GIL ne pose pas de problème.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
