Cache PHP / Cache d'opcode

14 réponses

Auteur	Message
Julgates \| Administrateur Inscrit le : 09/03/2005	# Le 27/09/2008 à 12:26 Bonjour WiWiCi, Après une petite discussion avec Bool, je me suis rendu compte que je n'utilisais plus de cache d'Opcode depuis des années maintenant. A l'époque j'étais sous eAccelerator (qui s'appelait TurkMMCache) et je teste en ce moment Xcache qui me sort de bonnes perfs (utilisation mémoire divisée par 2 au moins) Et vous vous utilisez quoi ? (Message édité le 27-09-2008 à 12h51 par Julgates) Shopping Time Network - Founder / CTO
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 27/09/2008 à 12:45 J'utilise ioncube sur BT Mais avec la migration vers le nouveau serveur (un dual xeon quad core avec 8Go de ram), je ne suis pas sur que je vais le remettre Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 27/09/2008 à 12:53 Nous c'est eaccelerator partout depuis quelques annees maintenant. Ca marche tellement bien qu'on s'est meme pas posé la question de savoir si quelque chose de mieux existait, ca repond parfaitement a nos besoin comme c'est actuellement. Avec l'augmentation de puissance des serveurs, c'est plus réellement un probleme de ce coté la, donc les optimisations ont beaucoup moins besoin d'etre poussees jusqu'au bout, on peut se concentrer sur d'autres choses
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 27/09/2008 à 12:53 En fait c'est en migrant sur un Quadcore que je me suis rendu compte. Je ne sais pas pourquoi mais avec les mêmes services et versions (apache 1.3 ; php 5) le quadcore utilise 2x + de RAM pour un même site que mon vieux bi P4. Vraiment bizarre. Shopping Time Network - Founder / CTO
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 27/09/2008 à 13:21 Y a pas un cache php d'office avec les dernières versions php et apache d'ailleurs ? Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 27/09/2008 à 13:33 PHP APC C'est ultra-performant, mais par contre parfois ça fait planter php sans trop de raisons ... Mais chez nous, on est montée a 5000 query/s dessus sans problème et on a bien vu la différence niveau charge serveur. @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/09/2008 à 13:42 devtribu : APC sera très probablement intégré à PHP 6 oui. Mais pour le moment il n'y a rien de ce genre. Par contre de ce que j'ai compris sur la mailing list la phase de compilation de PHP est de plus en plus "lourde" afin de mieux tirer partie des caches d'opcode. Ce qui veut dire que si on en utilise pas c'est lent daevel : infogérance et conseil \|\| moi
mirage \| Vincent Modérateur Inscrit le : 04/05/2005	# Le 27/09/2008 à 13:50 APC aussi car il sera intégré nativement à PHP6 et qu'il est disponible en paquet Pear donc ça s'upgrade facilement. Il propose aussi une fonctionnalité sympa pour l'upload de fichiers avec un suivi de la progression, ça bouffe pas grand chose et c'est pratique pour dire à l'internaute où ça en est sur les fichiers lourds Par contre, il n'aime pas bien le patch de sécurité Suhosin, j'ai eu pas mal de problème avec (les pages en cache s'emmêlaient, c'est Bool et Dob qui avaient trouvé que ça venait de Suhosin).
petitnuage \| Sam Membre Inscrit le : 20/11/2008	# Le 26/11/2008 à 14:31 J'avais utilisé eAcceleartor et j'en étais très satisfait. Depuis un an, je suis passé à APC du fait de son intégration à venir dans PHP 6. J'en suis très satisfait, même si la documentation — très sommaire — sur la mémoire partagée ne correspond pas à la réalité, sur une Debian Etch (j'utilise un gros bloc de 512 Mo pour APC alors que d'après la documentation, je devrais avoir 16 blocs de 32 Mo, mais passons). En matière de performances, sur les ML d'OVH, quelqu'un avait donné des résultats de tests qui montraient qu'un très gros goulet d'étranglement vise le changement d'utilisateur lié à suPHP. Du coup, sur mon serveur, j'utilise PHP brut en module, histoire de ne pas être ralentit uniquement, car je n'héberge que des sites de confiance, donc les problèmes de sécurité que cela implique (un site peut accéder aux fichiers des autres sites) sont limités.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 26/11/2008 à 15:57 Il me semble que par défaut APC utilise MMAP et non SHM, ce qui expliquerait pourquoi il se fout complètement de cette limite de 32Mo. Mais même si c'était le cas ça se modifie à la volée, comme expliqué dans la doc ... de eAccelerator . Après pour l'aspect sécurité, le suPHP pour moi sert surtout à limiter l'étendu des dégats en cas de faille dans un site : c'est déjà assez "chiant" qu'un pirate infiltre un site, je n'ai pas spécialement envie qu'il se propage sur tous les sites de la machine. Idem pour les scripts "annexes" tels que phpmyadmin envers lesquels je n'ai absolument aucune confiance et que je préfère donc isoler au maximum. Pour ce qui est du choix entre la sécurité "suPHP" et les performances "modPHP", il reste une troisième alternative : le trio suExec/fastCGI/cgiPHP. daevel : infogérance et conseil \|\| moi
petitnuage \| Sam Membre Inscrit le : 20/11/2008	# Le 27/11/2008 à 20:26 Ce qui prend des ressources, semble-t-il, ce n'est pas tant suPHP, mais le fait de devoir changer de contexte/utilisateur. Par conséquent, je pense que les performances doivent être sensiblement équivalentes entre suPHP et suExec/FastCGI/cgiPHP. Il faudrait éventuellement voir comment sont gérés les contextes avec des systèmes de virtualisation, de sorte à créer des machines virtuelles, une pour chaque site ou groupe de sites.
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/11/2008 à 20:35 Non, grace à fastcgi ce changement de contexte n'est fait que toutes les 500 exécutions, et les processus sont "pré-forkés" de la même manière qu'un Apache utilisant le mpm-prefork (celui utilisé avec modPHP justement). L'impact sur les perfs est donc quasi nul, et compensé par un gain de perfs sur les fichiers statiques et une consommation mémoire bien moindre. Ne t'en fais pas, avant de basculer tous les serveurs là dessus j'ai fait un minimum de test... EDIT : les chiffres sont peut être plus parlants, pour un site avec un "prefork" à 16 et sur l'ensemble de la journée d'hier (c'est à dire plus d'1.3 Millions de hits PHP, il y a eu en tout et pour tout 271 "changements de contexte"). (Message édité le 27-11-2008 à 20h56 par Bool) daevel : infogérance et conseil \|\| moi
petitnuage \| Sam Membre Inscrit le : 20/11/2008	# Le 27/11/2008 à 21:57 Bool a dit : EDIT : les chiffres sont peut être plus parlants, pour un site avec un "prefork" à 16 et sur l'ensemble de la journée d'hier (c'est à dire plus d'1.3 Millions de hits PHP, il y a eu en tout et pour tout 271 "changements de contexte"). Donc un changement tous les 4.794 hits PHP. Pas mal. J'en prends bonne note ! :-)
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/11/2008 à 22:08 Tout dépend du nombre du processus configurés en "prefork", j'ai mis 16 de manière un peu arbitraire, mais 64 serait peut être plus adapté à ce cas ci. daevel : infogérance et conseil \|\| moi
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 27/11/2008 à 22:15 Je capte rien du tout Shopping Time Network - Founder / CTO

Auteur

Message

Inscrit le : 09/03/2005

# Le 27/09/2008 à 12:26

Bonjour WiWiCi,

Après une petite discussion avec Bool, je me suis rendu compte que je n'utilisais plus de cache d'Opcode depuis des années maintenant.

A l'époque j'étais sous eAccelerator (qui s'appelait TurkMMCache) et je teste en ce moment Xcache qui me sort de bonnes perfs (utilisation mémoire divisée par 2 au moins)

Et vous vous utilisez quoi ?

(Message édité le 27-09-2008 à 12h51 par Julgates)

Shopping Time Network - Founder / CTO

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 27/09/2008 à 12:45

J'utilise ioncube sur BT
Mais avec la migration vers le nouveau serveur (un dual xeon quad core avec 8Go de ram), je ne suis pas sur que je vais le remettre

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 27/09/2008 à 12:53

Nous c'est eaccelerator partout depuis quelques annees maintenant. Ca marche tellement bien qu'on s'est meme pas posé la question de savoir si quelque chose de mieux existait, ca repond parfaitement a nos besoin comme c'est actuellement.

Avec l'augmentation de puissance des serveurs, c'est plus réellement un probleme de ce coté la, donc les optimisations ont beaucoup moins besoin d'etre poussees jusqu'au bout, on peut se concentrer sur d'autres choses

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 27/09/2008 à 12:53

En fait c'est en migrant sur un Quadcore que je me suis rendu compte. Je ne sais pas pourquoi mais avec les mêmes services et versions (apache 1.3 ; php 5) le quadcore utilise 2x + de RAM pour un même site que mon vieux bi P4. Vraiment bizarre.

Shopping Time Network - Founder / CTO

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 27/09/2008 à 13:21

Y a pas un cache php d'office avec les dernières versions php et apache d'ailleurs ?

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 27/09/2008 à 13:33

PHP APC

C'est ultra-performant, mais par contre parfois ça fait planter php sans trop de raisons ...

Mais chez nous, on est montée a 5000 query/s dessus sans problème et on a bien vu la différence niveau charge serveur.

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/09/2008 à 13:42

devtribu : APC sera très probablement intégré à PHP 6 oui. Mais pour le moment il n'y a rien de ce genre.

Par contre de ce que j'ai compris sur la mailing list la phase de compilation de PHP est de plus en plus "lourde" afin de mieux tirer partie des caches d'opcode. Ce qui veut dire que si on en utilise pas c'est lent

daevel : infogérance et conseil || moi

mirage | Vincent
Modérateur

Inscrit le : 04/05/2005

# Le 27/09/2008 à 13:50

APC aussi car il sera intégré nativement à PHP6 et qu'il est disponible en paquet Pear donc ça s'upgrade facilement. Il propose aussi une fonctionnalité sympa pour l'upload de fichiers avec un suivi de la progression, ça bouffe pas grand chose et c'est pratique pour dire à l'internaute où ça en est sur les fichiers lourds

Par contre, il n'aime pas bien le patch de sécurité Suhosin, j'ai eu pas mal de problème avec (les pages en cache s'emmêlaient, c'est Bool et Dob qui avaient trouvé que ça venait de Suhosin).

petitnuage | Sam
Membre

Inscrit le : 20/11/2008

# Le 26/11/2008 à 14:31

J'avais utilisé eAcceleartor et j'en étais très satisfait. Depuis un an, je suis passé à APC du fait de son intégration à venir dans PHP 6. J'en suis très satisfait, même si la documentation — très sommaire — sur la mémoire partagée ne correspond pas à la réalité, sur une Debian Etch (j'utilise un gros bloc de 512 Mo pour APC alors que d'après la documentation, je devrais avoir 16 blocs de 32 Mo, mais passons).

En matière de performances, sur les ML d'OVH, quelqu'un avait donné des résultats de tests qui montraient qu'un très gros goulet d'étranglement vise le changement d'utilisateur lié à suPHP. Du coup, sur mon serveur, j'utilise PHP brut en module, histoire de ne pas être ralentit uniquement, car je n'héberge que des sites de confiance, donc les problèmes de sécurité que cela implique (un site peut accéder aux fichiers des autres sites) sont limités.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 26/11/2008 à 15:57

Il me semble que par défaut APC utilise MMAP et non SHM, ce qui expliquerait pourquoi il se fout complètement de cette limite de 32Mo. Mais même si c'était le cas ça se modifie à la volée, comme expliqué dans la doc ... de eAccelerator .

Après pour l'aspect sécurité, le suPHP pour moi sert surtout à limiter l'étendu des dégats en cas de faille dans un site : c'est déjà assez "chiant" qu'un pirate infiltre un site, je n'ai pas spécialement envie qu'il se propage sur tous les sites de la machine. Idem pour les scripts "annexes" tels que phpmyadmin envers lesquels je n'ai absolument aucune confiance et que je préfère donc isoler au maximum.
Pour ce qui est du choix entre la sécurité "suPHP" et les performances "modPHP", il reste une troisième alternative : le trio suExec/fastCGI/cgiPHP.

daevel : infogérance et conseil || moi

petitnuage | Sam
Membre

Inscrit le : 20/11/2008

# Le 27/11/2008 à 20:26

Ce qui prend des ressources, semble-t-il, ce n'est pas tant suPHP, mais le fait de devoir changer de contexte/utilisateur. Par conséquent, je pense que les performances doivent être sensiblement équivalentes entre suPHP et suExec/FastCGI/cgiPHP. Il faudrait éventuellement voir comment sont gérés les contextes avec des systèmes de virtualisation, de sorte à créer des machines virtuelles, une pour chaque site ou groupe de sites.

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/11/2008 à 20:35

Non, grace à fastcgi ce changement de contexte n'est fait que toutes les 500 exécutions, et les processus sont "pré-forkés" de la même manière qu'un Apache utilisant le mpm-prefork (celui utilisé avec modPHP justement). L'impact sur les perfs est donc quasi nul, et compensé par un gain de perfs sur les fichiers statiques et une consommation mémoire bien moindre.

Ne t'en fais pas, avant de basculer tous les serveurs là dessus j'ai fait un minimum de test...

EDIT : les chiffres sont peut être plus parlants, pour un site avec un "prefork" à 16 et sur l'ensemble de la journée d'hier (c'est à dire plus d'1.3 Millions de hits PHP, il y a eu en tout et pour tout 271 "changements de contexte").

(Message édité le 27-11-2008 à 20h56 par Bool)

daevel : infogérance et conseil || moi

petitnuage | Sam
Membre

Inscrit le : 20/11/2008

# Le 27/11/2008 à 21:57

Bool a dit :
EDIT : les chiffres sont peut être plus parlants, pour un site avec un "prefork" à 16 et sur l'ensemble de la journée d'hier (c'est à dire plus d'1.3 Millions de hits PHP, il y a eu en tout et pour tout 271 "changements de contexte").

Donc un changement tous les 4.794 hits PHP. Pas mal. J'en prends bonne note ! :-)

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/11/2008 à 22:08

Tout dépend du nombre du processus configurés en "prefork", j'ai mis 16 de manière un peu arbitraire, mais 64 serait peut être plus adapté à ce cas ci.

daevel : infogérance et conseil || moi

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 27/11/2008 à 22:15

Je capte rien du tout

Shopping Time Network - Founder / CTO

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.