blog.t8d.de

Für unsere Memcached Implementation für sixgroups benötigten wir eine einfache Möglichkeit, diesen neu zu starten/zu leeren. Da alle unsere Entwickler auf dem gleichen Server arbeiten, haben wir auf dem Entwicklungsserver 4 einzelne Memcached-Instanzen laufen – je auf einem eigenen Port.

Leider wird beim Neustart via /etc/init.d/memcached restart immer nur der default Port 11211 verwendet. Auch nach längerem Suchen haben wir keine Möglichkeit gefunden, den Daemon auf einem anderen Port neu zu starten. Falls jemand hierfür eine einfache Lösung weiß, freuen wir uns über einen Kommentar.

Hier unser Workaround via Shellskript: Wir löschen zunächst die Instanz, die anhand des Ports aus der Prozessliste identifiziert wird und starten dann den Memcached Daemon für diesen Port neu:

wobei 11212 der Port des Daemons ist.

Vielleicht nicht die eleganteste Lösung, aber es funktioniert. Hoffe das hilft jemanden, der vor dem gleichen Problem steht.

update: Da WordPress leider partout die einfachen Anführungszeichen in dieser Kombination zu Backticks umgeschrieben hat, gibt es das obige Codebeispiel nun in Bildform.

Hatte gestern mit einem kleinen Ärgernis zu kämpfen, das mir bisher nicht begegnet war: Wenn man PHP auf der command line (CLI) ausführt, wird unter Ubuntu für die Konfiguration eigentlich die Datei /etc/php5/cli/php.ini benutzt. Da ich für eine Anzahl an Unit Tests PHP mehr Speicher geben wollte, erhöhte ich den Wert Memory limit :

memory_limit = 512M

Leider wirkte die Änderung sich nicht aus. Mein  Testscript brach immer wieder mit einem “Memory Allocation Error” ab. Durch diesen Blogpost bin ich dann aber draf gekommen woran es lag:

Die php.ini muss für jeden User lesbar sein, sonst werden die Default Einstellungen benutzt, wenn man php nicht als root ausführt. Ein

chmod 644 /etc/php5/cli/php.ini

behebt das Problem.

Da wir bei six groups jetzt auf mehre Applikationssever umstellen, müssen wir unsere Sessions in Zukuft in der Datenbank speichern.
Wie das zusamen mit Doctrine funktioniert steht beim Lampjunkie sehr gut beschrieben. Weiterhin haben wir folgendes gelernt:

1.  Die Session Lifetime muss größer als 0 sein (wir hatten zuvor den Hack fürs Verhindern von Session Timeouts verwendet und erstmal ging daher nicht viel)
2. In der php.ini müssen bestimmte Werte geändert werden, damit alte Sessions automatisch aus der DB entfernt werden:

   session.gc_probability = 1
   session.gc_divisor     = 100
   session.gc_maxlifetime = Wert in settings.yml

3. Update: Sehr wichtig ist außerdem, dass man die session_id Spalte mit einem Index versieht, damit das Updaten der Sessions in der DB nicht ewig dauert. Sonst bekommt man schnell Probleme. Bei uns war z.B. bei ca. 80.000 Sessions in der DB Schluss und die kommen relativ schnell zusammen wenn man den session timeout auf einen Tag stellt, denn Crwaler erzeugen ebenfalls Einträge in der Tabelle.  Die Update Queries brauchen dann sehr lange – in unserm Fall bis zu 15 Sekunden! Also sollte die Tabelle session so modifiziert werden:

   ALTER  TABLE  `sessions`  ADD  INDEX (  `sess_id`  );

Nachdem ich mich im ersten Teil der Serie mit Markup im Allgemeinen beschäftigt habe, behandele ich heute einen Punkt, mit dem man bei der Geschwindigkeit des Seitenaufbaus wirklich etwas rausholen kann: Möglichkeiten, Dateien durch verschiedene Arten von Kompression und sog. Obfuscating zu verkleinern.

• ZIP-Kompression für HTTP Header verwenden
  Zip Kompression für die HTTP-Übertragung beschleunigt den Aufbau von Webseiten teilweise sehr deutlich, ein entscheidender Faktor für den Erfolg einer Website. Dabei werden die Dateien mithilfe des Apache Moduls mod_deflate (früher mod_gzip) ZIP-komprimiert übertragen und erst vom Browser entpackt, was alle modernen Browser unterstützen. Wie sich das Modul auf einem eigenen Server schnell einrichten lässt, erklärt Howtoforge.
  Falls die ausgelieferten HTML Dateien relativ groß sind (ab ca. 15KB), kann es aber zu einem psychologisch negativen Effekt kommen, denn die Seiten werden erst aufgebaut, wenn sie komplett übertragen sind. Wer mit dem Modem surft , sieht im Zweifel einige Sekunden eine weiße Seite. Wenn die Source-Files also sehr groß sind, dann sollte man die Kompression für diese Dateitypen(z.B. php, html) evtl. abstellen. Außerdem benötigt die Kompression CPU-Resourcen auf dem Server. Eine gute Richtlinie, wann man das Modul einsetzten sollte und wie man es weiter konfiguriert (z.B. für Benchmarks) findet ihr bei Forever For Now.
• JavaScript Dateien verkleinern
  In JavaScript-Dateien gibt es normalerweise eine Reihe von Kommentaren, Tabulatoren und Umbrüchen, die je nach Coding-Stil eine Menge Platz verbrauchen. Diese lassen sich aber mit einigen Tools einfach entfernen. Teilweise beherrschen diese auch sog. Obfuscating, d.h. wirkliches Verkürzen von Code durch Umschreiben (z.B. Verkürzung von Variablennamen…). Zu diesen Packern gehört z.B. der Kompressor des Dojoo Toolkits oder Dean Edward’s Packer , mit dem auch die komprimierte Version von jQuery erstellt wird. Er entfernt nicht nur Kommentare und unnötigen Whitespace, er obfuscated auch. Dadurch wird eine JS-Datei ganz schnell mal um 50 Prozent kleiner. Darüber hinaus existieren eine Reihe weiterer Versionen, mit der man die Kompression dynamish durchführen kann, z.B. vor dem Upload auf den Liveserver. Leider ließen sich einige meiner JS-Dateien nicht komprimieren, insbesondere Prototype zeigte sich hier relativ widerspenstig und funktionierte nicht mehr. Wie man diese Probleme im Zweifel lösen kann erklärt Andrew Dupont in Packaging Prototype.
• Leerzeichen, Tabs und Zeilenumbrüche entfernen
  Wer aus irgend einem Grund, die oben beschriebenen Packer-Tools oder mod_deflate nicht einsetzen kann, kann zumindest überflüssige Leerzeichen, Einrückungen und Zeilenumbrüche aus seinen Dateien entfernen, was je nach Coding-Stil die Dateigröße zum Teil noch einmal deutlich reduziert. Für die, die bereits mod_deflate und JS-Packer verwenden, bringt dieser Tipp nichts.