2008-10-13 5 views

Répondre

32

En tant qu'Hoster, vous voulez absolument recycler sur Memory & Time, potentiellement Request limits and CPU. Vous voulez être assez agressif à propos de ces limites, mais assurez-vous de les publier à vos clients.

Memory - 512 pour une boîte x86, peut-être 768. Pour x64, vous pouvez définir cette valeur beaucoup plus élevée en fonction du nombre d'hôtes par serveur. Vous devez juste faire attention et regarder votre pool d'applications recycler les événements sur les problèmes de mémoire. - Nous recyclons généralement à 1 heure du matin, plus ou moins (premier site 1:01, deuxième 1:11, troisième 1:21, pour que vous n'ayez pas tout le recyclage en même temps)

Request limit - 35 000 était la valeur par défaut pour IIS6, mais ce nombre est assez arbitraire, et très dépendant du site en question. Pour les petits sites d'utilisation, le recyclage de nuit sera atteint bien avant que vous obteniez 35k demandes.

CPU - 95%/1 minute limite/KillW3WP, mais à utiliser avec précaution. Ma compréhension de ceci est que si le CPU atteint 95% + sur la limite de 1 minute pour ce processus de travail, le processus de travail est tué et est incapable de redémarrer pour le reste de la limite lorsque Action est défini sur KillW3WP. Vous voudrez peut-être commencer par NoAction et regarder attentivement les journaux de vos événements. - Vous voulez vous assurer que vous consignez les recyclages de pool d'applications pour chaque seuil d'événement que vous définissez, c'est-à-dire si vous limitez les limites de demandes, assurez-vous que la journalisation de limite de demande est activée.

Une chose à retenir est que vous devez mettre retail="true" dans l'élément <deployment> dans votre machine.config:

<system.web> 
    <!-- 
     <deployment 
      retail = "false" [true|false] 
     /> 
    --> 
    <deployment retail="true" /> 
</system.web> 

réglage Non cela permettra un site pour activer le débogage sur, ce qui permet les délais d'attente illimités dans les demandes - pas exactement idéal pour un hébergeur ...

+1

Merci. Si vous avez d'autres conseils pour configurer correctement l'environnement IIS pour l'hébergement, veuillez modifier votre message/ajouter de nouvelles réponses. – GrZeCh

+5

Vous devez prendre en compte la règle 1: 1 Site to AppPool. Grâce aux améliorations apportées à l'isolation AppPool d'IIS 7, les pools d'applications fonctionnant sous la même identité ne peuvent pas accéder à la mémoire/aux ressources de l'autre. –

1

Astuce: Lorsque vous recyclez votre application, toutes vos variables de session sont détruits ... donc la prudence à ce sujet!

À mon humble avis, conservez les valeurs par défaut.

+0

Mais c'est seulement si vous êtes InProc, non? –

+5

Vos variables de session ne seront détruites que si vous utilisez InProc. Je maintiendrais toujours les variables de session hors processus afin que vous puissiez facilement évoluer vers un Web Garden/ferme. –

2

Si votre site est très fréquenté, utilisez un programme de recyclage long. Si vous avez un site à faible trafic, utilisez un horaire plus court/par défaut pour économiser de la mémoire.

Je l'ai appris sur le blog de Al Zabir: http://msmvps.com/blogs/omar/archive/2008/10/04/best-practices-for-creating-websites-in-iis-6-0.aspx

Daniel S. a raison, vos variables de session sont détruites sur le recyclage, alors assurez-vous de tester ce bien ou avoir une bonne protection/récupération d'erreur lors de l'obtention de vos objets de session .

1

vous devez adapter les paramètres à vos besoins, prendre en compte la quantité de mémoire que vous avez et les heures de pointe d'utilisation de votre site/application web.

Tenez également compte de l'utilisation de la mémoire de votre site/application Web comme s'il y avait des fuites de mémoire que vous pourriez recycler plus souvent que vous ne le pensez.

Pesez toutes les fuites contre le coût du recyclage, comme indiqué ci-dessus, vous perdrez des variables d'état.

Questions connexes