Dernièrement j’ai suivi une formation pendant laquelle le formateur se posait une question sur le métier de la RATP. Transporter des personnes ou Calculer des itinéraires ?
J’ai un début de réponse…
Pour un trajet du métro Montparnasse au métro Brochant, tous deux sur la ligne 13, le moteur d’itinéraire propose un trajet avec une correspondance et c’est pour lui le trajet avec le moins de correspondance !
Ce billet est quelque peu technique, âmes sensibles, vous êtes prévenues.
Suite à la migration d’un serveur Windows 2003 / IIS6 vers un Windows 2008 / IIS7, nous avons eu un soucis de performance.
Nous avons utilisé l’utilitaire MSDeploy (http://www.iis.net/download/webdeploy) qui permet de faire une sauvegarde de la configuration IIS6 (la source) et une restauration sur un IIS7 (la cible).
Une fois mis en place et ouvert aux utilisateurs, les performances se sont révélées exécrables, alors que tous nos tests étaient concluants… Le problème venait d’un paramètre qui ne s’exprime pas de la même façon sur le IIS6 et le IIS7. Le mode débug.
Sur IIS6, aucune limitation alors que sur IIS7, ce mode activé a pour effet de limiter l’exécution du processus w3wp.exe à un seul thread par pool d’application. L’effet est assez déroutant, on a un serveur qui ronronne, RAM : ok, proc : ok, réseau : ok. mais les temps d’exécution sont hyper longs cas ils sont mis en file d’attente.
interface sous IIS6
interface sous IIS7
L’effet sur le serveur : debug activé
Débug désactivé :
Une des pistes a été trouvée dans cet article : http://support.microsoft.com/kb/316451
« la cause classique est que le débogage de script ASP est activée. Lorsque le débogage est activé, seul thread de travail ASP est disponible pour traiter les demandes entrantes pour les pages ASP » ou en anglais : « When debugging is enabled, only one ASP worker thread is available to process the incoming requests for ASP pages. »
Aujourd’hui, je suis arrivé à ce résultat ou presque.
En javascript, quand le nombre en trop grand, alors la précision laisse à désirer.