> Tech > Utiliser les résultats

Utiliser les résultats

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

L'utilisation des données de performances pour diagnostiquer un problème logiciel est un savoir-faire technique important. C'est aussi une condition préalable pour déterminer la manière de corriger les problèmes de performances (effectuer des changements de code, modifier les paramètres du serveur, par exemple). Je me concentre ici sur quelques-uns des paramètres

Utiliser les résultats

de serveur que vous pouvez
modifier. Vous devez tester les
éventuelles modifications pour être
certain qu’elles n’affaiblissent pas les
performances de votre système de
production.
Paramétrage de la métabase IIS.
Vous pouvez régler vos serveurs Web
en ajustant les paramètres de performances
suivants dans la métabase. (A
noter que ce n’est qu’une liste partielle
des valeurs que vous pouvez définir.)

  • AspThreadGateEnabled (pas disponible
    dans IIS 4.0 et antérieur) –
    Quand il est activé, ce paramètre active
    l’ASP thread gate, une porte qui
    supervise et modifie dynamiquement
    le nombre de worker threads
    que chaque dllhost.exe utilise pour
    traiter les requêtes ASP entrantes. La
    fonction compare l’utilisation de la
    CPU à  des seuils définis (AspThread
    GateLoadLow et AspThreadGate
    LoadHigh) et ajuste le nombre de
    threads que le système permet
    d’exécuter. Modifiez cette valeur si
    vous constatez que le serveur met
    des requêtes ASP en file d’attente ou
    que lesdites requêtes entraînent une
    utilisation de la CPU supérieure à 
    80 %.

  • AspProcessorThreadMax (Processor ThreadMax in IIS 4.0) – Ce paramètre
    limite le nombre de worker threads
    que IIS autorisera pour le traitement
    des requêtes ASP. Ce nombre est différent
    pour chaque processus, donc
    chaque processus a un pool d’ASP
    worker thread. La valeur par défaut
    est de 25 threads par processeur.
    Bien que la fonctionnalité ASP
    thread-gating utilise ce paramètre,
    thread-gating n’a pas besoin d’être
    activé pour que le paramètre fonctionne.
    Par exemple, voici un cas
    dans lequel vous pourriez vouloir
    utiliser le paramètre sans que le
    thread gating soit activé : si vous
    constatez beaucoup de requêtes en
    backup tout en sachant qu’aucune
    d’elles ne sollicite la CPU (par
    exemple, parce qu’elles sont dans
    une base de données back-end).

  • AspScriptEngineCacheMax – Cette
    valeur définit le nombre de moteurs
    de scripts ASP à  cacher en mémoire.
    Ces moteurs transforment un script
    analysé syntaxiquement en code octet.
    Dans IIS 5.0, la valeur est de 125.
    Dans IIS 4.0, la valeur par défaut est
    de 30. Si votre site a des milliers de
    pages ASP, vous améliorerez probablement
    les performances en augmentant
    la valeur par défaut.

  • AspScriptFileCacheSize – Ce paramètre
    ajuste le nombre de scripts
    ASP analysés syntaxiquement à  garder
    en mémoire. Valeur par défaut :
    250. Si cette valeur est mise à  0, aucun
    script n’est mis en cache ; avec –
    1, tous les scripts sont mis en cache.

  • ConnectionTimeout – Ce paramètre
    permet de fixer le délai avant lequel
    IIS termine une connexion inactive.
    La valeur par défaut est de 900 secondes
    (15 minutes). Si vous épuisez
    fréquemment les connexions sur le
    serveur, essayez de diminuer cette
    valeur. Si votre site a une page dont
    le renvoi demande longtemps et s’il
    n’y a pas beaucoup de trafic sur le
    serveur, vous pouvez augmenter ce
    nombre. Attention toutefois à  ne pas
    l’augmenter jusqu’au point où votre serveur manquera de connexions
    quand il atteindra un pic de charge.

  • MaxEndpointConnections – Cette
    valeur définit le nombre maximum
    d’écouteurs qui seront disponibles
    sur n’importe quel point d’extrémité
    du réseau (port 80, par exemple). La
    valeur par défaut est de 100. Si les
    clients reçoivent souvent une erreur
    Server Too Busy sur un site très actif
    mais peuvent se connecter correctement
    après un ou deux rafraîchissements
    seulement, il est peut-être nécessaire
    d’augmenter ce nombre (en
    même temps que la valeur
    ServerListenBacklog).

  • ServerListenBacklog – Ce paramètre
    ajuste le nombre de sockets en suspens
    que votre serveur Web peut
    mettre en file d’attente. La valeur par
    défaut dépend du paramètre Server
    Size. Si ServerSize est mis à  0, le
    nombre par défaut de sockets est de
    5 ; si ServerSize est de 1, le nombre
    par défaut est de 40 ; et si ServerSize
    est de 2, le nombre par défaut est de
    100. La plus petite des deux valeurs –
    ServerListenBacklog et MaxEndpoint
    Connections – est utilisée pour déterminer
    combien de connexions
    sont en pool sur votre serveur.

  • ServerSize – Ce paramètre indique le
    nombre approximatif de requêtes
    par jour que vous vous attendez à  recevoir.
    Une valeur de 0 indique
    moins de 10 000 requêtes par jour ; 1
    en indique moins de 100 000 et 2 en
    indique plus de 100 000 par jour.
    Vous pouvez définir cette valeur dans
    la glissière Performance Tuning
    de la console ISM (Internet Service
    Manager).

Paramètres du registre. Les paramètres
de registre suivants peuvent affecter
les performances de votre site.
Naviguez jusqu’à  la sous-clé HKEY_LOCAL_
MACHINE\SYSTEM\CurrentContr
olSet\Services\InetInfo\Parameters et
examinez les valeurs suivantes :

  • MaxPoolThreads – Cette valeur indique
    le nombre maximum de
    threads créés pour traiter les requêtes
    statiques entrantes. La valeur
    par défaut est de quatre par processeur.
    Si vos paramètres de cache sont
    adéquats pour votre trafic Web, vous
    n’aurez pas besoin de jouer sur cette
    valeur.

  • PoolThreadLimit – Cette valeur supplante
    la valeur MaxPoolThreads
    pour les requêtes vers ISAPI
    Extensions et vers d’autres services
    dans InetInfo (FTP, SMTP, par
    exemple). La valeur par défaut est de
    deux fois le nombre de méga-octets
    de RAM dans le système (avec une
    valeur par défaut maximale de 256).
    Comme les threads dans le pool de
    threads IIS n’existent que pendant
    24 heures, vous ne devrez en principe
    pas modifier ce nombre sauf si
    vous constatez une forte commutation
    de contexte, auquel cas vous
    pourriez le diminuer.

Téléchargez cette ressource

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010