Nettoyage de code
Par Laurentj le lundi, mars 5 2007, 13:03 - Projets - Lien permanent
Depuis quelques jours, le serveur mysql de l'Apinc connait de fort ralentissement. C'est bien simple, il croule sous les requêtes, à cause du nombre de site grandissant, du trafic augmentant, mais aussi à cause de requêtes trop gourmandes. Et pour certaines trop trop gourmandes. À tel point que mysql a fini par faire grêve ce week-end. Plus rien. Nada.
Mat (le même que celui d'openweb), admin système à ses heures à l'Apinc, observe depuis quelques semaines ces problèmes. Il est depuis passé à l'action : il essaye de contacter les propriétaires des sites fautifs pour qu'ils essayent d'optimiser un peu leur code, qu'ils arrêtent de faire des requêtes pourries. Peine perdue pour certains d'entre eux : ils ne sont pas développeurs et utilisent des trucs comme spip, phpbb et autres softs prêts à l'emploi souvent codés avec les pieds au niveau SQL. Et puis il y a d'autres webmestres qui ont fait leur site à la main, qui eux peuvent donc améliorer leurs scripts pourries. Et j'en fait parti.
J'ai en effet mon site sur tahiti chez l'apinc, un truc développé en 2001 pour la plus grosse partie, et peu retouché depuis. Autant vous dire que le code date ! Aprés donc m'être fait taper sur les doigts avoir été averti par Mat, je me suis replongé dans mes antiquités PHP, et j'avoue que c'est assez effrayant de se relire 5-6 ans après. Je vous passerai les détails tellement j'ai honte :-). Bon aller, si, assumons : du genre des index manquants, des GROUP BY et autres jointures dans tous les sens alors qu'avec un peu d'astuce, cela peut être évité (un peu de duplications d'infos peut être plus intéressants finalement que de faire des requêtes hyper complexes), récupérations de listes partielles d'enregistrements sans utiliser le mot clé LIMIT etc...
Et donc j'ai passé mon temps libre ce week-end à reprendre tout ça, à faire du nettoyage. En espérant que cela puisse contribuer à diminuer la charge du serveur mysql de l'apinc :-)
PS : au passage, je recherche un webdesigner bénévole qui serait volontaire pour rafraîchir un peu le design de mon site tahiti-fenua.
Commentaires
Mmmm, Spip a un système de cache des pages très efficace qui fait que justement il est assez léger côté SQL. Encore faut-il activer ce cache bien sûr, pareil pour phpBB. je pense que déjà si tous les utilisateurs cochaient la petite case "cache" de leur CMS favori, ça améliorerait bien les choses :)
Exact, mais lors de l'affichage d'une page, il reste quand même des requêtes, en particulier celles liées à l'enregistrement de statistiques &cie. Avec les spammeurs, ça devient critique : voir cet autre billet de l'apinc.
Bon et puis je ne comprend pas pourquoi le cache ne serait pas activé par défaut :-)
Le fait d'avoir un cache efficace (ce qui est très, très discutable dans le cas de SPIP, si vous voulez mon avis) n'empêche en rien SPIP d'être très lourd en SQL... Ca s'arrange dans la dernière version, mais il reste plein de problèmes (en particulier dans la partie "forum/commentaires", l'admin, qui n'utilise pas trop de cache visiblement, et comme le signale laurent, dans les statistiques) et surtout plein de SPIP pas à jour chez APINC, hélas...
Si je puis de permettre de lancer (en mon nom personnel) un appel, tout idées ou conseils en matière de php ou de base de données pour accélérer SPIP sont les bienvenus dans spip-dev@rezo.net.
"(un peu de duplications d'infos peut être plus intéressants finalement que de faire des requêtes hyper complexes)" C'est contraire à toutes les bonnes pratiques sur les bases de données. Si il y a des requêtes complexes que tu utilises souvent, fais-en des vues.
oui et non. Il faut savoir parfois laisser de coté son purisme quand une solution moins pure permet de gros avantages en performances.
Un exemple, dans le forum, j'affiche la liste des discussions avec leur libellé et le nombre de réponses correspondant pour chacune. Avant, j'avais donc une belle requête bien "complexe" avec group by et tout pour récupérer via un count le nombre de réponse en même temps que les infos propres à la discussion. Maintenant, j'ai rajouté un champs "nombre de reponse" dans les enregistrements, que j'incrémente à chaque fois qu'une nouvelle réponse est postée, et cela m'évite une jointure et un group by pour afficher la liste des discussions.
Ce genre d'astuce n'est pas ce qu'il y a de plus "crade", et ça permet de vraiment gagner en performance (surtout sur des grosses tables)
Bon déjà, avec mysql 4, c'est pas gagné (il ne connait pas les vues ;-), ce n'est dispo que depuis la version 5.1) et puis de toute manière, tu as beau cacher une grosse requête complexe derrière une vue, il n'en reste pas moins que ce sera toujours un processus plus complexe et moins performants pour récupérer les résultats que de faire un SELECT simple sans vue avec quelques duplications d'infos.
Salut,
Il faut vraiment tout miser sur du cache ou des imports XML si vous voulez gagner en rapidité.
Pour ton site sur Tahiti, au lieu de le "redesigner" tu préféres pas l'enlever ?
@ronaldhino
mais oui bien sûr, je vais mettre en cache des milliers de discussions...
Mouahahah ! encore mieux :-)
non mais franchement, c'est pas serieux ce que tu dis...
Non. C'est pas sympa de dire ça. Je t'emmerde.