IIS TUNING – CACHE UND PERFORMANCE

Posted by Calvijn on January 05, 2018

Viele Web-Entwickler werden dieses Scenario kennen:

Eine Web Anwendung (WebSeite / WebApplikation) wurde entwickelt und läuft Stabil im Netz (Internet / Intranet). Allerdings könnte sie noch “etwas” schneller reagieren.

Jetzt wird man versuchen die interne Logik der Anwendung zu optimieren. Server Side Code (PHP, ASP, Perl,…), Client Side Code (JavaScript,…) Nach optimieren wird man feststellen das diese Optimierung nur einen minimalen Schub bringt (Wenn überhaupt).

Der nächste Schritt wird die Optimierung des Datenabrufes sein. (Datenbank Queries zwischenspeichern, Indexe auf der Datenbank, Prozeduren, Datenbank Ansichten, Funktionen innerhalb der Datenbank). Diese Optimierung wird schon einen besseren Schub bringen, allerdings nicht in dem erhofftem Bereich, wenn man sich noch anderen Anwendungen im Vergleich ansieht.

Wer sich in der Linux Welt bewegt wird schon etwas tiefer in die Kenntnisse rund um Tomcat oder Apache Webservern greifen müssen. (Viel Glück und Geduld ;)) Wer sich in der Windows Welt bewegt hat es etwas einfacher. Vorallem wenn man einen IIS als Webserver hat und eine WebAnwendung mit ASP.Net im Hintergrund. Denn der IIS bringt viele Optionen bzgl. des Cachings sowie das ASP.Net, das ein eigenes Caching Framework besitzt, welches für ASP WebForms entwickelt wurde. Natürlich wird es auch in ASP.Net MVC intern benutzt. Folgende Cache Varianten stehen für die Performance Optimierung zur Verfügung: Kernel Cache

  • IIS Output Cache
  • ASP.Net Output Cache
  • ASP.Net Object Cache
  • Database Cache / SQL Cache

IIS Kernel Cache (http.sys)

Der Kernel Cache ist eine Treiber basierte Anwendung der auf dem HTTP Protokoll des IIS sitzt. Dieser “horcht” den HTTP Traffic ab und stellt statische Inhalte sowie hoch frequenzierte Inhalte in seinen eigenen Cache (Zwischenspeicher). Somit ist er einer der schnellsten Zwischenspeicher im IIS. Da er eine Anfrage für o.g. Inhalt direkt aus seinem Zwischenspeicher ausliefert ohne das diese Anfrage an den IIS weitergegeben wird.

IIS Output Cache

Die IIS Ausgabezwischenspeicherung kommt zum Zug wenn man die entsprechenden Regeln (Ausgabezwischenspeicherungsregel / Output Cacherule) aktiviert und anwendet. Diese basieren auf Dateiendungen *.html, *.aspx, *.asmx, etc Man kann im IIS jede Endung eintragen und das Cache Verhalten für diese Resourcen beeinflußen. Auf diesem Wege kann man auch Response Header setzen die vom IIS mit angehängt werden. Allerdings gibt es hier einige Fallstricke die bei eingeschalteten Kompressionen (Kompression für Statischen / Dynamischen Inhalt) zu unerwünschten bzw. zu fehlverhalten führen können. Standard mäßig ist der IIS Output Cache für Statische Inhalte aktiviert. Das heißt das Bilder, Stylesheets (CSS), JavaScript (JS) bereits von Haus aus gecacht werden.

ASP.Net Output Cache

Dieser Cache kommt vom ASP.Net Framework und wird programmatisch “aktiviert”. Dabei muß in der Programmierung das “OutputCache” Attribut für die Ausgabe verantwortlichen Methoden gesetzt werden. Eine weitere Variante wäre dieses Attribut in der Markup Datei zu definieren. Was meistens bei kleinen ASP WebForms Projekten gemacht wird. (Nicht schön aber funktional) Mehr dazu im nächsten Artikel.

ASP.Net Object Cache

Der Object Cache zählt eigentlich nicht zu den IIS Cache Varianten, da allerdings in den meisten Fällen eine ASP.Net Anwendung über den IIS gehostet wird muß diese Variante auch hier genannt werden. Der Object Cache ist eine rein Programmatische Geschichte und zählt dabei zu einem guten Programmierstil mit Objekt Orientierung. Da bei einem Objekt Orientierten Programmier Ansatz viele Objekte erzeugt werden die direkt im Arbeitsspeicher liegen kann man auch viele Daten die man für die Anwendung benötigt in den RAM legen. Eigentlich sollte es gängige Praxis sein nicht jeden Aufruf direkt von der Datenquelle neu abzurufen. Leider wird dieses von vielen Entwicklern nicht berücksichtigt. Mehr dazu im nächsten Artikel.

Database Caching / Database Performance

Auch diese Variante ist kein wirklicher IIS Cache, denn es geht mehr um die Performance des Datenabrufes von einer Datenbank. Wer Datenbank sagt sollte sich grundsätlich folgende Fragen stellen:

  • Index? Indizies erstellt ? Ja, es gibt mehr als nur den PrimaryKey Index…
  • Falls bei jeder Anfrage immer die gleichen Abfragen (Queries) erstellt werden: Zwischengespeicherung der Abfragen ? (Object Caching)
  • Ja, auch die abgerufenen Daten zwischengespeichern ? (Betrifft vorherigen Punkt) Falls Indizies erstellt wurden: Fragmentierung ? etc

IIS Cache Tuning

ObjectCacheTTL ist ein Registry Schlüssel in der Computer Registry, der die Lebensdauer eines Objektes innerhalb des Caches definiert. Wer jetzt nach diesem Schlüssel sucht sollte feststellen das dieser Schlüssel im Standard Fall nicht gesetzt ist. Den solange dieser Schlüssel nicht existiert wird die Standard Lebensdauer von 120 Sekunden übernommen. ScavengerPeriod ist auch ein Registry Schlüssel in der Computer Registry. Allerdings definiert dieser die Zeitspanne wann der Scavenger in Aktion treten soll. Der Scavenger ist verantwortlich dafür das der Cache nicht voll läuft und somit den Arbeitsspeicher lahm legt. Sobald er Aktiv wird, löscht er einträge aus dem Cache, wobei es keine Garantie gibt das er immer die ältesten Einträge löscht. Vielmehr geht es dabei um die gesamt Aufrufe einer Resource. Auch dieser Schlüssel ist im Standard Fall nicht gesetzt. (Falls schon jemand die Suche angeworfen hat :))

Nur Statischer Inhalt ?

Dann auf zum permanenten FrequentlyHit

Falls sich auf den Seiten kein Dynamischer Inhalt befindet, sprich: Die Inhalte benötigen keine Aktualisierungen. (Sollte bei einer ASP.Net Anwendung theoretisch sehr selten vorkommen. Aber, Ja es gibt auch solche Anwendungen)

Dann gibt es die möglichkeit eine angeforderte Seite schon beim ersten Aufruf als Frequenzierten Treffer (FrequentylHit) zu behandeln.

Der IIS besitzt von Haus aus die Fähigkeit stark frequenzierte Seiten in seinem Kernel Cache in komprimierter Form zu cachen. Dieses Funktion wurde ursprünglich zu IIS 6.x Zeiten eingefügt um gegen DoS Attacken gerüstet zu sein. Damit der Server auch bei erhöhten Aufrufen noch erreichbar bleibt. Die Standard einstellungen liegen bei 2 zu 10. Damit ist gemeint: Zwei Treffer innerhalb von Zehn Sekunden markieren einen Resourcen Aufruf als frequenzierten Treffer. Somit wird diese Resource automatisch im Kernel Cache gespeichert.

Falls man wirklich nur statischen Inhalt hat dann kann man die Standard Einstellungen von 2 auf 1 setzen. Die 10 Sekunden Zeitspanne kann man dabei getrost ignorieren. Da jeder Aufruf automatisch zu einem FrequentlyHit wird.

Achtung!

Da jeder Aufruf direkt im Kernel Cache landet, wird auch keine Anfrage an die ASP Handler des IIS geleitet. Formulare werden somit nicht mehr funktionieren (Kontakt Formulare, Login, Logout, …) solange sich diese Resource im Kernel Cache befindet.