Webworking

Nachrichten und Artikel des WebTeams

Inhalt

Wartungsarbeiten am Blogdienst: 26.04. ab 15 Uhr

Am Dienstag, 26.04.2011 ab 15 Uhr bis ca. 16 Uhr findet eine Wartung des Blogdienstes ( http://blogs.fau.de/ ) statt. In diesem Zeitraum ist der Zugriff auf den Blogdienst nicht oder nur eingeschränkt möglich.

Der Grund dafür ist, dass der VM-Server des Blogdienstes mit mehr Systemspeicher (RAM) aufgerüstet werdem muss. Bei dieser Gelegenheit werden auch sämtliche Software-Pakete (auch der Kernel) auf neuesten Stand gebracht.

Hintergrund: Der RAM wird knapp. Seit einiger Zeit sind die Seitenzugriffe und Feedabfragen auf das Blogsystem signifikant gestiegen, so daß dadurch der SWAP des VM-Servers intensiv genutzt wird um den RAM für Caching frei zu machen. Da der SWAP vom maximalen verfügbaren Speicher abhängt, kann es passieren, daß der Apache (plus PHP u. APC-Erweiterung) unter diese Bedingungen nicht optimal läuft und daher unerwartete Prozessfehler z.B. zwischen Thread und APC-Index (Cache) stattfinden, die den Webserver in “Panik” versetzt.
Die Kombination Apache + PHP + APC ist ansonsten eine sehr leistungsfähige Plattform und WordPress ist mit APC fast viermal schneller als ohne, aber irgendwann erreichen auch die Möglichkeiten der Software ihre Grenzen, so daß nur mehr eine grundlegende Verbesserung der Systemausstattung weiterhilft.

Cache Control bei dynamischen Webauftritten

Mit dem neuen Apache 2.2 haben wir zur Steigerung der Performance das Cache-Modul von Apache aktiviert (“Mem Cache”).

Dieses Modul bewirkt, daß Webseiten, darunter auch dynamisch generierte Seiten, vom Webserver zwischengespeichert werden und beim nächsten Request wieder ausgeliefert werden, ohne daß dann die Seite nochmals von vorne “gebaut” werden muss. Dadurch ergibt sich teilweise ein merkbarer Performancegewinn.
Dem Voraus gingen verschiedene Tests, über die ich im letzten Jahr bereits in diesem Blog berichtete. Vgl: Vorbereitungen zum Umstieg auf den Webcluster: Performance

Leider mussten wir nun feststellen, daß es doch Probleme gibt:  Bei Webangeboten, die verschiedene Inhalte immer vom selben Skript liefern (z.b. immer von einer “index.php”), kann es passieren, daß zunächst der falsche Content geliefert wird und der richtige erst dann kommt, wenn man  die Seite nochmal explizit neu anforderte.

Eine genauere Analyse der Vorgänge zeigte zwei mögliche Ursachen, bzw Lösungen:

  • Das Skript liefert bei der Generierung der Inhalte bislang keine Antwort-Header, die spezielle Cache-Control-Anweisungen beinhalten. So fehlt beispielsweise eine solche Zeile in den Antwort-Headern:

    Cache-Control: no-cache

    Die Lösung wäre also, daß das Skript um diese oder andere Angaben ergänzt wird.
    Bei einigen CMS, wie beispielswiese bei Typo3, gibt es entsprechende Funktionen und auch Extensions, die dies automatisch setzen.

  • Sollte das Problem nicht über eine Anpassung oder Konfiguration der Skripte lösbar sein, besteht ansonsten die Möglichkeit, daß das Caching für den kompletten Webauftritt oder für einzelne Verzeichnisse daraus serverseitig deaktiviert wird.
    Im dem Fall, daß der Webauftritt auf unseren Webcluster liegt, wird dies das Webteam tun. Wir werden dann in der Konfiguration des Webauftritts die Anweisung 

    CacheDisable  /

    ergänzen.
    Im Webmasterportal kann jeder angemeldete Webmaster über die Ansicht der Konfiguration, unter dem Unterpunkt “VirtualHost-Konfiguration”, nachprüfen, ob und welche Direktiven gesetzt sind und ob diese dabei ist.

Sollten Sie hinsichtlich dieses Themas Unterstützung des Webteams benötigen, setzen Sie sich bitte mit uns in Kontakt.

 

Tipp zur Performancegewinnung

Webauftritt die mit dem Web-Baukasten der Uni erstellt werden, enthalten mehrere interaktive Skripten. Die Seiten werden während des Aufrufs dynamisch erzeugt.
Zwar sorgen Caches und Proxys bereits dafür, daß bekannte Seiten schnell ausgeliefert werden, jedoch kann die echte neugenerierung einer Seite auf unseren alten Servern (die auch noch nicht loadbalanced sind) doch schon 1.2 Sekunden dauern.

Ein Tipp zur Verbesserung der Performance betrifft solche Webauftritte, bei denen die Zielgruppennavigation (in den Seiten oben) nicht benutzt wird oder sich so gut wie nie ändert.

Die Zielgruppennavigation wird in der SSI-Datei websource/ssi/kopf.shtml definiert.

Dort finden Sie folgenden HTML-Code:

 <div id="hauptmenu">
          <h2 class="skip"><a name="hauptmenumarke" id="hauptmenumarke">Zielgruppennavigation</a></h2>
          <!-- #include virtual="/cgi-bin/navigation/inhalt.pl?type=ziel&noU=1&nodfn=1"  -->
       </div>

Dabei wird bei jedem Laden der Seite das Skript aufgerufen, welches die Navigation aufbaut. Auch in dem Fall, wenn gar keine Zielgruppennavigation definiert ist.

Um hier einen Performancegewinn zu erfahren, gehen Sie folgendermaßen vor:

a) Wenn Sie gar keine Zielgruppennavigation nutzen, löschen Sie einfach die Zeile mit der Include-Anweisung.

b) Wenn Sie eine Zielgruppennavigation haben, dann schreiben Sie die statisch an der Stelle des Includes. Kopieren Sie sich dazu die URI /cgi-bin/navigation/inhalt.pl?type=ziel&noU=1&nodfn=1 und fühen davor ihren DOmainnamen an. Diese Adresse rufen Sie dann im Browser auf.
Die erhalten dann das erzeugte dynamische Menu.
Von diesem kopieren Sie sich den Quellcode, den Sie dann in der websource/ssi/kopf.shtml anstelle der Include-Anweisung einsetzen.