Lequel installer: Apache Worker ou Prefork? Quels sont les (dés) avantages de chacun?


55

D'après les descriptions à la fois de Prefork et de Worker MPM, il semble que le type de préfork soit quelque peu obsolète, mais je ne parviens pas à trouver une comparaison adéquate entre les deux types.

Ce que j'aimerais savoir:

  • Quelles sont les différences entre les deux versions?
  • Quels sont les avantages ou les inconvénients de chaque type de serveur?
  • Existe-t-il des directives de base sur le type à choisir en fonction des conditions?
  • Existe-t-il de grandes différences de performances entre les deux?

Réponses:


40

Comme le dit la documentation, vous devez utiliser le MPM prefork si vous devez éviter les threads pour assurer la compatibilité avec les bibliothèques non sécurisées pour les threads. En règle générale, tout module Apache non trivial ( mod_phpou, plus précisément, la myriade d’extensions et de bibliothèques qu’il est liée à un exemple canonique) possède une sorte de bibliothèque non sécurisée pour les threads (ou dispose code sécurisé dedans), donc à moins que vous n'utilisiez une jolie installation Apache, je choisirais le MPM prefork.


3
J'aurais recommandé le travailleur MPM, sauf si vous utilisez PHP. Worker est le MPM recommandé par Apache, et offre de meilleures performances et des frais généraux réduits. C'est seulement que les développeurs PHP n'ont jamais entendu parler de la sécurité des threads qu'il est nécessaire d'utiliser prefork.
David Pashley

16
PHP est thread-safe depuis très longtemps. Ils suggèrent seulement l'utilisation de pré-forkers car ils ne peuvent pas contrôler ce que font les autres bibliothèques. Quittez blâmer PHP pour l'inaction d'autres développeurs.
Alister Bulman

3
PHP est peut-être thread-safe (bien que j'en doute) mais toutes les bibliothèques auxquelles il est lié ne le sont certainement pas. Ici, nous exécutons quelques applications PHP assez volumineuses et tous les deux mois, nous essayons de passer de la pré-fork à la travailleuse, mais nous obtenons immédiatement des données corrompues.
Aleksandar Ivanisevic -

5
Au moins la fonction changera la variable ENV ne sera pas thread-safe, setlocal php.net/manual/en/function.setlocale.php est un exemple courant de cela.
rayon

4
Remarque: ces problèmes ne s'appliquent pas si PHP est connecté, par exemple avec php-fpmvia FastCGI. Ensuite, le MPM travailleur convient parfaitement - alors le fpm exécutera toutes les requêtes PHP dans un processus propre, tandis que Apache pourra exécuter les threads. Le problème de sécurité de PHP-Thread vous empêche uniquement d'utiliser mod_php, qui exécute PHP dans le processus Apache.
mschuett

13

La solution classique pour exécuter des extensions non sécurisées tout en servant de grands nombres (> 100) de connexions simultanées consiste à exécuter PHP sur fastCGI (mod_fcgid, un module natif d'apache) et à adresser des requêtes dynamiques proxy à une instance apache exécutant Worker MPM.

Cela vous permettrait de passer de quelques centaines à plus de 1 000 connexions simultanées avec une quantité de mémoire modeste (4 à 8 Go) lorsque vous fournissez un mélange de contenu statique et dynamique.

Bien entendu, vous devez également examiner les solutions de mise en cache front-end dans le cadre de votre déploiement global (memcached, varnish).

Vous pouvez également mettre à niveau vers apache 2.4 et son événement natif , MPM, qui gère la concurrence de manière beaucoup améliorée (les threads sont déclenchés lors de la connexion, sans attendre d'être interrogés.)


Pourriez-vous développer le commentaire de l'événement mpm? Comment ça se compare vs mpm-worker?
Sirex

Alors que le MPM travailleur était déjà basé sur les threads, et donc beaucoup plus rapide à démarrer et plus léger à exécuter, l'événement MPM n'interroge plus le socket - il est averti de l'activité; donc "événement".
Adaptr

donc cela devrait mieux fonctionner sur les sites à fort trafic (13k / sec)?
Sirex

6

Cela fait environ trois ans que la question a été postée, mais je vous conseillerais plutôt de choisir MPM (travailleur) plutôt qu'un pré-fourchisseur, même si vous utilisez PHP, pour obtenir de meilleures performances.

En ce qui concerne les différences, le pré-fork est non-threadé et le serveur crée un processus pour chaque requête du client (il pré-forge en prévision de nouvelles demandes afin que le forking ne prenne pas le temps de réponse). Étant donné que les demandes sont traitées par un serveur dans un processus distinct, votre mémoire et votre CPU sont généralement beaucoup plus sollicités. Le travailleur apporte le multi-threading, qui est plus léger et utilise mieux la mémoire.


2

C'est quelque chose de très particulier à ce que vous servez. Si vous faites beaucoup de petites connexions statiques, les threads seront plus légers et plus rapides. Si vous avez peu d'applications volumineuses constamment générées, Prefork pourrait avoir un avantage en raison de sa maturité et de sa stabilité. Pourquoi ne pas simplement configurer ce dont vous avez besoin, en tester un, échanger le module MPM, essayer à nouveau, voir celui qui vous convient le mieux?


Vous ne pouvez pas "échanger" arbitrairement le MPM dans Apache 2.2; il est défini au moment de la compilation.
Adaptr

Vous pouvez avec apt ou RPM. Debian propose plusieurs packages Apache 2 différents, en fonction du style que vous préférez.
Brendan Byrd

1

qui a besoin du type et du type de trafic que vous allez avoir. Et avant tout, vous devez comprendre la principale différence entre le préfornement et le travailleur. J'espère que l'article ci-dessous vous aidera à comprendre! http://slashroot.in/how-is-nginx-different-from-apache


2
Nous préférons que les réponses aient un contenu, pas des liens vers du contenu. Si vous pouviez fournir un résumé de ce qui est sur la cible de lien, c'est la meilleure pratique. Link-rot se produit.
sysadmin1138

1
La question portait sur Apache (nginx n'est pas apache) et les avantages relatifs de prefork ou de threads (nginx n'utilise ni l'un ni l'autre)
symcbean
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.