Le 28 juil. 2010 à 09:39, JF Bustarret a écrit : > > 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" ?
Oui je suis sans doute allé un peu vite dans l'idée, effectivement on peut tout rediriger dans un log. Mais la consommation mémoire des deux modules est conséquente, pour un ordre d'idée avec un framework perso (les symfony et autres consomment bien trop) en prod je consomme 900Ko en moyenne par requête, pour un temps de calcul de 0.035 sec avec requêtes sql, memcache et mogilefs, dès que je charge xdebug je monte à 2,5Mo de mémoire et un temps moyen de 0,45 sec par requête. Certains diront que ca reste raisonnable comparé aux 4,5Mo de mémoire pour afficher un hello world avec Symfony et plus pour un zend mais de mon côté tout ce que je gagne en ressources ce sont des économies d'infra, d'électricité, ... et un surf plus sympa. Je ne vous parle même pas lorsque les pages sont en cache. Pour info ca tourne sur du Nginx avec php5 en fcgi donc les vm web n'ont que 1Go de ram et tiennent un ab -n 50000 -c 200 sans erreur. Pour ta technique de logguer une fois toutes les 30 sec en fait ton but est plutôt de mesure toute régression du code. Dans ce cas là ta solution est effectivement pas mal du tout. Après si tu as un comportement en particulier que bien sur tu n'arrives pas à reproduire de ton côté, le profilage par machine de réplication reste pour moi l'assurance de faire du debug sur toutes les requêtes avec le tracage activé dans xdebug par exemple et trouver LA requête de folie qui fait des erreurs. -- Pierre-Henry Muller _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
