2 votes

Pourquoi APC (ou similaire) cause-t-il des problèmes de performance pour l'hébergement mutualisé ?

Je suis en train d'utiliser un hébergement mutualisé et je ne peux pas activer APC. Il y avait un fil de discussion à ce sujet ici, et la seule raison évoquée était la sécurité (php-cgi contre mod_php). J'ai interrogé l'hébergeur, et ils ont dit que c'était pour des raisons de performance, spécifiquement que l'I/O ferait planter le serveur. Je ne comprends pas vraiment cela - sûrement avec un cache d'opcode en mémoire partagée, il y aurait moins d'I/O? Fondamentalement, si je configurais une entreprise d'hébergement mutualisé (bien que je ne puisse pas le faire!), j'aurais pensé qu'il aurait beaucoup de sens d'utiliser un cache (si la sécurité le permettait) pour améliorer les performances pour tous les clients.

Est-ce que quelqu'un peut éclairer ma lanterne à ce sujet? Merci d'avance

7voto

JRR Points 11

Je dirais que l'utilisation de l'APC sur les plans d'hébergement mutualisé n'est généralement pas une bonne idée.
La réponse de votre hébergement est correcte mais ce n'est pas la seule raison.

Lorsque vous optez pour un hébergement mutualisé, vous devez être conscient que vous n'êtes pas le seul à utiliser le serveur sur lequel votre site est hébergé. Selon le serveur de l'entreprise d'hébergement, il peut y avoir 300 (ou plus) clients qui hébergent également leurs sites sur cette machine.

Très souvent, ces sites contiennent DE NOMBREUX fichiers php. Par exemple, un site basé sur joomla 1.6 peut avoir environ ~3000 fichiers php (~10mo) (incluant le site et le panneau d'administration). Imaginez que ces 300 clients utilisent tous la plateforme Joomla et que les sites sont

  1. Très fréquemment visités
  2. Engendrent une charge moyenne sur le serveur

Cela signifie que tous ces clients devront éventuellement mettre en cache ~900 000 fichiers - ~3000mo de RAM seront utilisés uniquement pour mettre en cache les fichiers php. Comme vous le savez, avec l'APC, vous pouvez également stocker des "entrées de cache utilisateur" où vous pouvez généralement stocker des paramètres ou des objets sérialisés. Je ne peux pas dire combien de RAM ira là-dedans car cela dépend de ce que vous stockez, mais disons encore 50-100mo supplémentaires.

Pour l'instant, nous avons utilisé environ 3,1Go de RAM.
Maintenant, ajoutez un peu de RAM nécessaire pour faire fonctionner les services de base - Apache, FTP, PHP, MySQL, PostgreSQL, SendMail et les outils de sauvegarde du serveur. Vous finirez probablement quelque part près de 5-6Go de RAM qui seront presque constamment utilisés.

Les autres problèmes avec l'APC surviennent lorsque vous mettez en cache - tout le monde peut voir ce que vous avez mis en cache (autant que je sache). Vous devrez donc probablement chiffrer ce que vous stockez - ce qui demandera plus de CPU car vous devrez chiffrer/déchiffrer en permanence. De plus, si quelqu'un efface accidentellement tous les fichiers mis en cache/entrées utilisateur, le serveur va partir en vrille en essayant de recacher.

En fin de compte, aucun administrateur système ne voudra traverser toute la galère pour activer et prendre en charge l'APC. Ce n'est pas non plus un avantage pour l'entreprise. Ils préféreraient avoir 300 clients de plus leur rapportant de l'argent plutôt que de se préoccuper de l'APC et se demander si leur serveur ne tombera pas en panne ou si quelque chose ne tournera pas mal à tout moment.

Une meilleure solution serait que le client obtienne un serveur dédié (géré). De cette façon, le client sera le seul à héberger un site sur ce serveur et pourra demander au support d'installer ce qu'il souhaite sur le serveur. Cela sera beaucoup plus facile et épargnera au client, à l'administrateur système et à l'entreprise d'hébergement de devenir chauves :)

J'espère que cela vous aidera à comprendre pourquoi l'APC n'est pas inclus dans les hébergements mutualisés.

1voto

k s Points 101

Par : http://www.php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask

apc.mmap_file_mask chaîne de caractères
Si compilé avec le support MMAP en utilisant --enable-mmap ceci est le masque de fichier de style mktemp à passer au module mmap pour déterminer si votre région mémoire mmap'ed va être sauvegardée dans un fichier ou dans une mémoire partagée. Pour un mmap sauvegardé dans un fichier, le paramétrer à quelque chose comme /tmp/apc.XXXXXX (exactement 6 _Xs). Pour utiliser le style POSIX shm_open/mmap mettez un .shm quelque part dans votre masque, par exemple /apc.shm.XXXXXX Vous pouvez également le paramétrer à /dev/zero pour utiliser l'interface /dev/zero_ de votre noyau pour la mémoire mmap'ed anonyme. Le laisser non défini forcera un mmap anonyme.

Si vous utilisez un fichier sauvegardé cela augmentera certainement votre IO en fonction de la quantité de trafic entrant sur le serveur.

0voto

devicenull Points 5542

Cela va diminuer les performances de tout hébergement partagé à moins que vous ayez suffisamment de mémoire pour garder chaque fichier PHP chargé en mémoire. Lorsque vous avez tout un tas d'utilisateurs essayant de mettre en cache des fichiers qui ne sont pas souvent consultés, le serveur va commencer à faire des échanges de mémoire, ce qui va diminuer les performances de tout ce qui tourne sur cette machine.

0voto

3molo Points 4320

Selon https://stackoverflow.com/questions/1053810/php-apc-what-happen-when-apc-cache-is-full, le cache est vidé lorsque la mémoire est pleine et si le ttl est à 0. S'il n'est pas défini à zéro, il utilisera un mécanisme LRU (Least Recently Used).
Il me semble toujours avantageux d'utiliser APC.

0voto

RSabet Points 2887

@tftd a indiqué les raisons principales de ne pas activer APC, Memcached, etc. dans l'hébergement mutualisé. Cependant, un cas d'utilisation peut survenir si votre serveur mutualisé n'est pas vraiment partagé mais seulement utilisé pour vos propres projets (ou pour les clients de conception/développement web et si vous ne leur donnez pas accès FTP/panel), alors ce serveur peut toujours bénéficier d'APC/Memcached, etc.

En tout cas, je suppose que le problème d'E/S dépend de la RAM disponible pour APC, car il tenterait constamment d'invalidater certaines entrées et de mettre en cache de nouvelles si la RAM disponible est faible ou si le nombre de sites/fichiers PHP est très élevé (un cas courant dans l'hébergement mutualisé). Cela ne devrait pas poser de problème s'il y a suffisamment de RAM et que vous gardez un œil sur apc.php (la page d'informations d'APC).

En plus de cela, le bénéfice d'APC se fera sentir surtout sur des sites à trafic modéré/élevé, car la mise en cache des fichiers PHP rarement visités n'aurait pas beaucoup d'importance.

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