Bild 1: XTune Manager
Geschrieben von: Christian Koller
Kategorie: Optimierung
This printed page brought to you by AlphaSierraPapa
Um die verschiedenen Einstellungsmöglichkeiten eines Internet Information Servers (IIS 4.0 und IIS 5.0) zum Tuning wirklich nützen zu können bedarf es normalerweise eines sehr fundierten Wissens über den Aufbau des IIS. Die Tuningmöglichkeiten sind vielfältig. Um nur einige Parameter zu nennen, die die Performance eines Windows NT / 2000 Webservers stark beinflussen können:
Ein Teil dieser Parameter lässt sich in der Microsoft Management Console (MMC) des IIS beeinflussen. Für andere Einstellungen muß man direkt Werte in der Registry des Betriebssystems ändern.
Das Tool XTune der Firma Post Point Software erleichert das Einstellen von Performance-relevanten Parametern des Webserver und einzelner Websites erheblich. XTune ist gratis und läuft sowohl auf IIS 4.0 als auch auf IIS 5.0 (Downloadlink am Ende des Artikels).
Die Installation von XTune auf dem Webserver ist einfach: das downgeloadete File entpacken (zum Beispiel mit WinZip) und Setup.exe starten. Wie immer bei einer Installation sollte man Administratorrechte haben.
Nachdem das Setup abgeschlossen ist, befindet sich in Start/Programme ein neuer Eintrag namens XTune, der die XTune Dokumentation und den XTune Manager (auf MMC Basis) enthält.
Um den Webserver mit Hilfe von XTune einzustellen, öffnen Sie den XTune Manager aus der XTune Programmgruppe. Der XTune Manager (siehe Bild 1) entspricht dem IIS Manager unter Windows NT 4.0 Server oder dem Internet Services Manager unter Windows 2000.
Bild 1: XTune Manager
Je nach dem, ob Sie nur eine Website oder den ganzen Webserver tunen wollen, haben Sie zwei Möglichkeiten:
Klicken Sie mit der rechten Maustaste im XTune Manager auf ein Webserver Symbol und wählen Sie Eigenschaften (Properties) im Kontextmenü. Das Eigenschaftsfenster für den Webserver öffnet sich. Klicken Sie in diesem Fenster auf den XTune Tab. Schon können Sie die Webserver Parameter einstellen um die Performance zu optimieren (siehe Bild 2).
Bild 2: XTune Tab im Webserver Eigenschaftsfenster
Was eine Veränderung der einzelnen Parameter im XTune Tab bewirkt, und was hinter den Begriffen steht wird in den folgenden Absätzen erklärt:
Der PoolThreadLimit Parameter gibt den maximalen Wert des MaxPoolThreads Parameters an, der für einzelne Websites oder IIS Prozesse gesetzt werden kann.
Wenn zum Beispiel PoolThreadLimit einen Wert von 50, und der Parameter MaxPoolThreads für eine Website den Wert 70 hat, so bekommt die Website trotzdem nur maximal 50 Threads im Thread Pool zur Verfügung gestellt.
Anmerkung: In der XTune Dokumentation ist dieser Parameter falsch erklärt (Stand XTune Version 1.0.4324.3).
Bei gleichmäßigen Zugriffen ("static workload)" auf den Webserver wird empfohlen, den Parameter PoolThreadLimit auf die Anzahl der Prozessoren und den Parameter MaxPoolThreads auf 1 zu setzen (siehe Microsoft Web Workshop Artikel IIS 4.0 Tuning Parameters for High-Volume Sites). Der Default Wert ist etwa doppelt so groß wie die MB des Computerspeichers (256 MB Ram resultieren in einem Standardwert von 510 für den PoolThreadLimit Parameter).
Die PoolThreadLimit Einstellung wird in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\ gespeichert.
Wenn der Webserver Anfragen nicht sofort bearbeiten kann, so werden diese in der sogenannten Request Queue abgelegt. Bekommt der Webserver eine gewisse Zeit lang (mehr als 30 Sekunden) mehr Anfragen als er verarbeiten kann, so wird die Anzahl der Anfragen in der Request Queue immer größer. Erreicht diese Anzahl nun den Wert des Parameters RequestQueueMax, so gibt der Webserver auf jede weitere eintreffende Anfrage eine Server too busy Meldung aus und verwirft die Anfrage.
Eine empfohlene Einstellung ist ein Wert von 200 für den RequestQueueMax Parameter. Der Standardwert ist 500.
Die Webserverleistung (Anfragen pro Sekunden an einen bestimmten IIS Service: Web, FTP, ...) kann man effektiv erhöhen, indem man den Wert des Parameters von standardmäßig 15 auf etwa 200 erhöht.
Connection Requests (Anfrage nach einer HTTP Verbindung) an den Webserver werden in der sogenannten Connection Queue gehalten bis sie vom Web Service bearbeitet werden können. Für jeden IIS Service existiert eine separate Request Queue, aber für die Länge aller Queues gilt das selbe Limit, das mit dem Parameter ListenBackLog festgelegt wird.
Wenn die Queue eines Webservices voll ist (die maximale Anzahl an Connections erreicht hat), so werden alle neuen Connection Requests (Anfragen für HTTP Verbindungen) zurückgewiesen.
Der standardmäßige Wert von 15 genügt für die meisten Serverdienste. Wenn jedoch ein Server bei kurzen Spitzenauslastungen zu viele Verbindungsanfragen ablehnt, weil ein Service gerade eine hohe Auslastung besitzt, so kann eine Erhöhung des ListenBackLog Parameter Wertes in einer deutlichen Verminderung der Zahl der abgelehnten Verbindungsanfragen resultieren.
Es wird weiters empfohlen, bei einer Veränderung der maximalen Queue Länge die folgenden Server Parameter im Auge zu behalten um Flaschenhälse im System aufzuspüren und zu vermeiden: Server Prozessor Auslastung, Memory Auslastung, Connection Counter.
Der MaxPoolThreads Parameter gibt die Anzahl von Threads im Thread Pool an. Sein Wert wird in Threads-pro-Prozessor Einheiten angegeben.
Jeder Thread im Pool wartet auf eine Netzwerk Anfrage an den Webserver und bearbeitet diesen.
Es wird empfohlen den Parameter auf einen Wert von 20 zu setzen. Standardeinstellung ist 10 Threads pro Prozessor.
Jeder IIS Prozess hat einen eigenen Objekt Cache, in dem zum Beispiel ADO Connections, andere ActiveX Objekte, aber auch ASP-Dateien auf Ihre Wiederverwendung warten. Wenn ein Objekt nach einer bestimmten Zeitspanne (TTL = Time To Live in Sekunden) nicht wiederverwendet wurde, so wird das Objekt aus dem Cache entfernt.
Wenn der Hauptspeicher des Webservers begrenzt ist, so verhindert eine kürzere TTL, daß die Speicherverwaltung von Windows NT oder Windows 2000 Festplattenspeicher verwenden muß um die Objekte zu speichern. Festplattenzugriffe sind im Vergleich zu reinen Speicherzugriffen sehr langsam und vermindern somit die Performance des Webservers.
Ist hingegen genügend Hauptspeicher im Webserver vorhanden, so kann man eine höhere TTL (in Sekunden) einstellen. Dadurch werden mehr Objekte gespeichert und die Wiederverwendungsrate steigt. Dadurch erübrigt sich die resourcenintensive Neuerstellung von diversen Objekten oder das Auslesen von ASP-Dateien von der Festplatte und die Neukompilierung.
Somit kann man den ObjectCacheTTL Parameter bei Webservern mit genügend Hauptspeicher und gleichmässigen Zugriffsraten über alle Web- und ASP-Seiten getrost auf "unendlich" stellen. Dies geschieht durch das Setzen des Wertes 4294967295.
Bei großen Websites ist es oft nötig eine große Anzahl von verschiedenen Dateien bereit zu halten. Wenn die Website hauptsächlich statische HTML Seiten (oder anderen statischen "Content") enthält, so kann die Performance des Servers stark verbessert werden, wenn man die Anzahl der Dateien, die aus dem RAM anstatt direkt von der Festplatte ausgelesen werden, erhöht.
Dies wird über den OpenFileInCache Parameter gesteuert. Empfohlen wird ein Wert von 1000 pro 32 MB Hauptspeicher.
Der IIS hält "System Handles", Directory Listen und verschiedene BLOBS (Binary Large Objects), die häufig verwendet werden, im Cache. Der MemoryCacheSize Parameter spezifiziert, wieviel Hauptspeicher (in Bytes) für diesen Cache zu reservieren sind.
Ein Wert von 0 (Null) bedeutet, daß nichts gecacht wird. Eine Erhöhung des MemoryCacheSize Wertes bringt bei Sites mit einer hohen Zahl an Requests eine spürbare Verbesserung der Performance wenn der Hauptspeicher genügend RAM enthält.
Anmerkung: Damit eine Änderung dieses Wertes Gültigkeit erlangt, muß man die Services (Dienste) des IIS stoppen und neu hochfahren.
Empfohlen ist eine Einstellung von 4194304 Bytes anstatt der standardmäßigen 3072000 Bytes.
Ab dem MaxFreeTcbs Schwellenwert für die Anzahl der aktiven TCP Verbindungen werden TCP Control Blöcke im TIME-WAIT Status wiederverwendet. Eine Wiederverwendung von TCP Control Blöcken ist in der HTTP RFC nicht vorgesehen und sollte daher vermieden werden.
Der empfohlene Wert für MaxFreeTcbs ist 72000. Standarmäßige Einstellung ist, je nach Betriebssystem und Hauptspeichergröße zwischen 250 und 2000.
Durch diesen Parameter wird die Zeitdauer festgelegt, die eine TCP-Connection (Webserververbindung) im TIME-WAIT Status verweilen kann bis sie geschlossen wird. Solange sich eine Verbindung im TIME-WAIT Status befindet können die Socket Paare der Verbindung nicht wiederverwendet werden.
Die empfohlene Einstellung für den Parameter ist 60 Sekunden, der Standardwert ist 240 Sekunden.
Der MaxHashTableSize Wert bestimmt wie schnell das System einen TCP Control Block auffinden kann. Der Wert muß immer als Potenz von 2 angegeben werden (512,1024,2048 usw).
Hier sollte der Default Wert von 512 nicht unterschritten werden. Die XTune Entwickler empfehlen eine Einstellung auf den Wert 65536.
Die maximale TCP Empfangsfenstergröße wird mit diesem Parameter festgesetzt. Das Empfangsfenster umfasst die Anzahl von Bytes die ein Client zum Webserver senden kann ohne dafür eine Empfangsbestätigung zu bekommen.
Im Allgemeinen wird ein größeres Empfangsfenster immer mit höherer Performance in langsamen Netzwerken mit höher Übertragungsbreite (wie dem Internet) einhergehen. Für beste Resultate sollte das Empfangsfenster genau ein Vielfaches der TCP Maximum Segment Größe (MSS) sein.
Empfohlen wird ein Wert von 17520 anstatt dem Standardwert von 8760 für Ethernet Netzwerke.
Außer Anpassungen des Webservers erlaubt XTune auch das Anpassen von Website Parametern an die Anforderungen um so eine bestmögliche Performance einzelner Websites zu erzielen. Dies wird in den nun folgenden Absätzen beschrieben.
Expandieren Sie zuerst die Websites (siehe Bild 1) im XTune Manager Fenster. Danach klicken Sie mit der rechten Maustaste auf die gewünschte Website und wählen Properties oder Eigenschaften, wodurch sich ein Fenster öffnet (siehe Bild 3).
Bild 3: Eigenschaftenfenster der Website
Klicken Sie in diesem Fenster auf den XTune Tab (siehe Bild 4). Nun können Sie bequem die wichtigsten tuningrelevanten Parameter der Website ändern.
Bild 4: XTune Tab
Wie im Bild 4 zu sehen ist, kann man auf dem XTune Tab folgende Parameter einstellen:
Die ASPQueueTimeout Eigenschaft gibt die Zeit in Sekunden an, die ein ASP Skript in der Queue bis zum Abarbeiten maximal verstreichen lässt. Wenn ein ASP Skript erst nach der spezifizierten Zeit zur Verarbeitung angenommen wird, so terminiert der Webserver die Ausführung des ASP Skripts und gibt eine "Server too busy" Meldung an den Client aus.
Eine vernünftige Einstellung für diesen Parameter sind 30 Sekunden. Der Default Wert ist unendlich.
Anmerkung: Dieser Parameter könnte anstatt mit XTune auch mit Hilfe des IIS Administration Script Utility Tools (adsutil.vbs) gesetzt werden.
Die Eigenschaft AspScriptTimeout spezifiziert die maximale Zeitdauer in Sekunden, die ein ASP Skript laufen darf, bevor es vom Webserver terminiert wird.
Empfohlen werden 30 Sekunden für diesen Parameter, der Default Wert sind 90 Sekunden. Der kleinste Wert ist eine Sekunde.
Anmerkung: Der im AspScriptTimeout Parameter gesetzte Wert kann für bestimmte ASP Seiten durch Zuweisen eines Wertes zur Server.ScriptTimeout Eigenschaft im ASP Skript verändert werden.
Wenn eine ASP Seite mittels ADO (ActiveX Data Objects) auf eine Datenbank zugreift, so bestimmt der ConnectionTimeout Parameter die Zeitdauer in Sekunden, nach der eine inaktive Datenbankverbindung automatisch geschlossen wird.
Je nach Datenbankgeschwindigkeit und Komplexität der Datenbankabfrage werden Werte zwischen 5 und 30 Sekunden empfohlen.
Der Webserver behält die im AspScriptFileCacheSize Parameter angegebene Anzahl an vorkompilierten ASP Skript Dateien im Cache. Die Performance beim Abrufen einer gecachten ASP-Datei vom Webserver ist wesentlich höher als bei einer nicht gecachten Datei, da ein Festplatten-Zugriff und das Vorcompilieren entfallen. Auf der anderen Seite benötigt jede gecachte Datei Speicherplatz.
Wird der Wert für AspScriptFileCacheSize auf 0 (Null) gesetzt, so werden keine ASP-Dateien gecacht. Ein Wert von -1 bedeutet, daß alle Skript Dateien gecacht werden.
Ein empfohlener Wert, je nach Speichergröße und Aufruf von ASP-Dateien, ist 256 bis 2000.
Mit Hilfe dieser Einstellung bestimmen Sie die maximale Anzahl der gecachten Script Engines, die ASP im Speicher hält. Da jede Script Engine eine ASP-Seite abarbeitet, bedeutet eine Erhöhung des AspScriptEngineCacheMax Wertes, daß mehrere ASP-Seiten gleichzeitig abgearbeitet werden können. Dies ist insbesondere bei ASP Applikationen wichtig, die "langsame Operationen" wie Datenbankzugriffe, Festplattenzugriffe, Datei-Upload auf den Server, Einsatz von ActiveX-Komponenten und ähnliches beinhalten.
Empfohlen werden 100 bis 300 als Wert für den Parameter. Der Default Wert ist 50.
Diese Eigenschaft gibt die Anzahl der "outstanding" Sockets an, die vom Webserver abgefragt werden können. Der optimal zu setzende Wert basiert auf der Konfiguration des Betriebssystems und dem ServerSize Parameter.
Durch Verändern des Parameters und Testen der Site mit einem sogenannten Web Application Stress Tool (siehe auch Absatz Testen der Webserver Performance) kann man die beste Einstellung herausfinden (siehe auch MSDN Artikel Configuring IIS to Handle Heavy Usage, ID Q229814). Der Standardwert ist 40.
Anmerkung: Ohne XTune könnte man diese Eigenschaft mit Hilfe des IIS Administration Script Utility Tools setzen.
Mit dem Parameter MaxEndPointConnections kann man die maximale Anzahl der "empfangsbereiten" Sockets setzen, die an einen Netzwerk Endpunkt gebunden sind. Ein Wert von 25 bedeutet, daß maximal 25 Netzwerk-Connections gleichzeitig auf einen bestimmten Netzwerk-Port der Website erlaubt sind.
Ein guter Wert für Websites mit hohen Zugriffsraten ist 500 bis 1000. Ein Wert von -1 (&HFFFFFFFF) wird als "unendlich" interpretiert. Default Wert hat, je nach Konfiguration, einen der folgenden Werte: -1, 200, 255.
Auch auf den MaxEndPointConnections Parameter wird im MSDN Artikel Configuring IIS to Handle Heavy Usage (ID Q229814) bezug genommen.
Der Parameter ServerSize spiegelt die Anzahl der erwarteten Client-Requests pro Tag wieder. Der Wert dieser Eigenschaft wird benutzt, um unter anderem auch Einfluß auf den Wert des ServerListenBacklog Parameters zu haben.
Die Werte für den ServerSize Parameter, und wofür sie stehen:
Der Default Wert ist 1. Empfohlen wird ein Wert von 2 für größe Zugriffszahlen.
Dieser Parameter legt fest, ob der Webserver fehlgeschlagene Anfragen aus dem Internet in das Windows Event Log schreibt oder nicht.
Wenn AspLogErrorRequests gewählt ist, so werden Standard ASP Fehler mitgeloggt.
Es wird empfohlen das mitloggen von Standard ASP Fehlern auszuschalten, da dies weitere Resourcen spart. Standardmäßig ist das mittloggen von Standard ASP Fehlern eingeschalten.
Anmerkung: Um das Mitloggen aller ASP Fehler zu unterbinden, muß das Logging ganz ausgeschalten werden. Dies wird durch Setzen der DontLog und LogType Parameter auf FALSE in der IIS Metabase mittels Metabase Editor oder IIS Administration Script Utility erreicht.
NTLM bezeichnet die in das Betriebssystem (Windows NT 4.0 oder Windows 2000) integrierte Authentifizierung, auch bekannt unter dem Namen Secure Challenge/Response Authentication.
Wenn die NTLM Authentifizierung ausgeschalten wird, so kann sich ein Client (zum Beispiel durch den Webbrowser) nicht mehr als Benutzer unter einem Windows Benutzerprofil (Benutzernamen und Paßwort) anmelden.
Ein Unterbinden dieser Authetifizierungsmethode spart wiederum Webserverresourcen. Standardmässig ist NTLM Authentifizierung erlaubt.
Ein Artikel zu Authentication and Resource Protection in Windows 2000, der auch auf NTLM eingeht, ist bei ist bei Microsoft TechNet online.
Eine Website, die keinerlei Session State benötigt, da keine Daten in Session Variablen gespeichert werden, kann man dadurch beschleunigen, daß man den Session State für die gesamte Website ausschaltet. Dies bedeutet, daß der Webserver keine Sessions mehr managen muß und keine neuen Session Objekte mehr generiert werden, wenn ein Besucher die Website aufruft. Auch der Aufwand zum Senden und Verwalten der Sessioncookies fällt damit für den Webserver weg.
Achtung: Durch Ausschalten des Session States werden die Funktionen Session_OnStart und Session_OnEnd der global.asa nicht mehr ausgeführt. Außerdem tritt beim Versuch, Daten in einer Session Variablen zu speichern, ein Laufzeit-Fehler auf.
Wenn Sie auf Sessions nicht verzichten können, so ist es möglich, die Ausführung von ASP-Skripts die nicht auf das Session Objekt zugreifen mittels <% @ EnableSessionState = False %> Direktive zu beschleunigen (siehe auch Artikel @-Direktiven auf ASP Seiten und Session Variablen - Verwendung und Stolpersteine).
Empfohlene Einstellung: Ausschalten des Session States, daher AspAllowSessionState Parameter im XTune Tab nicht wählen. Standardmässig ist der Session State eingeschalten.
Das Buffern des Outputs einer ASP Seite ist ein wirkungsvoller Weg um die Abarbeitung von ASP-Skripts zu beschleunigen. Die Wirkung beruht darauf, daß der Webserver den Output nicht Stück für Stück zum Browser schickt, sondern auf einmal. Dadurch entfällt für den Webserver das Warten darauf, daß der Browser den Empfang der Output-Teile bestätigt.
Um jeden ASP-Output zu cachen, setzen Sie im XTune Tab den AspBufferingOn Parameter auf Ein.
Standardmässig ist am IIS 4.0 das Buffern ausgeschalten, am IIS 5.0 hingegen eingeschalten.
Achtung: Obwohl die Abarbeitung der ASP-Seite insgesamt schneller abläuft, so dauert es doch länger, bis der Browser einen Teil der Seite anzeigt. Vor allem bei Scripts, bei denen bestimmte Teile (wie Datenbank-, Festplattenzugriff oder Kreditkartenvalidierung) merklich lange brauchen, ist es empfehlenswert, Meldungen und einen ersten Teil der Seite mittels Response.Flush zum Browser zu schicken (siehe auch Artikel Zwischenspeichern von ASP Seiten).
Dieser Parameter bestimmt, wieviele "Working Threads" pro Prozessor und pro IIS Prozess parallel abgearbeitet werden können.
Die IIS 5.0 Metabase Eigenschaft AspProcessorThreadMax hatte unter IIS 4.0 noch den Namen ProcessorThreadMax und wurde in der Betriebssystem Registry des IIS 4.0 gespeichert.
Empfohlene Einstellung für den Parameter ist der Wert 30. Standardmäßig ist unter IIS 5.0 der Wert auf 25, und unter IIS 4.0 der Wert auf 10 gesetzt.
Im Allgemeinen kann man den Wert unverändert lassen, außer Teile von ASP-Seiten greifen exzessiv auf externe Objekte (wie ADO oder das FileSystemObject Object) oder andere langlaufende ActiveX-Komponenten (wie Kreditkartenabbuchungssysteme) zu. Dann kann ein Hinaufsetzen des AspProcessorThreadMax Wertes einen drastischen Performence-Gewinn bedeuten.
Der MSDN Artikel How to Tune the ASPProcessorThreadMax (ID Q238583) behandelt ausführlich die Einstellungen und Auswirkungen dieses Parameters auf die Webserver Performance.
Ein Wert von 25 für den Parameter AspProcessorThreadMax auf einem Dual-Prozessor System bedeutet, daß jeder IIS- Prozeß bis zu 50 "Working Threads" beinhalten kann.
Wenn die Application Protection unter IIS 5.0 auf High (Isolated) gesetzt ist, so hat jede isolierte IIS Applikation ihren unabhängigen Satz von "Working Threads". Die Einstellung für die Application Protection finden Sie bei den Website Eigenschaften (Properties) auf dem Home Directory Tab (siehe Bild 5).
Der Parameter kann nur unter Windows 2000 gesetzt werden. Unter Windows NT 4.0 müßen Sie den Registry-Eintrag HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ASP\ mit einem Tool wie Regedt32 ändern. Unter IIS 4.0 kann auch eine Erniedrigung des Wertes eine Performance- Steigerung bringen.
Das Einstellen und Tunen eines Webservers nach Gefühl, oder das Begutachten der Resultate ohne echte Zugriffslast auf den Webserver ist nicht zielführend.
Das Microsoft Web Application Stress Tool erlaubt es Ihnen, hohe Zugriffszahlen auf einen Webserver zu simulieren und ihn damit in einer bestimmten Konfiguration bis an seine Grenzen auszutesten. Erst dadurch ist es möglich, die Auswirkungen von Webserver Tuning, ASP-Code und Datenbank-Optimierung direkt in einem wirklichkeitsnahen Belastungsszenario testen. Siehe auch den TechNet Artikel Know Your Limit: The Capacity-Planning Tool Nobody Knows.
Das Tool Adsutil.vbs ist ein Komandozeilentool, geschrieben in VBScript, das mittels CScript.exe Kommando ausgeführt werden kann. Das Tool ist im Option Pack 4.0 und im IIS 5.0 enthalten.
Mit Hilfe dieses Tools lassen sich Werte und Einträge in der Metabase des IIS direkt auslesen und setzen (siehe MSDN Artikel Description of Adsutil and MetaEdit Utilities Used to Modify the Metabase, ID: Q240225).
Das Tool Adsutil.vbs befindet sich im \Inetpub\AdminScripts Ordner (Windows 2000) bzw. im %SystemRoot%\system32\inetsrv\adminsamples Order (Windows NT 4.0). Die Dokumentation zum Tool können Sie am IIS unter der Adresse http://localhost/iishelp/iis/htm/adminsamples/adsutil.htm aufrufen. Eine Beschreibung der anderen Administrationsskripts für IIS finden Sie unter http://localhost/iishelp/iis/htm/adminsamples/default.htm.
Der Metabase Editor erlaubt das Auslesen und Verändern von IIS Metabase Werten in einem Windows-basierenden Tool das ähnlich wie das Regedt32 Tool für die Registry arbeitet (siehe Bild 6).
Bild 6: Metabase Editor (MetaEdit)
Eine Beschreibung zur Verwendung des Metbase Editor Tools findet sich im MSDN Artikel Description of Adsutil and MetaEdit Utilities Used to Modify the Metabase, ID: Q240225).
Das Metabase Editor Tool ist frei über den Download des Site Server Commerce Edition Resource Kit erhältlich (Downloadlink am Ende des Artikels). Nach dem Download und Entpacken rufen Sie die Datei Setup2.exe auf. Diese installiert das Metabase Editor Tool. Gegebenenfalls müßen Sie das Tool manuell in der Registry registrieren. Dies geschieht durch einen Doppelklick auf die Datei RegisterMetaEdit.reg.
Außerdem findet sich das MetaEdit Tool noch im Windows 2000 Server Resource Kit und im IIS 4.0 Resource Kit.
Webservertuning ist eine Wissenschaft für sich, jede Website hat ein anderes Anforderungsprofil, eine andere Sitestruktur und andere Daten, die vom Server zum Client geschickt werden.
Das Werkzeug XTune erlaubt es dem interessierten Webadministrator, die Parameter eines IIS Webservers, die für die Performance des Servers und von Websites verantwortlich sind, in einem einfach zu bedienenden, grafischen Tool auf MMC Basis einzustellen.
This printed page brought to you by AlphaSierraPapa
Auswirkung des Providers auf die Datenbank Performance
http:/www.aspheute.com/artikel/20000419.htm
Einführung in Performance Monitoring
http:/www.aspheute.com/artikel/20000428.htm
Geschwindigkeitsmessungen in ASP
http:/www.aspheute.com/artikel/19990919.htm
HTTP Komprimierung in IIS5
http:/www.aspheute.com/artikel/20001115.htm
Monitoring von ASP
http:/www.aspheute.com/artikel/20000502.htm
Performance Monitoring a la .NET
http:/www.aspheute.com/artikel/20000809.htm
Serverseitiges Caching mit XCache
http:/www.aspheute.com/artikel/20000817.htm
Virtuelle Verzeichnisse umbenennen
http:/www.aspheute.com/artikel/20030911.htm
XTune Revisited
http:/www.aspheute.com/artikel/20011002.htm
Configuring IIS to Handle Heavy Usage
http://support.microsoft.com/support/kb/articles/Q229/8/14.ASP
Description of Adsutil and MetaEdit Utilities Used to Modify the Metabase
http://support.microsoft.com/support/kb/articles/Q240/2/25.ASP
Enhancing Performance in Internet Information Server 4.0
http://support.microsoft.com/support/kb/articles/Q235/4/61.ASP
How to Tune the ASPProcessorThreadMax
http://support.microsoft.com/support/kb/articles/Q238/5/83.ASP
IIS 4.0 Tuning Parameters for High-Volume Sites
http://msdn.microsoft.com/workshop/server/feature/tune.asp
Know Your Limit: The Capacity-Planning Tool Nobody Knows
http://www.microsoft.com/TechNet/iis/technote/knowcpt.asp
Microsoft Web Application Stress Tool
http://webtool.rte.microsoft.com
Site Server Commerce Edition Resource Kit
http://msdn.microsoft.com/library/winresource/ssreskit/rk_listall_reskittools.htm
The Art and Science of Web Server Tuning with IIS 5.0
http://www.microsoft.com/windows2000/library/operations/web/tuning.asp
Web Server Performance Optimization white paper
http://www.microsoft.com/backstage/whitepaper.htm
Windows 2000 Server Resource Kit
http://www.microsoft.com/windows2000/library/resources/reskit/default.asp
Xtune
http://www.postpointsoft.com/home/xtune_what_is_xtune.htm
©2000-2006 AspHeute.com
Alle Rechte vorbehalten. Der Inhalt dieser Seiten ist urheberrechtlich geschützt.
Eine Übernahme von Texten (auch nur auszugsweise) oder Graphiken bedarf unserer schriftlichen Zustimmung.