AOit Linux Admin Blog

Ab und an möchte man eine bestimmte zufällige Anzahl von Ergebnissen aus einer MySQL Tabelle Abfragen.

Hier die entsprechende Syntax:

SELECT * from meine_tabelle ORDER BY RAND() LIMIT 25

Wer für die Zukunft gewappnet sein will, sollte sich umbedingt schon jetzt mit evtl. deprecated Meldungen auseinandersetzen die bei PHP 5.3 auftauchen.

Z.B. der alte xt:Commerce 3 Shop hat relativ viele Anweisungen die deprecated sind:

PHP Deprecated:  Function eregi() is deprecated
PHP Deprecated:  Function split() is deprecated
PHP Deprecated:  Function session_is_registered() is deprecated

Diese Shop Version sollte man sowieso aufgrund der Tatsache das sie nicht mehr weitergepflegt wird ersetzen/updaten. Entweder man nimmt die 4er Version direkt von xt:commerce oder aber das Projekt xtcModified.

Eine Liste aller deprecated Funktionen gibt es hier:

http://de2.php.net/manual/en/migration53.deprecated.php

Finden kann man die deprecated Meldungen entweder in dem man display_errors einschaltet und entsprechend den Loglevel oder in dem man die Fehler in ein seperates Logfile schreiben lässt (auf Produktivsystemen immer die bessere Variante).

*xt:Commerce ist ein geschützter Name der Firma xt:Commerce GmbH.

Mittlerweile ist die offizielle Version 2.0 von Cakephp erschienen.

Ein paar kurze Eckdaten:

• Performance ca. 50% schneller gegenüber Cakephp 1.3 (liegt stark am neuen lazy-loading und das der PHP4 Support weggefallen ist)
• PHPUnit als Testframework
• Download: https://github.com/cakephp/cakephp/tarball/2.0.0
• Dokumentation: http://caky.de

Wenn man mit Git arbeitet möchte man irgendwann einmal Code von anderen importieren.
Zum Beispiel um ein Plugin in seine Cakephp Applikation zu importieren. Oder man hat selbst verschiedene Projekte und möchte bestimmten Code wiederverwenden. Bei uns haben wir zum Beispiel das Frontend für unsere Kunden und das Backend für die Administratoren komplett von einander getrennt. Aber z.B. der CSS Code ist in beiden Projekten nahezu gleich. Und auch bestimmte Plugins kommen in beiden vor. Es wäre ein fast unmöglicher Aufwand in beiden Projekten immer den identischen Code zu haben.

Daher haben wir ein Konzept gefunden wie man mit solchen Abhängigkeiten flexibel umgehen kann.

$ cd mein-projekt
$ git clone <url-anderes-projekt> mein-unterprojekt
$ git add mein-unterprojekt/

Wichtig ist hierbei das beim letzten Befehl auch ein / am Ende steht. Andernfalls versucht Git den eigenen viel komplexeren Submodul-Modus zu benutzen.

Jetzt hat man praktisch zwei verschachtelte Git Repositorys. Wenn man nun das Unterprojekt updaten will, geht man wie folgt vor:

$ cd mein-unterprojekt
$ git pull

Das funktioniert weil immer das näherliegende .git Verzeichnis benutzt wird. Ein weiterer großer Vorteil ist das wir das Unterprojekt an unsere Projektbedürfnisse anpassen können.

Ein kleiner Wermutstropfen tritt auf wenn ein anderes Projektmitglied den Code vom Hauptprojekt "cloned". Der Code vom Unterprojekt ist zwar enthalten, aber nicht die direkte Abhängigkeit zum Unterrepository. Das lässt sich aber relativ einfach lösen in dem man bei Änderungen dann einfach den Ordner löscht mit "rm -Rf mein-unterprojekt" und wie oben gezeigt wieder neu cloned. Daher packen wir in jedem von uns angelegten Unterprojekt auch eine Readme mit den nötigen URL Infos hinein.

Eine unserer Aufgaben im Linux Server Support ist es Kunden beim Optimieren Ihrer Seite(n)/Server zu unterstützen. Meistens betrifft dieses Servereinstellungen zu verfeinern. Manchmal müssen wir uns aber auch auf die Anwendungsebene begeben um zu analyisieren wo Performance verloren geht.

In dem jetztigen Fall ging es um ein VB Forum mit über 200.000 Seiten. MySQL und Apache waren schon wunderbar eingestimmt. Trotz der fast 200 Onlineuser waren die Seitenwerte unter 1 Sekunde. Eigentlich alles optimal. Aber der Betreiber merkte das der Googlebot immer länger zum Spidern brauchte.

Nach einer Analyse mit Jmeter viel mir auf das Beitragsseiten zum Vergleich zu anderen ca. 400ms länger also im Schnitt 800ms zum Laden brauchten. Im Schnitt hatte die Seite einen Wert von 319ms (nur dynamischer Content).

Ich denke viele wären über solche Werte schon sehr froh. Aber da die Googlebewertung einer Seite auch davon abhängt wie schnell Sie sich Spidern lässt und 400ms * 200.000 Seiten = ca. 22h schnellers crawlen bedeutet, hatten wir eine neue Herausforderung vor uns.

Mit der zur Hilfenahme von xdebug gelang es uns relativ schnell den Übeltäter mittels Profiling ausfindig zu machen. Und zwar setzt der Kunde zur Seo Optimierung VBSEO ein. Diese Extension machte in der vorhandenen Version sehr viel Gebrauch von preg_replace() (über 80.000 Aufrufe pro Seite). Des Weiteren viel uns auf das sich im APC Usercache gerade einmal 80 KByte an Daten befanden. Jetzt hätte man natürlich den Source Code durchforsten können, aber das ist für mich bei komplexeren Anwendungen immer nur die letzte Wahl.

Denn man kann so schnell die Updatefähigkeit verlieren und man sollte zunächst versuchen bei den Entwicklern nachzufragen. Offiziell gab es zwar noch kein Update aber eine inoffizielle Entwicklerversion. Diese sollte eigentlich das Cache Problem lösen, was leider nicht wirklich klappte, dafür aber waren die Beitragsseiten nun genauso schnell wie alle anderen.

Wie in unserem Beitrag "Datenschutz mal richtig umsetzen" geschrieben sollte man aufsteigende (z.B. MySQL autoincrement) ID Primary Felder vermeiden. Wenn man sich ein wenig umschaut merkt man schnell das UUIDs diesen Zweck erfüllen könnten.

Zwar sind diese eigentlich aus einem ganz anderen Grund erfunden worden, aber warum das Rad neu erfinden wenn ein Quasi Standard auch den Zweck erfüllt. Nebenbei erhält man damit auch die Möglichkeit Datensätze unabhängig (offline) vom MySQL Server zu erzeugen. Denn man erzeugt ja nun selbst die Primary ID und wenn man sich an den UUID Standard hält sollten auch keine Konflikte auftreten.

Unter Cakephp geht das ganze auch sehr Schmerzfrei indem man einfach das ID Feld statt mit int(11) mit char(36) anlegt. Dann kümmert sich Cakephp selbständig um die Erzeugung der UUID Nummern.

Heute haben wir einen unschönen Bug im PHP-FPM Modul von Froxlor entdeckt. Das TMP Verzeichniss (üblicherweise unter /var/customers/tmp/KUNDE zu finden) wird nicht mit den richtigen Rechten ausgestattet.

Einen Bugreport haben wir auch schon erstellt:

http://redmine.froxlor.org/issues/846

Kurze Hintergrundinfo zu PHP-FPM:

PHP-FPM ist ein neuer Fastcgi Process Manager, der eine sauberere Rechte und Prozessverwaltung für PHP pro Kunde ermöglicht.