4 votes

PHP-FPM et APC pour l'hébergement mutualisé ?

Nous cherchons un moyen de faire en sorte qu'APC ne crée qu'un seul cache par compte/site. Cela peut être fait avec Fastcgi (dernière mise à jour 2006 ) mais avec Fastcgid APC devra créer plusieurs caches pour plusieurs processus exécutés par le même compte.

Pour contourner ce problème, nous nous sommes intéressés à PHP-FPM.

Le gestionnaire de processus PHP permet à plusieurs processus PHP de partager un seul cache APC.

Mais d'après ce que j'ai lu (j'espère me tromper), même si vous créez un pool par processus, tous les sites de tous les pools partageront le même cache APC. Cela nous ramène au même problème qu'avec Memcached partagé : ce n'est pas sûr !

Sur le site de php-fpm, j'ai lu que vous pouvez chrooter les pools de php-fpm et définir un UID et un GID spécifiques par pool si c'est le cas, APC ne devrait-il pas utiliser cet utilisateur et ne pas avoir accès au cache des autres pools ?

Un article ici (en 2011) suggère que vous devriez exécuter un processus par pool en créant plusieurs lanceurs sur différents ports et différents fichiers de configuration avec un pool par fichier de configuration :

http://groups.drupal.org/node/198168

Est-ce toujours nécessaire ?

Si oui, quel serait l'impact de l'exécution de 800 processus de php-fpm ? S'agirait-il principalement de la mémoire ? Si oui, comment puis-je déterminer l'impact sur la mémoire ?

Je suppose qu'il serait préférable d'exécuter 800 fois le php-fpm plutôt que d'avoir des comptes créant plusieurs caches APC pour un seul site ?

Si en moyenne un compte crée un cache de 50Mo et crée 3 caches par compte cela fait 150Mo par compte ce qui fait 120Go .

Cependant, si chaque compte n'utilise en moyenne que 50 Mo, cela fait 40 Go.

Nous aurons au moins 128 Go de RAM sur notre prochain serveur, donc 40 Go est acceptable si l'exécution de 800 x PHP-FPM ne crée pas une surcharge de plus de 20 Go !

Selon vous, PHP-FPM est-il le meilleur moyen de fournir un cache APC sécurisé sur un hébergement mutualisé avec un serveur disposant d'une quantité décente de mémoire ?

Ou devrais-je envisager un autre système ?

Merci !

2voto

JDJ114 Points 1

Je ne vois vraiment pas de problème à utiliser FastCGI ici. Je m'explique : APC est nécessaire pour les sites avec une fréquence élevée de visites et pas du tout nécessaire pour les sites qui reçoivent des visites occasionnellement.

Donc, en ce qui concerne l'efficacité de la mémoire : vous avez plusieurs sites sur votre serveur, dont certains sont populaires et d'autres non. Vous avez un pool de processus FastCGI pour chaque site et PHP gère ses travailleurs (en utilisant le wrapper FastCGI Shell avec la variable PHP_FCGI_CHILDREN), chaque pool FastCGI a une durée de vie, le cache APC est partagé entre tous les processus PHP du pool.

Les sites populaires seront souvent visités et le pool FastCGI ne mourra pas, l'APC restera en mémoire, avec un cache de 50 Mo pour tous les travailleurs PHP.

Les sites moins populaires déclencheront la politique d'élimination FastCGI et les travailleurs seront complètement arrêtés, le cache APC libérant de la mémoire. Lorsque ce site recevra une visite, le pool sera redémarré et la première visite sera plus lente. Ce modèle combine efficacement le mode PHP-CGI avec une faible consommation de mémoire et une utilisation élevée des ressources avec le pool de processus PHP-FPM avec un cache chaud et prêt.

Avec le modèle PHP-FPM, vous devrez garder au moins UN travailleur pour chaque site, ce qui entraîne une grande consommation de mémoire.

ps. il existe un patch à la demande pour php-fpm mais je ne l'ai pas encore testé en production.

1voto

regilero Points 1440

J'ajouterai que votre post m'a aidé à trouver un bug où le cache d'opcode d'APC mélangeait plusieurs fichiers de configuration entre plusieurs instances chrootées. Ainsi, lorsque vous utilisez des pools chrootés, il est toujours nécessaire d'avoir des démons php-fpm séparés, vous ne devez jamais utiliser plusieurs pools où le chemin chrooté peut s'effondrer entre les pools.

0voto

Steve Smith Points 58

Je sais ce que vous essayez de faire, puisque cela fait partie du projet que je dirige. J'ai déjà fait des recherches à ce sujet et il semble que la seule façon de résoudre le problème est d'utiliser une version modifiée de memcached et apc.

Je pensais qu'actuellement APC permettait de sauvegarder des données dans memcached, mais j'ai découvert que ce n'est pas le cas, donc la façon la plus simple de résoudre le problème est de pirater memcached en lui permettant d'avoir différents comptes avec différents caches, et peut-être différentes tailles de cache, et ensuite de pirater APC aussi, permettant d'interroger memcached pour récupérer des codes d'opération à partir de lui.

Le piratage de Memcached serait également utile car vous pourriez fixer un délai d'expiration au cache et évaluer ce qui doit être mis en cache et ce qui ne doit pas l'être : de cette façon, vous économiseriez plus de mémoire vive et ne l'utiliseriez que sur demande. Pour sélectionner le compte que vous voulez utiliser, vous utiliseriez alors l'authentification SASL (qui a déjà été développée pour memcached) contre le serveur memcached, mettant plus de sécurité dans cette configuration.

Le déploiement de Memcached serait également utile pour d'autres choses comme la mise en cache, je vais donc suivre cette voie.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X