Bonjour,
J'ai un traitement qui passe tres bien sur mon serveur de dev et de pre-prod et plante en production. Est il possible de faire un debugage en Prod ?
Merci pour vos conseils.
Version imprimable
Bonjour,
J'ai un traitement qui passe tres bien sur mon serveur de dev et de pre-prod et plante en production. Est il possible de faire un debugage en Prod ?
Merci pour vos conseils.
Ma petite expérience me dit que ce n'est pas conseillé :)
Cependant, un DebugDiag en prod pour catcher les crash ou Hang IIS et une analyse des logs avec WinDgb s'est pour ma part souvent avéré être un super moyen de détecter des erreurs en production.
En recherchant j'ai vu qu il existait Remote Debugger, qq un a t il un retour l'experience ?
Des try catch et une gestion des logs appropriés
Et le tour est joué
Une appli ne devrait jamais planter sans qu'on sache la source de l'erreur
try/ catch, c'est beaucoup trop invasif.
C'est gestion doit être externe au programme, AutoDumpPlus (http://support.microsoft.com/kb/286350/fr) permet de générer un dump automatiquement en cas de crash ou de Hang IIS, et cela sans offusquer le code avec des try/catch qui ne font que cacher le problème (et encode, s'ils ont accès malin pour ne pas catcher des OutOfMemory ou de StackOverFlow)
A bas les try/catch imbéciles.
Mince, et moi qui mets que des try/catch imbéciles ...Citation:
Envoyé par bacelar
Pour ma part, je ne suis jamais parvenu à obtenir un dump avec ADPlus, d'ou mon conseil de regarder du côté de DebugDiag (très probablement à cause d'une mauvaise utilisation de ma part bien sûr).
Cependant, je suis assez d'accord sur le fait que la meilleure solution étant bien sûr de tester avant mise en prod, il faut mieux utiliser un outils pour tracer l'origine du problème que de la contourner par des Try/Catch couteux qui ne feront que le masquer.
Epineux problème que la gestion des exceptions...
Nan mais faut arrêter de dire que les try/catch masque l'erreur, à moins que vous laissiez le catch vide :roll:
Le seul problème avec les try/catch c'est que c'est horriblement lent.
Après, ça ne masque pas l'erreur, ça reste au développeur de fournir le moyen à l'utilisateur de savoir pourquoi ça plante.
Seulement en cas de plantage, ce qui ne devrait pas arriver trop souvent, non?Citation:
Envoyé par laedit
Tout dépend de l'appli et de comment elle a été structuré, mais généralement oui, ça ne devrait pas arriver trop souvent.
Je ne suis pas sûr que les try\catch sont horriblement lent.... Pour moi ce sont des à priori. J'ai personnellement fait des tests de charge, et les résultats ne mettent pas en évidence des chutes de performances. On à même tendance à dire que catcher des exceptions typés et moins coûteux que de catcher une exception globale. Ce que je pensais également avant de faire les tests. Tout dépend de l'application, de ce qu'il y dans le try catch, de la gestion des exceptions (nombre de couche d'exception)... Mais globalement, ça ne coûte pas cher de gérer cela proprement, et de remonter des exceptions typés.
Pour l'avoir testé, il se passe quand même un temps entre le moment où l'exception est levée et celui où elle est "catchée".
Ok, donc tu catches rien.
Et quand ça plante, t'affiches quoi au client? Une page d'erreur sans traitement? T'attends que le client remonte le problème avant de te rendre compte qu'il y a un truc qui cloche dans ton appli?
Les try/catch ne changent rien au niveau de la vitesse d'exécution du code... excepté quand y'a une exception qui est levée, mais c'est mieux ça et de la traiter correctement (log/envoisemail, etc) que de l'afficher bêtement au client.
Le seul défaut des try/catch, c'est lors de la compilation, je m'explique :
Prenons ce code, si c'est hors d'un try / catch, le compilateur va optimiser le code compilé en :Code:
2
3
Code:int i = 4;
Le problème avec les try/catch, c'est que du a leurs utilisation, le compilateur n'optimise absolument rien de ce qui est a l'intérieur !
Donc utilisez les try/catch a bon escient ! Ne faite pas des try catch vide, ni des try catch contenant des bête throw... l'erreur remontera d'elle même si il faut, pas besoin de la relancer, ça la lance pas plus vite :-)
A BANNIR :
Code:
2
3
4
5
6
7
8
Code:
2
3
4
5
6
7
8
SINON ... pour revenir au sujet du post... Tu as aussi les trace.axd qui peuvent grandement t'aider, tu vois ce que c'est?
Les traces axd sont generes lorsque je mets les traces d'une page a true, c ca ?
Oui c'est ça, plus d'info ici :Citation:
Envoyé par topolino
http://blogs.crsw.com/mark/archive/2005/04/06/827.aspx
Donc tu l'active, a chaque requête faite, t'as une nouvelle ligne dans ton fichier /dossier/trace.axd, tu cliques sur view detail, et t'auras les détails de la vie de ta requete.
Tu peux aussi manuellement écrire dedans en fesant des Trace.Write (ou Output je sais plus) pour écrire des infos dedans...
Try/Catch pour du log ou du pseudo traitement d'erreur, c'est idiot.
Quand l'application plante, vous avez un débuggeur en ligne pour faire un dump de l'application à tous les niveaux du processus de fermeture de l'application et vous avez un programme WatchDog qui est à même de relancer l'application.
En ASP.NET, les Evénements des AppDomain feront largement l'affaire pour faire un dump ou vos si chères traces. Mais vous n'aurez qu'un code délicat à faire, sur ces évènements. Vous ne serez pas dépendant d'un stagiaire qui oublie in try/catch, ou pire, qui try/catch sans faire de throw ex (moi, je préfère des finaly) ou qui trace n'importe comment.
Je persiste, les try/catch/finaly, c'est pour gérer des erreurs connues, ET PUIS C'EST TOUT.
Et là, on ne met même pas en branle les contenairs d’IoC type Spring.NET ou EntLib et leurs intercepteurs, que les "traitements" sauvages des exceptions rendent inopérants.
Les exceptions coûtent chères quand elles s’exécutent. Qaund on les catche n’importe comment, elles s’exécutent souvent et pendant longtemps.:aie::aie::aie:
T'as pas répondu à
Citation:
Et quand ça plante, t'affiches quoi au client? Une page d'erreur sans traitement? T'attends que le client remonte le problème avant de te rendre compte qu'il y a un truc qui cloche dans ton appli?
Quand ça plante, je créer un dump (mini ou pas), j'affiche une boite de dialogue à l'utilisateur, je zippe le dump, j'envoie un email avec le zip au mail de support (ou le chemin vers un partage ou est le dump), je relance l'application, avec des paramètres particuliers si nécessaire ou un watchdog etc...
Tout ça avec un simple fichier de configuration du débuggeur en ligne (CDB, NTSD ou autre) et quelques VBS si nécessaire.
En cas de plantage,
D’exception non catché dans un thread auxiliaire,
Au moment du lancement d'une exception catché,
Au moment du passage du compteur de programme à une valeur donnée,
En cas de Hang IIS,
Sur demande utilisateur,
Sur déclanchement sur seuil Perfmon,
etc...
Et ça, c'est sans les outils d'analyse automatiques des dumps pour alerter via Task TFS le développeur du dernier workItem TFS ayant modifié la ligne incriminé.
S'il y a un manque, je pense que je pourrais me l'implémenter.:aie::aie::aie: