- Statut : non résolu
- Ce sujet contient 15 réponses, 3 participants et a été mis à jour pour la dernière fois par
, le il y a 18 années.
-
Messages
-
Bon le sujet est vaste, alors on va dire que je ne fais que le démarrer.
Que faire pour améliorer les perfs dans MU ?
A priori il y a 2 voies principales:
– setup des machines et du soft (apache php mysql)
– modifications de codecoté apache, pas grand chose à voir si on a un peu configuré le serveur proprement (maxclients etc.).
coté PHP, l’utilisation d’un cache semble judicieuse compte tenu de la quantité de code dans wordpress. Perso j’ai eu des problemes avec tous les softs de ce genre sur le fichier kses.php. Après une durée indéterminée et relativement aléatoire ou tout fonctionnait correctement, j’obtenais des segfaults, et tous les process HTTP plantaient, rendant le site innaccessible en quelques minutes/secondes. Cela le faisait avec EA et APC (pas essayé zend). Finalement j’ai gardé APC, qui a l’option de se désactiver sur des fichiers spécifiques, et j’ai simplement désactivé kses. Je n’ai pas effectué de comparaison à proprement parlé (meme si ca ne devrais pouvoir qu’etre plus rapide), mais je vais bientot pouvoir en faire une bien précise car un de mes serveurs presque remplis est encore en mode cgi/suphp (qui n’autorise pas le php cache) et je vais bientot le faire passer en mod_php+APC, je vous tiendrai au courant sur les différences observées.
coté mysql, le setup chez moi est relativement classique (on lui donne toute la ram dont n’a pas besoin le reste du serveur pour les indexes et le cache). Le seul truc un peu spécial c’est le nombre de tables que mysql peut ouvrir simultanément, assez élevé chez moi pour parer au fait qu’il y a énormément de tables dans MU.
coté code, il faut que je fasse quelque chose pour les requetes, mais je n’en ai encore pas eu l’occasion. 120 requetes pour le chargement d’une page, ca va pas. Je pense je vais customiser le code qui rapatrie les options, et d’une manière générale essayer de tendre vers un paradigme ou chaque table ne serait accédée qu’une fois par chargement de page.
en de mes gros objectifs pour très bientot c’est pour le chargement des images. MU est assezstupide pour mettre les images dans un folder dans le blogs.dir nommé par l’id du blog, moralité mod_rewrite ne peut s’en sortir tout seul, et faut passer par php+mysql, pour chaque image en plus puisque ce sont des requetes HTTP distinctes et que wordpress n’a pas de sessions. je vais donc migrer tous les directory depuis l’id du blog vers le nom du blog dans un premier temps, afin de pouvoir les servir via mod_rewrite directement. Peut etre à terme j’utiliserai un serveur HTTP léger, je connais bien mathopd et c’est impressionnant, sur big-boards.com j’arrive à servir des petits gifs à un taux qui avoisine les 40000 requetes par minute, et le process mange jamais plus de 20% du CPU
. Par contre passer sur un HTTP léger, ca introduit des problèmes supplémentaires (faut soit stocker les images à part, soit gérer les ports de manière spécifique), et quand on est derrière un apache en reverse proxy, ca sert à rien . Donc ca pour le moment c’est pas trop au programme de mon coté.enfin j’ai un petit problème de perfs introduit par le plugin de stats que j’ai développé pour unblog mais c’est un peu spécifique.
Voila pour un début, feedback welcome
.J’ai plusieurs questions.
Tu dispose d’une architecture sans redondance, tu poses combien de blogs maximum sur un serveur ?
(un rapide descriptif de la machine par rapport au nombres de blogs, sinon le chiffre veut pas dire grand chose)Je suis également attristé du nombre de requêtes sur une « fresh » install, plus de 40 pour l’affichage, le double d’un WordPress classique… pour des raisons pratiques, nous hésitons à porter WPmu sur pgSQL, il n’y a pas de gain de performance pure sur les requêtes, mais les fonctionnalités DBA, réplication, etc, sont extrêmement fiable. MySQL il parait que ça n’est pas du tout ca. Cas déjà envisagé ?
Pour le problème d’options, tu as tenté d’optimiser les thèmes en diminuant le nombre de « blog_settings » ? (passage en variable, etc)
Tu as déjà réalisé des essais avec le serveur web LiteSpeed ?
Leur benchmark sont très impressionnant, mais en pratique ?Avec Image Manager tu rencontre le même problème ?
« define(‘ENABLE_CACHE’,true); »
Je descend à 14 requêtes pour la home (30 requêtes en moins).
et 11 pourr le thème par défaut (38 en moins).C’est déjà mieux.
Tu l’utilise Quentin ? pour ton problème de requêtes ?
> Tu dispose d’une architecture sans redondance, tu poses combien de blogs maximum sur un serveur ?
honnetement j’ai pas fait de stats détaillées, la réponse à cette question dépend vraiment beaucoup de l’activité moyenne des blogueurs. Quand tu fais de l’hébergement gratuit, tu as pas mal de « déchet ». Les gens qui se sont planté de nom créent 3-4 blogs avant d’en choisir un, beaucoup en créent un pour essayer puis ne reviennent pas, l e degré d’investissement des utilisateurs est surement moindre que dans une plateforme payante (type lemonde) ou forcément les gens sont plus motivés et plus actifs. Donc sans corréler à un niveau d’activité le chiffre ne veut pas dire grand chose. Disons que par rapport au niveau d’activité sur unblog, j’ai environ 15000 blogs par machine (plusieurs genre de machines, mais la plupart des core2duo 2Gig de ram). Mais vraiment je ne peux pas dire que je monitore le nombre de blogs par machine proactivement, en gros quand MRTG dit que la machine commence à patauger, je déplace quelques blogs 😉.
Pour les options je crois que je vais modifier directement la fonction et la remplacer par une requete sur toutes les options, stockant le tout dans un cache php, qui sera lu par toutes les requetes suivantes. Sinon faudrait faire un audit de tous les themes+plugins, et je préfère traiter le problème à la source.
Pour litespeed, non je n’ai pas encore évalué cette option. J’ai du mal a comprendre comment il peut etre compatible avec des accelerateurs PHP alors qu’il ne marche qu’avec PHP en CGI et qu’aucun des accélérateurs ne supporte ce setup. Par ailleurs, l’investissement pour la version enterprise est nécessaire ce qui diminue l’intéret financier du gain de perf. Reste le gain de perf pur et son intéret pour l’utilisateur, mais je voudrais voir ce que ca donne vraiment vs un apache optimisé avec APC, car sinon le casse tete de la migration, et l’utilisation d’un soft avec lequel je suis pas super familier n’en vaudrait peut etre pas la chandelle. A voir quoi.
Pour imagemanager, a quel probleme fais tu allusion ? Je n’ai pas encore intégré le plugin dans mon environnement pour ma part.
non, pas eu le temps d’investiguer a fond le cache. J’ai vu des mentions de 3 types de cache différent, MU, WP_CACHE, et un autre, j’ai pas encore vraiment compris qui cachait quoi, de plus il semble que c’était pas mal buggué à un certain stade et ma nightly est assez vieille, donc je pense que je vais faire ca après la migration de MU. Tu sais exactement ce qui est caché et ou/comment avec cette option activée ?
« define(‘ENABLE_CACHE’,true); »
« var $global_groups = array (‘users’, ‘userlogins’, ‘usermeta’, ‘site-options’, ‘site-lookup’, ‘blog-lookup’, ‘blog-details’); »
En gros, toutes les infos, type blog_settings, et toute la gestion URL du blog DB/Serveur
Autant dire, un gros coup de pouce!
C’est fonctionnel sur la dernière nightly d’hier.Je pense qu’elle l’est depuis la version 1.1
http://trac.mu.wordpress.org/browser/tagsok donc ENABLED_CACHE (en tout cas dans les versions récentes) sert à cacher les infos du blog qui sont lues dans les tables génériques si je comprends bien c’est ca ?
J’ai déja entendu parler d’un cache au niveau des pages, est-ce que c’est une fonctionnalité de MU ou est-ce le plugin wp-cache ?
C’est le plugin WP-Cache
mais il n’est pas fonctionnel avec WPmuENABLED_CACHE
– les blog_settings des blogs
– et la base wp_blogs de WPmu, qui lie les ID, et les URL, etc.🙂
Salut,
puisque quentin a ouvert le bal, je vais me lancer. Tout d’abord je rappelle que pour moi le contexte est légèrement différent, mais que cette différence a une importance. Nos bloggueurs sont nécessairement des abonnés payant, ce qui implique que la croissance du nombre de blog est forcément plus limitée.
Nous avons d’abord envisagé des système de cache de bytecode Php mais non apc ni eaccelerator ne fonctionnaient correctement (segmentation faults). Nous avons donc laissé tombé. En y réfléchissant (pas longtemps) je me suis dit que dans un premier temp la faiblesse majeure de WPMU est que toutes les pages sont dynamiques. Je me suis donc attelé à un système de cache des pages HTML. Le but étant de ne plus subir de hausse de charge à cause du trafic en lecture. Seul le trafic d’édition des blog doit impacter la plate-forme.
La solution retenue est un reverse proxy squid entre l’internaute et les serveurs de blogs. Pour cela j’ai du d’abord m’atteler à segmenter les différentes blogs des pages pour les cacher individuellement. En effet décacher tout un blog à chaque nouveau commentaire en raison du widget « Recent Comments » est … dommage.
J’ai donc modifié les widgets de facon à ce qu’il soient servis en ajax, ainsi le code HTML de chaque widget ainsi que du corps de page est servi individuellement et caché individuellement par squid. J’ai donc rajouté des hooks sur toutes les action d’administration du blog modifiants ces blocs. Un exemple, la modification d’une note entraine le décache de :
– du widget note récentes
– du corps de page de la note
– des différentes pages d’archives contenant une référence à cette note.Voilà pour le html. Pour ce qui est des images, qui comme vous le disiez nécessitent un passage dans mod_rewrite, nous avons choisi de les Akamaiser (elle sont cachées par les proxy d’akamai pour 7 jours), j’ai juste modifié wordpress pour qu’il ajoute un timestamp sur toutes les images pour éviter tout problème lors de la mise à jour d’une image. Si nous n’avions pas disposé du service d’Akamaï, j’aurais utilisé squid en limitant la volumétrie pour éviter de stocker 2 fois tous les médias des blogs.
Le résultat de ces modification est que, je ne recois sur mes serveurs que très peu de requêtes sur des images et que pour les requêtes autres, 75% d’entre elles sont servies directement par squid. Je n’ai plus de pic de charge en raison du trafic en lecture (squid est ultra rapide), le seul paramètre qui augmente la charge sur la plate-forme est la modification/création (de note, commentaire…). Mais comme le nombre de blogs réellement actif est de l’ordre de 10%, la charge n’augmente qu’assez lentement en fonction du nombre de blogs.
Il me reste un dernier chantier, la modification de wp-cron.php, en effet, pour l’instant en raison de l’horodatage des notes, je ne cache la home du blog que 10minutes, ainsi l’horodatage est précis à 10 minutes. Je vais créer un script qui sera lancé par le démon cron qui lancera les décaches des article horodatés. Je pourrais ainsi cacher les home des blogs pour une durée illimité et atteindre, je pense, près de 90% de hit ratio sur squid.
Pour finir, nous avons rajouté la possibilité d’ajouter des serveurs de blogs dans notre ferme. Tous ces serveurs sont connectés à la même base Mysql (répliquée), des hooks assurent la synchronisation des répertoires d’upload des différents blogs. La scalabilité de la base n’est pour l’instant pas à l’ordre du jour car notre plateforme tourne très bien sur 2 machines dont chacune héberge : wpmu, squid et mysql (la maitre ou l’esclave). Nous avons encore la possibilité de déplacer mysql sur une 3eme machine. Le load average ne dépassant jamais 8 en pic et étant autour de 3 sur des bi-dualcore, nous avons le temps.
Pour ce qui est du cache WordPress, nous l’avons désactivé, car squid en faisait disparaitre l’intérêt.
Je précise que nous avons supporté sans problème des pics à plus de 150000pages/jours.
Voilà, en espérant avoir été clair.. un peu 🙂 !
En relisant vos post, je lisais ce que vous disiez sur wp_cache et pour moi ce n’est pas un cache de pages html mais d’objets issus de la base de donnée. C’est pourquoi, selon moi, il ne va pas assez loin et devient inutile derrière un cache de page HTML (ie Squid dans mon architecture).
heu je vais faire des petites réponses car j’aurai surement pas le temps de tout lire d’une traite.
Pour la remarque sur APC et les SegFaults, je les ai eu aussi. En fait, elles ne se produisent que sur un fichier (kses.php). Si tu désactives APC sur ce fichier, plus de problèmes. C’est pour ca que j’utilises APC et pas EA d’ailleurs, car EA ne permet pas d’etre désactivé juste pour un fichier.
Enfin tout ca pour dire que pour éviter les segfaults de wordpress avec apc, il suffit d’ajouter une ligne:
apc.filters kses.phpDans la config d’apc.
Le boost est monumental au niveau du temps de réponse des accès php, pour environ 40 megs de ram utilisés (sachant que tu gagnes en processing et que ca compense largement).
Bien sur vu que tu sembles avoir un cache statique en front, c’est probablement moins intéressant, mais je pense que meme seulement sur les mises à jour ca devrait se faire sentir.merci pour l’info je viens de tester, en 20 minutes je n’ai pas eu de segmentation faults, cela me semble très très prometteur! La charge des machines est maintenant aux alentours de 1 à 2 au lien de 2 à 4 !!! L’utilisation CPU semble avoir diminué de 10 ou 20% !
Même avec le cache de pages statiques, compte tenu du trafic en commentaires et posts, cela suffit à diminuer significativement la charge.Je suis ravi, bravo et merci Quentin !
Bonne nouvelle donc 🙂
Pour ma part, je suis un peu overbooké entre le lancement d’une plateforme de blog et les à cotés.
Je reviendrais donc dès la semaine prochaine, sur la méthologie que j’emploie, complètement différente de vous 2, avantages, inconvénient, etc 😉je reviens juste un peu sur le post d’olivier, je doit dire que je suis quand meme assez surpris de la solution d’ajaxiser les widgets. Outre les problèmes induits au niveau du support des différents browsers, ca me semble un frein certain à la qualité de l’indexation des blogs. En effet les robots ne voient pas les widgets, et donc pas les liens qu’ils contiennent… Bon maintenant peut etre que ce n’est pas hyper important pour lemonde, mais de mon coté le référencement est au coeur du business model, alors je ne me vois vraiment pas m’orienter vers ce genre de solution.
Olivier, je me demandais, n’étant pas moi meme subscriber au monde, y a-t-il un blog de test que je pourrais utiliser, juste pour regarder par curiosité ?
. Par contre passer sur un HTTP léger, ca introduit des problèmes supplémentaires (faut soit stocker les images à part, soit gérer les ports de manière spécifique), et quand on est derrière un apache en reverse proxy, ca sert à rien 
- Vous devez être connecté pour répondre à ce sujet.