Was sind die optimalen Einstellungen für Recycling von Anwendungspools in IIS7 in gemeinsam genutzten Umgebung?

Question

Was sind die optimalen Einstellungen für Recycling von Anwendungspools in IIS7 in einer gemeinsamen Umgebung?

Answer 1

Als Hoster, möchten Sie auf jeden Fall auf dem Memory & Zeit recyceln, möglicherweise Grenzen und CPU anfordern. Sie wollen ziemlich aggressiv über diese Grenzen sein, aber stellen Sie sicher, dass Sie sie zu Ihren Kunden veröffentlichen.

Speicher - 512 für eine x86-Box, vielleicht 768. für x64, können Sie diese viel höher eingestellt auf der Anzahl der Hosts pro Server abhängig. Sie müssen nur vorsichtig sein und Ihre AppPool recycle Ereignisse auf Speicherprobleme beobachten.

Zeit - Wir bei 1 Uhr morgens typischerweise recyceln, plus oder minus (erste Stelle 01.01 Uhr, die zweiten 1,11 dritte 1.21, nur so haben Sie nicht alle zur gleichen Zeit des Recycling)

Anfrage Grenze - 35.000 war der Standard für IIS6, aber diese Zahl ist ziemlich willkürlich und sehr abhängig von der Website in Frage. Für kleinen Verwendungsort wird die nächtliche recycle getroffen, lange bevor man 35k Anfragen erhalten.

CPU - 95 % / 1 Minuten-Grenze / KillW3WP, aber dies sorgfältig verwenden. Mein Verständnis davon ist, dass, wenn die CPU 95% trifft + über die 1-Minuten-Grenze für diesen Arbeitsprozess, wird der Arbeitsprozess getötet und ist nicht in der Lage für den Rest der Grenze neu zu starten, wenn Aktion KillW3WP eingestellt ist. Vielleicht möchten Sie noaction zunächst versuchen, nur sorgfältig Ihre Ereignisprotokolle zu beobachten.

Recycle-Ereignisprotokolle - Sie sicherstellen möchten Sie AppPool melden sich für jedes Ereignis ThreshHold rezykliert, dass Sie eingestellt -. dh, wenn Sie von Anfragen Grenzen basierend Grenze ab, sicher ist, dass Antrag machen limit-Protokollierung aktiviert

Eine Sache zu erinnern ist, dass Sie sollte gesetzt retail="true" im <deployment> Elemente in den machine.config :

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

Einstellung nicht eine Website ermöglicht das Debuggen zu aktivieren, die unbegrenzte Timeouts in Anfragen erlaubt - nicht gerade ideal für einen Hoster ...

Answer 2

Wenn Sie eine stark befahrenen Website haben, verwenden Sie lange recycle Zeitplan. Wenn Sie einen niedrigen Verkehrs Website verwenden kürzer / default Planspeicher zu speichern sind.

Das erfuhr ich von Al Zabir Blog: http://msmvps.com/blogs/omar/archive/2008/10/04/best-practices-for-creating-websites-in-iis-6-0 aspx

Daniel S. ist richtig, erhalten Sie Ihre Session-Variablen auf Recycling zerstört, so stellen Sie sicher, dass Sie dies auch testen oder gute Fehler haben Schutz / Erholung, wenn Ihre Sitzung Objekte zu bekommen.

Answer 3

Tipp: Wenn Sie Ihre App recyceln, werden alle Session-Variablen werden zerstört ... also Vorsicht auf diese

IMHO, halten Sie die Standardeinstellungen.

Answer 4

müssen Sie die Einstellungen auf Ihre Bedürfnisse zugeschnitten sind, berücksichtigen die Größe des Speichers Sie und die Spitzenzeiten der Nutzung für Ihre Website / Web-Anwendung haben.

Auch berücksichtigen die Speichernutzung Ihrer Website / Web-Anwendung, als ob es Speicher sind Lecks Sie häufiger werden könnten Recycling dann denken Sie.

Wiegen alle Lecks gegen die Kosten des Recyclings auf, wie oben erwähnt, Sie Zustandsvariablen verlieren.