Optimisation serveur : nginx + eaccelerator + vanish

Je préfère APC que eaccelerator car il semblerait que APC sera fourni de base avec PHP6.
Et c'est super simple à installer sur Debian (Lenny):

Code:

apt-get install php-apc
/etc/init.d/apache2 restart

 

Oui APC est vraiment *le* truc à mettre: compatible avec tout.
J'essaye de faire des benchs chez tous les clients où j'ai l'occasion d'installer ça, voilà quelques résultats:

PHPMyAdmin (exemple typique d'un "gros" truc PHP)

Code:

Sans APC : Requests per second:    140.60 [#/sec] (mean)
Avec APC : Requests per second:    475.25 [#/sec] (mean)
Avece APC - Suhosin : Requests per second:    492.85 [#/sec] (mean)

Wordpress

Code:

Sans APC : Requests per second:    27.37 [#/sec] (mean)
Avec APC : Requests per second:    49.94 [#/sec] (mean)

Pour nginx il faut surtout faire attention aux rewrites qui sont un peu long à convertir.

 

Installer cette ribambelle d'optimisations ça a bien des effets négatifs aussi non ? ce n'est que bénéfique donc ? ^^ Genre ça doit consommer à mort de ram ( a part pour lighthttpd ) et au final il y a plus de risques de swap s'il y a moins de ram dispo ? A partir de quel moment a-t-on réellement besoin de ces optis ? Ca me titille de tester tout ça mais bon, debian uptime de 250jours, aucun souci de vitesse ou perf, je suis malade moi :lol:

 

eaccelerator + varnish là oui c'est "trop".

Il faut faire un choix, "cacher" a un coup surtout au premier affichage.
Après cacher dans la RAM (memcache par exemple) a un coup en RAM, mais soulage le disque, donc tout dépends "où" on est "radin": pas beaucoup de RAM, on va éviter, beaucoup de RAM et disques lents, autant le faire.

Il faut faire des benchs en utilisation "normale". Une page qui est vue une fois par jour, n'a pas forcément besoin d'être en cache.
Dans les trucs sans risques et rentable c'est réellement du APC et du Nginx ou Lighttpd.
MySQL a aussi un cache par défaut, performant.

 

Tiens je remonte ce topic, après avoir testé APC sur mon new serveur, rox du poney

Et sous le dernier debian, juste une commande pour l'installer sans devoir tout compiler comme l'a dit spout ^^

Code:

apt-get install php-apc

 

S'il y a "pas mal de sites" il faut un chouillat configurer :

Code:

 cat /etc/php5/conf.d/apc.ini
; configuration for php apc module
extension=apc.so
apc.max_file_size = 8M
apc.shm_size = 384M

surtout le shm size qui par défaut est à 16Mo ça fait un ou deux sites de quelques Mo.

 

La j'ai 30M par défaut, mais oui je compte bien augmenter la taille en fonction de l'utilisation des ségments. Surtout avec 16Go de ram, je sais pas ce que je vais en faire =D.

Le truc c'est qu'il ne met qu'en mémoire les fichiers .php c'est tout. Tous les fichiers caches enregistrés en .html il ne les mettra pas en cache donc ? Ca serait pas interessant de changer l'extension des fichiers caches vers .php pour que APC les prennent en compte ?

 

Pour vérifier l'état de la mémoire, il faut décompresser: /usr/share/doc/php-apc/apc.php.gz
Et le copier là où il sera accessible via le serveur Web.

 

Oui, j'avais oublié de le dire ^^ Bien utile ce petit script php !
Sinon une idée pour les fichiers caches ?

 

C'est du cache d'opcode: http://julien-pauli.developpez.com/tutoriels/php/apc/

Si les fichiers .html sont parsés avec PHP (addtype application x-httpd-php .html) je pense que le PHP exécuté dedans sera mis en cache.

 

Non pas de php dans les fichiers html chez moi. Mais si un fichier ne contient pas de code php à exécuter mais possède l'extension php. Aucun avantage donc à utiliser APC dessus ? Ou il ne pourra même pas ? J'vais faire un ti test ^^

EDIT: Oui on dirait que le fait de juste changer l'extension sans même qu'il y ait de code php à l'intérieur du fichier le met en cache avec APC. Maintenant reste à savoir si c'est rentable de laisser gérer les fichiers statics de cache avec APC ou les laisser sans extension, ou .html, peu importe. APC pourrait éviter des accès disques pour récupérer les fichiers cache ? J'hésite

 

A mon avis pas rentable.
Le gros avantage d'APC dans ce cas est qu'il "saura" où aller chercher le cache sans compiler toutes les merdes.

 

Tiens en passant faut mettre le paramètre sans le M (apc.shm_size = 384M)
Comme ceci : apc.shm_size = 384
Sinon on se tape une belle erreur [apc-error] apc_mmap: mmap failed: Cannot allocate memory

 

Pas si tu as une version à jour
Dans "ma version" (APC 3.1.7, PHP 5.3.6) si tu le mets pas tu te payes un warning

 

Je passe par les paquets debian, j'espère qu'ils feront la maj très bientôt ^^

 

Tu devrais ajouter les paquets dotdeb tu aurais des paquets lamp à jour

 

Si ils sont stables pourquoi n'y sont-ils pas par défaut alors ?

 

Parce que c'est la stratégie debian: on attends un moment pour être sûr que c'est stable de chez stable mais du coup, par défaut les versions sont très vielles.

 

T'as jamais eu de soucis avec le dotdeb ? J'vais chercher de la lecture à ce sujet histoire de changer d'avis ^^

 

J'peux pas edit
Voila j'ui passé a la 3.1.9
J'ai du d'abord virer le paquet php-apc et installer php5-apc ^^

 

"Curieusement" jamais.
Le gars (un français en plus, alors autant en profiter) fait vraiment bien son boulot et quand il y a une update il a fait les tests.
Généralement tu as 2/3 jours de décallage avec la version officielle car il fait quand même gaffe que des gros bugs n'apparaissent pas.

@Yoyos oui (je te conseille de le suivre sur Twitter si tu t'y mets) c'était dans le but d'uniformiser le tout

 

Voila c'est fait ^^ C'était @Dotdeb j'imagine .
Sinon c'est marrant le Hit d'apc: 99.9% xD

 

Sinon j'viens de céder j'ai installer nginx , c'est surement psychologique mais j'ai l'impression que j'ai page s'affiche trop vite =D
Après quelques tests sur ma box de test, tout s'est bien passé !

Merci à tous pour ce beau topic !!

 

A mon avis ce n'est pas psychologique

Félicitation en tout cas d'avoir sauté le pas
Tu utilises bien PHP en FPM ? (sinon c'est peut-être la prochaine étape )

 

je sais pas ce que c'est Je l'utilise juste pour les fichiers statics pour le moment. ^^ J'irai faire un tour pour voir ce que c'est ce fameux php-fpm ^^

 

Tiens par curiosité je viens de tester mes redirections avec l'outil de wri et j'ai une petite erreur 400 badrequest. https://www.webrankinfo.com/outils/header.php?url=http://tutomaker.com/
Tu vois pas d'où ça peut venir ? C'est suite à l'installation de nginx, mais comment identifier le problème C'est ptet aussi l'outil qui bug ? Parce que dans le navigateur en tout cas je suis bien redirigé.

Quelqu'un aurait une idée pour corriger cela ?

 

Tes logs te disent quoi ?

 

J'ai juste ça dans l'access log d'apache :

Code:

194.146.226.133 - - [22/Jun/2011:16:16:06 +0200] "HEAD / HTTP/1.0" 301 204 "-" "-"

Et rien dans les logs nginx vu qu'il a passé la requête a apache2 il me semble ^^
Si t'as un site avec un combo Apache+Nginx avec Apache qui gère la redirection, tu peux tester l'outil aussi ?

 

J'ai pas encore fini les améliorations de perf mais voila un peu le graphe après que le cache ait été généré, c'est hallucinant ^^ tombé a 52ms le téléchargement d'une page ^^

Temps de téléchargement d'une page (en millisecondes):