•  08-06-2019
  •  | 
  •  

Question

Quelqu'un a-t-il de l'expérience avec des accélérateurs PHP tels que MMCache ou Accélérateur Zend?J'aimerais savoir si l'utilisation de l'un ou l'autre rend PHP comparable à plus rapide technologies Web.De plus, y a-t-il des compromis à faire pour les utiliser ?

Était-ce utile?

La solution

Notez que Zend Optimizer et MMCache (ou des applications similaires) sont des choses totalement différentes.Pendant que Zend Optimizer essaie d'optimiser l'opcode du programme, MMCache mettra en cache les scripts en mémoire et réutilisera le code précompilé.

J'ai fait quelques benchmarks il y a quelque temps et vous pouvez trouver le résultats sur mon blog (en allemand cependant).Les résultats de base :

Zend Optimizer seul n'a pas aidé du tout.En fait, mes scripts étaient plus lents que sans optimiseur.

En ce qui concerne les caches :* le plus rapide: eAccelerator * XCache * APC

Et:Vous VOULEZ installer un cache d'opcode !

Par exemple:texte alternatif http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png

C'est le temps qu'il a fallu pour appeler 10 000 fois la page d'accueil de WordPress.

Modifier: BTW, eAccelerator contient lui-même un optimiseur.

Autres conseils

MMCache est obsolète.Je recommande soit http://pecl.php.net/package/APC ou http://xcache.lighttpd.net/, qui vous offrent tous deux également un stockage variable (comme Memcache).

Les deux sont intéressants et permettront d’accélérer puisqu’ils compilent le code source en représentation binaire qui est ensuite exécutée par le moteur PHP.

Tout grand site Web fonctionnant avec PHP (Facebook par exemple) exécute une sorte de système de cache d'opcodes comme MMCache.

Le problème est qu’ils ne sont pas très simples à mettre en place en fonction de votre système.

En fonction de la quantité de code PHP réellement exécutée et de la durée de cette exécution, cela peut être une très grosse victoire.Cela ne fera certainement pas de mal, mais le gain que vous constaterez dépendra beaucoup de l'endroit où vous passez actuellement votre temps.

d'ailleurs, mmcache a été intégré dans un projet différent maintenant, j'ai oublié le nom mais Google vous le dira.

J'utilise APC sur mes serveurs de production et cela fonctionne plutôt bien dès le départ.Compilez-le et ajoutez-le à PHP et il n'y a plus grand chose à faire.Je le vérifie de temps en temps juste pour consulter les statistiques, mais comme j'utilise beaucoup MVC, tous les fichiers principaux (routeurs, contrôleurs, etc.) changent rarement au quotidien afin que le code reste compilé et s'exécute assez efficacement. .

actuellement, nous utilisons apc, gratuitement et ce n'était qu'un simple plug and play sur nos serveurs en direct.Fourni une énorme augmentation des performances de notre site, d’autant plus que la taille du projet augmentait.J'ai également désactivé apc.stat afin qu'il ne vérifie pas si le code a été mis à jour. Ainsi, chaque fois que nous devons mettre à jour le code sur le site en direct, nous redémarrons Apache.

J'utilise APC et je peux attester qu'il peut réduire considérablement la charge du processeur et des E/S sur un serveur d'applications si vous maintenez un taux d'accès au cache élevé.Cela vous évite non seulement d'avoir à compiler, mais également d'avoir à lire les fichiers php à partir du disque.(c'est à dire.les bytecodes sont servis directement à partir de la mémoire principale, donc c'est super rapide) Cela réduit la vitesse de rendu d'une seule page et augmente les requêtes par seconde que votre serveur peut gérer.

Si vous utilisez RedHat ou CentOS, installer APC est très simple :

yum install php-devel httpd-devel php-pear
pecl install apc 
echo "extension=apc.so" > /etc/php.d/apc.ini
# if you're using SELinux:
chcon "system_u:object_r:textrel_shlib_t" /usr/lib/php/modules/apc.so
/etc/init.d/httpd restart

Vous avez posé des questions sur les inconvénients.Le seul inconvénient est qu'il nécessite un peu de mémoire.La valeur par défaut sur APC est de 30 Mo, mais elle peut être ajustée, et le coût d'un peu de mémoire est plus que rentabilisé grâce à l'augmentation de la vitesse et du taux de réponse.

Les tests de BlaM incluaient tous les appels DB effectués par WordPress.Lorsque vous effectuez moins d'appels à la base de données, vous constaterez que le gain de performances des caches d'opcodes est encore plus spectaculaire.

J'ai utilisé Zend Accelerator un peu à l'époque (2004-ish).Cela a certainement donné des gains de performances significatifs sur le code avec lequel il pouvait fonctionner, mais malheureusement, le système que j'utilisais était conçu pour charger assez souvent dynamiquement du code puis l'évaluer, ce avec quoi Zend Accelerator ne pouvait pas faire grand-chose à l'époque (et je' Je suppose que je ne peux toujours pas).

En revanche, nous avons certainement constaté des problèmes de mise en cache (où le code serait modifié, mais la version compilée se synchroniserait avec le changement pour une raison ou une autre).J’imagine que ces problèmes ont probablement été résolus maintenant.

Quoi qu'il en soit, je n'ai pas de chiffres de comparaison précis et je n'ai certainement pas écrit le même système dans différents environnements à des fins de comparaison, mais pour la grande majorité des systèmes, PHP ne va pas vous tuer en termes de performances.

Avez-vous vérifié Phalanger?Il compile PHP en code .NET.Voici quelques repères ce qui montre qu’il peut améliorer considérablement les performances.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top