Opcache et Prestashop comment le configurer

okom3pom

Bonjour,

Comment optimiser la configuration d'opcache pour prestashop ?

Merci

doekia

Le réglage par défaut de l'opcache (64M de mémoire et 4M de clé) est déjà relativement optimisé pour une Prestashop.

Lorsqu'il y a beaucoup de produits, catégories, modules il peut-être judicieux pour 1 Prestashop d'augmenter:
opcache.memory_consumption = XXX (XXX est une nombre en méga) 512 ça donne pas mal d'espace
opcache.interned_strings_buffer = YYY (YYY en méga est la zone réservé de XXX pour les clés 32 c'est énorme)
opcache.max_accelerated_files = ZZZ (par défaut 2000, c'est le nombre de fichier maximum caché 10000 c'est déja gigantesque)
opcache.revalidate_freq = T (en s, par défaut 2s que l'on peut facilement mettre à 5 ou 10s)

Attention dans le cas php-cgi mais aussi pfp-fm dans une moindre mesure, il existe un opcache par process. Donc il faut s'assurer que les php-cgi vivent assez longtemps pour avoir l'occasion de faire leur office et que si l'on admet 50 process, celà signifie 50 opcache différent.

Dans tous les cas les ralentissements de prestashop n'ont pas vraiment pour cause une lenteur du php, mais une manière de coder "risible" excutant des boucles inutiles à outrances et un codage de SQL digne d'un 3eme année de maternelle. Je dis cela car il ne faut pas s'attendre a des miracles de performances au travers de l'opcache (

okom3pom

Déjà il faut savoir que ce cache ne va pas mettre des données en stock mais les fichiers php en binaire; et dans prestashop il y en a des fichiers php et encore plus avec le cache smarty.

Donc déjà il va falloir déterminer combien de fichier il faut mettre en cache, je vous conseille donc de faire la commande suivante après un temps important sans avoir vidé le cache de prestashop :

find . -type f -print | grep .php | wc -l find . -type f -name '*.php' | wc -l ( doekia )

Cette commande va vous retourner le nombre de fichier php pour ma part je suis à + 40 000.

Ceci va nous permettre de configurer la variable suivante qui doit être un nombre premier ( liste des nombre premier )

opcache.max_accelerated_file 41777; // Exemple pour mon site

Il faut ensuite modifier :

opcache.revalidate_freq 0; // Nombre de seconde avant la revalidation du cache

opcache.validate_timestamps 0; // Permet de ne pas vérifier le timestamps des fichier ( Production seulement )

Ensuite il va falloir travailler sur la mémoire qu'on va laisser à opcache pour ça vous pouvez télécharger ici un script qui vous donnera des informations sur la mémoire utilisée par opcache.

Avec ce script vous allez pouvoir déterminer combien mémoire allouer à opcache les deux paramètres sont :

**opcache.memory_consumption 64; **// Valeur par défaut en M je l'ai personnellement réglé à 256
**opcache.interned_strings_buffer 8; **// Valeur par défaut en M je l'ai personnellement réglé à 32

Voilà après avoir configuré opcache avec ces variables, je sens une amélioration sur mon site, bon ce n'est pas non plus deux fois plus rapide comme dit ici mais il y a bien une amélioration.

Naturellement vous ne pourrez régler ces paramètres qu'avec votre propre serveur, ce qui me fait dire que les tests de l'article ci-dessus ont été fait sur une boutique avec 5 articles et que sur la page d'accueil et avec pas beaucoup de fichiers.

Un bon article pour comprendre tous les paramètres.

doekia

t'embêtes pas avec le nombre premier, opcache ajustera cette valeur au nombre premier directement supérieur au nombre que tu saisis. De par la doc on ne doit pas saisir de nombre supérieur à 100'000.

find . -type f -name '*.php' | wc -l c'est plus mieux

je suis personellement contre opcache.revalidate_freq et opcache.validate_timestamps à 0. Cela mène à beaucoup de complications en cas de changement de code pour un gain extrèmement minime. Augmente le revalidate_freq à 60 ou 600 tu auras sensiblement le même gain sans devoir redemarrer tout le bouzin pour corriger un bug

Le gain est vraiment visible avec beaucoup d'accès concurrents, mais il reste à la marge, dans 99% des cas les lenteurs sont soit SQL, soit les 47 boucles stupide de Cart et quelques autres pas piqués des vers

okom3pom

Merci pour ces éclaircissements.

Je reste également persuadé que ce n'est pas la cause de la lenteur de prestashop, mais vu la lenteur à cause des boucles c'est toujours bon à prendre.

okom3pom

Quand j'ai passé ces paramètres à 0 je me suis dis je sens qu'un jour j'allais devenir fou car mes modifs ne seront pas prise en compte, je vais sûrement suivre tes conseilles pour le revalidate_freq