Der Proxy-Cache Varnish ist einer der Schlüssel zu der hervorragenden Leistung unserer Drupal-Hosting-Pakete. Er speichert Seiteninhalte für eine bestimmte Zeit im RAM und kann sie danach um Größenordnungen schneller ausliefern als der dahinter liegende Apache-Webserver.
Zunächst speichert Varnish statische Daten wie Grafiken und CSS-Stylesheets. Mit auf Caching optimierten Drupal-Distributionen wie Pressflow Drupal oder Cocomore Drupal kann Varnish dann sogar ganze Seiten cachen und damit die Seitenauslieferung enorm beschleunigen.
Die Haltedauer im Cache wird dabei durch Einstellungen in Drupal und in der Webserver-Konfiguration beeinflusst. Für eine maximale Entlastung des Webservers will man diese Haltedauer natürlich möglich hoch setzen.
Nun kann es sein, dass man eine Node ändert und möchte, dass sie sofort in der neuen Version ausgeliefert wird. Nutzer unserer Pakete DrupalCONCEPT PRO/dedicated und DrupalCONCEPT ELITE bieten wir dazu einen Zugang zur Administrations-Schnittstelle des Caches an, über die das Drupal-Modul Varnish die sofortige Cache-Aktualisierung auslösen kann.
Details zu dieser Varnish-Integration finden Sie bei unseren Tips & Tricks.
Der Proxy-Cache Varnish gehört bei allen unseren Drupal-Hosting-Paketen zur grundlegenden Infrastruktur. Er beschleunigt nicht nur die Auslieferung von Grafik- und CSS-Dateien, sondern kann beim Einsatz moderner Drupal-Distributionen auch die dynamisch erzeugten Seiten zwischenspeichern.
Wie wir heute festgestellt haben, reicht es bei Drupal 7 nicht aus, in den Leistungs-Einstellungen das externe Caching zu aktivieren, damit Varnish neben Dateien auch Seiten speichert.
In der aktuellen Version von Drupal 7 ist zusätzlich das Setzen einer Variablen in settings.php notwendig. Erst dann sendet Drupal die nötigen HTTP-Header, die Varnish das Caching von Seiten erlauben.
Näheres zu diesem Problem und seiner Lösung finden Sie in unserem Help Center.
Als Betriebssystem unserer Server verwenden wir grundsätzlich die LTS-Releases (Long Term Support) von Ubuntu Linux, aktuell also Version 10.04 "Lucid Lynx".
Wie wir heute herausfanden, sind die von Ubuntu gelieferten Solr-Pakete für Tomcat (solr-tomcat-1.4.0+ds1-1) und Jetty (solr-jetty-1.4.0+ds1-1) unvollständig; es fehlt ein wichtiger Symlink. Dies führt bei bestimmten Suchbegriffen zu folgender Fehlermeldung am Beginn eines Java-Tracebacks:
java.lang.NoClassDefFoundError: org/apache/lucene/index/memory/MemoryIndex
Solr findet hier die Bibliothek "lucene-memory" nicht, was durch Setzen des folgenden Symlinks behoben werden kann:
$ cd /usr/share/solr/WEB-INF/lib $ ln -s ../../../java/lucene-memory.jar lucene-memory.jar
Nach dem Neustart von Tomcat/Jetty ist das Problem beseitigt.
Wir haben diesen Bugfix bereits in unser Servermanagement aufgenommen, sodass er in allen unseren Solr-Installationen automatisch angewandt wird.
Um die Unterschiede zwischen verschiedenen Datei-Revisionen anzeigen zu lassen, gibt es das Kommando git diff. Auch beim Mergen von Branches ist, spätestens bei Konflikten, ein Überblick über die jeweiligen Veränderungen wichtig. Aufs Macs wird mit dem Xcode-Entwicklungspaket auch die Applikation FileMerge (opendiff) installiert, die in solchen Fällen sehr hilfreich ist. Dieser Techblog-Eintrag beschreibt, wie FileMerge bequem mit git integriert werden kann.
Gerade bekamen wir einen Support-Anruf eines verzweifelten Kunden. Ein Entwickler hatte versehentlich seine Test-Version der settings.php eingecheckt und mit seinen Änderungen hochgeladen. Natürlich war die Website damit offline.
Dank des zugrunde liegenden git-Repositorys konnten wir sein Versehen innerhalb weniger Sekunden korrigieren. Es ist schließlich Sinn und Zweck von Version Control Software, alle vorigen Versionen einer Datei zu archivieren.
Mit dem Kommando
$ git checkout HEAD^ sites/default/settings.php
war die Produktionsversion der Datei wieder da, und nach
$ git add sites/default/settings.php $ git commit -m "Restore settings.php" $ git push origin master
war die Website wieder in Betrieb. Natürlich hätten wir auch ein reguläres Backup der Datei gehabt, aber über das git-Repository ging die Reparatur deutlich schneller. Und noch wichtiger: Der Kunde weiß jetzt, wie er solche Versehen selbst wieder rückgängig machen kann.
Drupal-Entwicklern ist das Konzept der Hooks vertraut. Hooks sind Software-Schnittstellen, die es erlauben, in einen bestehenden Prozessablauf zusätzliche externe Funktionen zu integrieren. In Drupal kann man mit Hooks z.B. vor dem Speichern eines neuen Inhalts zusätzliche Prüfungen oder Aktionen einbauen. In gleicher Weise funktionieren die Hooks im Version Control System git. Ein Beispiel, wie ich mit git-Hooks meine Arbeit vereinfachen konnte, möchte ich in diesem Artikel beschreiben.
Auf vcs.freistil-hosting.net betreiben wir öffentliche git-Repositorys, die unter anderem die aktuellen Versionen von Drupal und OpenAtrium zum Checkout anbieten. Um unseren Kunden viel Aufwand zu ersparen, pflegen wir hier auch eine eigene Drupal-Distribution namens "Drupal Allstars" mit einer Sammlung der beliebtesten Contrib-Module (CCK, Views, etc.). Drupal-Anwender, die dieses Repository als Quelle nutzen, können mit einem einfachen "git pull" auf einen Schlag das Update von Drupal und aller in der Distribution enthaltenen Module durchführen.
Wir erweitern den Umfang der in "Drupal Allstars" enthaltenen Module von Zeit zu Zeit; die Liste ihrer aktuellen Versionen ist als Textdatei MODULES.TXT in der Distribution enthalten. Und um genau diese Textdatei geht's jetzt.
Erscheint ein neues Update für eines der Module, aktualisiere ich es in meinem lokalen Branch, indem ich die alte Version entferne und die aktuelle mit Drush herunterlade. Eventuelle neue Dateien werden mit git add hinzugefügt und mit den anderen Änderungen durch git commit zunächst lokal und durch git push auf vcs.freistil-hosting.net eingecheckt.
Und schon wieder ist es passiert! Vergessen, MODULES.TXT zu aktualisieren. Das jetzt erneut notwendige commit/push ist irgendwann einfach nur peinlich.
Hier kommen die Hooks ins Spiel, mit denen ich in die git-Abläufe eingreifen kann: Durch ihre Nutzung kann ich die Aufgabe der Listen-Aktualisierung von meinem löchrigen Gedächtnis zum verlässlichen git verlagern! Ideal geeignet ist hier der "pre-commit"-Hook, über den das Update der Modulliste noch rechtzeitig vor dem Commit erledigt werden kann.
Ich habe dazu einfach das bisher manuell aufgerufene Script, das alle aktuellen Modulversionen in MODULES.TXT schreibt, aus meinem Scriptverzeichnis in die Datei hooks/pre-commit innerhalb des git-Repositorys verschoben und — ha! — vor jedem Commit wird jetzt noch schnell MODULES.TXT aktualisiert. Jetzt wird die Datei nie wieder einen veralteten Stand enthalten. git rocks.
+49 761 45895590
Mo.-Fr. 09:00-17:00 (CET)