Le 27 juil. 2010 à 23:18, frantishrek a écrit : > J'ai vu passé des news sur xhprof mais je ne l'ai pas testé. > D'après ce que j'en ai vu, cela semble être un xdebug (développé par > facebook) un peu mieux foutu dont les traces sont un peu moins > verbeuses. > Ca s'installe sur un serveur de prod' ? Quelqu'un a testé ?
Ca tourne sur un de mes serveurs de prod (plateforme d'une petite cinquantaine de serveurs). 1 frontal (sur 20) a l'extension loadée, et le code déclenche xhprof entre une fois toutes les 1000 requêtes (mon objectif est d'avoir une trace toutes les 10 à 30 secondes). Un script tourne toutes les nuits pour aggréger les données de la journée, et générer un rapport sur le top du jour (cpu, mémoire), et faire un delta avec J-1 et J-7. C'est *très* rustique par rapport à ce que Facebook fait (ils ont couplé ça avec une vraie interface de reporting, avec de beaux graphes, et un mécanisme d'alerting). Globalement : - oui ça a un léger impact sur la charge du serveur, (j'allais mettre "impact sensible", mais en reprenant mes courbes cpu/mémoire/load/requêtes http, je m'aperçois que l'impact est inférieur à 10% en mode nominal, donc pas si important que ça - à revalider avec une charge importante), - pour ce qui est du temps de génération des pages, aucun impact n'apparait sur mes graphes de prod ; de toutes façons, le temps de génération dépend dans notre cas essentiellement de la latence des accès memcache - pour une appli standard faisant des accès externes (webservice ou base ou memcache), ce sera pareil, - ça donne un résultat tellement utile que ce serait dommage de s'en priver Le profilage en dev/recette ne remplacera jamais un profilage au fil de l'eau (et inversement), parce que c'est le meilleur moyen d'avoir un profilage extensif, c'est le meilleur moyen d'avoir du "profilage de non régression", et parce que l'immense majorité des sites web n'ont pas le temps/les hommes/le matériel pour faire une recette extensive dans des conditions identiques à la prod à chaque livraison de code. (on va mettre de côté les gros sites de eCommerce qui ont des besoins et des moyens différents du commun des mortels). C'est comme pour le monitoring : mieux un serveur très bien monitoré, même si ça le fait péter à 90 de charge au lieu de 100, parce que tu peux identifier et corriger proprement les goulets d'étranglement longtemps avant que ça pète, plutôt que de paniquer le jour où ça pète et bricoler une verrue en panique pour que ça passe. Si des gens sont intéressés, je peux filer mon code. Le 28 juil. 2010 à 01:11, Pierre-Henry Muller a écrit : > mode admin sys qui parle : > rien en production ne doit donner la structure de ton site (archi, code, > path, ...) > donc pas de xdebug ou xhprof Je comprends ton inquiétude pour ce qui a une chance de s'afficher. Maintenant, le danger pour moi est plus grand avec un PHP "bare" qui est paramétré pour afficher les erreurs qu'avec un PHP + xdebug qui est paramétré pour ne rien afficher, mais logguer. (Ceci étant dit, c'est une mauvaise idée d'avoir xdebug en prod : cela n'apporte pas plus de visibilité sur les bugs que ce qu'on peut avoir avec un gestionnaire d'erreur bien foutu; côté profilage, xhprof est mieux adapté, et côté debug/code coverage, qui a envie de faire tourner ça sur un serveur de prod ?). Pour ce qui est de xhprof, cela ne change rien au niveau des erreurs générées, cela ne rend rien plus ou moins verbeux, ça rajoute juste quelques fonctions php pour déclencher le profilage et récupérer les données. Pourquoi donc refuser "par principe" ? JFB _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
