HHVM schickt PHP Webseiten auf die Überholspur

Über 80% aller Webseiten weltweit werden mit PHP betrieben.

Der schnelle Einstieg in die Programmiersprache sorgt für eine große Beliebtheit bei den Programmierern. Ob quick&dirty oder sauber objektorientiert. Alles ist möglich.

Große CMS oder Shopsysteme nutzen PHP. Module für verschiedene Datenbanksysteme stehen zur Verfügung um Daten aus PHP heraus zu verwalten.

Mit fast jedem PHP Update wurde die Programmiersprache schneller aber um gruße Shop mit tausenden von einzelnen PHP Dateien zu betreiben fehlt es teilweise doch noch an der nötigen Performance. Denn im Netz gilt: Je schneller eine Seite desto geringer die Absprungrate der Besucher.

Also wird um jede Millisekunde gefeilscht.

Es gibt verschiedene Ansätze um die Geschwindigkeit von PHP Anwendungen zu steigern:

  1. Optimieren von Code
  2. Caching von Daten
  3. Caching von Code

Wir gehen davon aus, dass der Code optimal läuft da wir uns nur mit 1 und 2 beschäftigen wollen.

Caching von Daten

Um Daten zu cachen gibt es verschiedene Möglichkeiten. Anwendungen legen Daten im Dateisystem oder Speicher ab und greifen auf diese zu um sie nicht erneut berechnen zu müssen. Memcached wird dazu gerne verwendet. PHP kann über Memcached Daten im RAM Speicher ablegen und sehr schnell darauf zugreifen.

Varnish ist ebenfalls ein beliebter Seitencache. Damit brauchen Webseiten nicht bei jedem Aufruf neu berechnet zu werden sondern werden aus einem Cache heraus ausgeliefert.

Caching von Code

Eien PHP Datei wird vor jedem Ausführen in einen Bytecode übersetzt. Wenn man nun eine PHP Datei häufig benötigt könnte man diesen Bytecode auch in einen Cache ablegen um die Zeit des Übersetzens zu sparen (OpCode Cache).

Die PHP Beschleuniger können neben dem Cachen des Bytescodes auch noch Optimierungen vornehmen und die Geschwindigkeit nochmals zu steigern. Es gibt verschiedene OpCode Caches (eAccelerator, APC, Zend OpCache).

Was ist nun HHVM?

HHVM (HipHopVirtualMachine) ist ein eigenständiges Programm welches PHP Dateien zunächst in einen ByteCode übersetzt (HHBC). Dieser ByteCode wird dynamisch zur Laufzeit durch eienn  Jit Compiler in Maschinencode compiliert. Da HHVM hierzu eine eigene PHP Implementation hat werden ggf. nicht alle Funktionen der normalen PHP Version unterstützt.

Auf diese Weise kann eine PHP Anwendung innerhalb von HHVM um ein vielfaches schneller und ressourcensparender laufen als innerhalb eines normalen PHP Interpreters.

Möchten Sie einen HHVM Server nutzen? Kein Problem. Auf unseren Root-, Managed, SVN- und Git sowie Shophosting Servern können wir Ihnen gerne einen HHVM einrichten.

Wenn Sie Fragen haben schreiben Sie uns

Vorteile einer Cloudumgebung für Magento

Die technischen Anforderungen an einen Magento Onlineshop sind stets dieselben. Die Kunden erwarten eine hohe Verfügbarkeit, eine gute Performance und einen optimalen Schutz ihrer persönlichen Daten. Aus der Perspektive des Shopbetreibers ist darüber hinaus wichtig, dass die Hardwareressourcen jederzeit einem steigenden Bedarf angepasst werden können, ohne den Betrieb für ein Serverupgrade zu unterbrechen. Cloudhosting drängt sich als Antwort auf diese Herausforderungen geradezu auf, weil seine grundlegende Idee in der Hardwareabstrahierung besteht. Rechenleistung und Storage werden dabei als Services verstanden, die unabhängig von einer konkreten Hardware zur Verfügung gestellt werden.

Redundante Infrastruktur

Vorteile einer Cloudumgebung für Magento shop hostingDas wichtigste Konzept der Ausfallsicherheit von IT-Systemen ist und bleibt die Redundanz. Sämtliche Hardwarekomponenten sind mehrfach vorhanden, um defekte Teile sofort überbrücken zu können. Dazu wird zunächst eine leistungsfähige Enterprise Plattform benötigt, die ausreichende Hardwareressourcen zur Verfügung stellt, um einzelne Ausfälle ohne Einbußen bei der Performance kompensieren zu können. Eine redundante Infrastruktur ist jedoch deutlich mehr als nur ein Ersatzteillager. Redundanz bedeutet in der IT, dass defekte Komponenten ohne Betriebsunterbrechung automatisch überbrückt werden. Dazu muss nicht nur die Hardware redundant ausgelegt sein, sondern auch alle Daten und laufenden Prozesse müssen dupliziert werden. Ein angenehmer Nebeneffekt der Redundanz besteht darin, dass sämtliche Daten auch zwischen den Datensicherungen mehrfach vorhanden sind. Somit sind im Ernstfall auch neue Kundendaten, die seit der letzten Sicherung gespeichert wurden, nicht verloren. Natürlich ist die alte Regel, dass redundante Datenträger kein Backup ersetzen, weiterhin uneingeschränkt richtig. Aber redundante Datenträger können so manches Rollback ersparen, das immer mit Datenverlusten verbunden ist. Magento verfügt zwar über eine sehr gute Rollback-Funktion – aber nutzen möchte man sie doch lieber nicht!

Cloudhosting ist den Alternativen überlegen

Vorteile einer Cloudumgebung für Magento shop hostingÜber welche Alternativen müssen wir hier überhaupt sprechen? Sicher nicht über den selbst betriebenen Server. Dieser Weg kommt allenfalls für große Unternehmen mit eigenem Rechenzentrum in Betracht. Für die Mehrzahl der Shopbetreiber kommt jedoch der interne Serverbetrieb ohnehin nicht infrage, weswegen die einzige wirkliche Alternative in der Anmietung eines realen Servers statt eines virtuellen Servers besteht. Das Rechnen in der Cloud kann in diesem Vergleich auf zahlreiche Vorteile verweisen. Hardwareressourcen unserer Enterprise Plattform können jederzeit bedarfsgerecht zugewiesen werden, außerdem garantieren wir in unserem Paket VMWare Gold eine extrem hohe Verfügbarkeit von 99,99 Prozent, die durch die Redundanz der Plattform ermöglicht wird. Der Unterschied zwischen 99,9 Prozent und 99,99 Prozent Verfügbarkeit ist übrigens keine reine Zahlenspielerei, an der nur Nerds ihren Spaß haben. Dieser Unterschied bedeutet knapp acht Stunden weniger Ausfallzeit pro Jahr – wie viele Kundenkontakte sind das bei Ihnen? Diesen zahlreichen Vorteilen steht als einzige Einschränkung gegenüber, dass das managed Cloudhosting keinen Root Zugriff erlaubt. Für Softwareentwickler kann das ein Problem sein, aber kaum für einen Shopbetreiber. Dafür werden Sicherheitsupdates im Betriebssystem automatisch eingespielt.

Einige Worte zur Datensicherheit

Secured Online Cloud Computing Concept with Business Man protectNicht zuletzt durch eine indifferente Berichterstattung der Medien wird allein schon der Begriff „Cloud“ oft mit Datenschutzproblemen assoziiert. Bei genauerem Hinsehen wird schnell klar, dass die meisten der bekannt gewordenen Probleme nicht technischer Natur sind. Problematisch ist eher, dass viele große Anbieter amerikanischem Recht unterliegen und daher den US-Behörden Hintereingänge öffnen müssen. Aus technischer Sicht bieten professionelle Rechenzentren zweifelsohne einen besseren Schutz gegen externe Angriffe, als ein normales Unternehmen selbst gewährleisten könnte. Mit Cloud oder Nicht-Cloud hat das Ganze wenig zu tun, sondern nur mit können und wollen!

MySQL per SSH Tunnel zu einem Root- oder Managed-Server

Es kann manchmal notwendig sein, lokal einen MySQL Zugriff auf eine entfernte Datenbank zu realisieren.

Um dies zu bewerkstelligen gibt es zwei Möglichkeiten.

1. Der MySQL Server wird nach extern freigeschaltet der Benutzer bekommt externe Zurgiffsrechte
2. Man baut einen SSH Tunel zum MySQL Server auf

Punkt 1 muss vom Provider bzw. vom Verwalter der Webhosting Umgebung durchgeführt werden.

Punkt 2 können Sie selbst realisieren sofern Sie SSH Zugriff auf Ihr Paket haben. Bei unseren SVN Hosting, Shop Hosting und Server Angeboten ist das Standardmäßig inklusive.

Herstellen eines SSH Tunnels um sich mit einer Datenbank auf einem Root Server oder Managed Server zu verbinden

Per Linux:

Am einfachsten ist es über Linux

ssh logt sich also mit dem Benutezrnamen „benutzer“ auf dem Server mein-server.de ein. Lokal wird der Port 3306 geöffnet.

Alles was an den lokalen Port 3306 geschickt wird, leitet ssh über den Tunnel an dbserver.mein-server.de:3306 weiter.

Man kann sich also lokal per mysql -h 127.0.0.1 mit der Datenbank verbinden.

Per Windows (Putty)

Hier muss unter Connections->SSH->Tunnels lediglich der Port eingestellt werden.

MySQL per SSH Tunnel zu einem Root  oder Managed Server webhosting shop hosting root server managed server MySQL per SSH Tunnel zu einem Root  oder Managed Server webhosting shop hosting root server managed server

Nach dem Klick auf open wird die gewählte SSH Verbindugn geöffnet und ein Tunnel hergestellt.

Eine Verbindung an Port 3306 würde also über den Tunnal an den dbsrv.mein-server.de Port 3306 weitergeleitet werden.

Man muss lediglich darauf achten, dass der lokale Port nicht bereits vergeben ist z.B. durch eine eigene lokale MySQL Installtion.

Magento Hosting ist sehr langsam

„Mein Magento Hosting ist sehr langsam“ stand in der Mail, die vom Support geöffnet wurde.

Da dies eien sehr allgemeine Aussage ist, klärte der zuständige Mitarbeiter erstmal mit dem Kunden ab, wie sich das Geschwinigkeitsproblem äussert.

Trotz Varnish Cache, Memcached, APC kam es zu gelegentlichen hängern, die teilweise sogar die Datenbank lahm legten.

Bei einem Magento Hosting kommt es auf das Zusammenspiel aller Komponenten an

Die Analyse ergab, dass das Problem regelmäßig auftrat. Nach einiger Zeit kam es zu einem Stillstand des MySQL Servers da dieser mit Anfragen auf die Tabelle category_catalog_flat_store so beschäftigt war, dass er keine anderen Anfragen beantworten konnte. Die Laufzeiten für die Abfrage steigerte sich von 1,5 Sekunden auf teilweise über 100 Sekunden.

Der Varnish Cache hat zwar einiges puffern können jedoch ist auch der Cache irgendwann abgelaufen. In dem Fall wird dann die Seite neu berechnet. Wenn die Trägheit z.B. durch ein aufwändiges Menü erzeugt wird, muss das Menü für alle Benutzer, die in dem Augenblick online sind, neu berechnet werden. So kann es auf einen Schlag zu 20, 30 oder mehr aufwenigen Abfragen kommen. Wenn diese Abfragen dann lange dauern potenziert sich das Problem. Während der DB Server damit beschäftigt ist, laufen neu Abfragen auf, die dann in der Queue landen. So läuft innerhalb von wenigen Sekunden die Datenbank voll, bis nichts mehr geht.

Es wurden dann falsche Indexfelder in der category_catalog_store_flat Tabelle sowie der core_url_rewrites ausgemacht, die Abfragezeiten von mehreren Sekunden erzeugten. Nach dem Zurücksetzen der Indexfelder war die Laufzeit wieder bei wenigen Millisekunden.

Der Kunde bemerkte zwar die Verbesserung bemängelte jedoch weiterhin eine Trägheit, die zwar nicht mehr so schlimm war aber trotzdem nicht in Ordnung.

Oftmals befinden sich im Magento Store mehrere Fehler

Nachdem das Laufzeitverhalten mit NewRelic weiter analysiert wurde konnten am Quellcode und ind er Datenbank keine Probleme gefunden werden.

Das finden mehrere Fehler macht die Analyse immer sehr schwierig. Man hat einen Fehler gefunden und kommt nicht zum erwünschten Ziel. Es erfordert dann viel Erfahrung um trotzdem Fehler für Fehler zu finden.

Nachdem als zusätzliche Fehlerquelle der Memcached identifiziert wurde, und dieser neu gestartet wurde war das Problem jedoch behoben. Magento hat offensichtlich etwas im Memcached abgelegt was zu langen Laufzeuten geführt hat.

Magento Hosting mit Plesk 11.5, Apache, Nginx und Varnish Cache

Varnish ist ein sehr beliebter Seitencache für Webseiten.

Der Geschwindigkeitsvorteil kann je nach verwendeten Backend ein vielfaches betragen da Webseiten nicht bei jedem Abruf berechnet sondern statisch ausgeliefert werden.

Gerade im Bereich von Magento Hosting und Shop Hosting wird er sehr häufig eingesetzt.

Ich möchte hier einmal zeigen, wie man den Cache in einer Plesk Umgebung installiert.

Er wird als Daemon installiert und zwischen Webserver und Benutzer gehängt. Seiten werden entweder aus dem Cache geladen oder vom Webserver (Backend Server) abgerufen.

Um den Varnish im Plesk einzubinden sind einige Schritte erforderlich.

1. Installation des Varnish Caches
2. Erstellen einer custom Konfiguration im Plesk (CentOS: /usr/local/psa/admin/conf/templates/custom)

Installation des Varnish Caches für das Magento Hosting

Der Varnish Cache ist auf einem RH/CentOS sehr einfach installiert:

Dadurch wird der Varnish in der Version 3 installiert.

Vorsicht: Sofern andere Respoitory Varnish zur Verfügung stellen sollte mit yum priorities eine Reihenfolge festgelegt werden.

/etc/varnish/default.vcl:

/etc/sysconfig/varnish:

Erstellen einer custom Konfiguration für Plesk

Damit der Webserver von Plesk die Daten vom Varnish abruft und nicht direkt vom Webserver ist eine Konfigurationserweiterung notwendig.

Plesk ist standardmäßig so konfiguriert, dass eingehende Verbindungen vom NGinx Reverseproxy entgegen genommen werden.

Nginx liefert lokale Dateien ggf. direkt aus und übergibt weiter Anfragen an den Apache Server, welcher i.d.R. auf Port 7080 horcht. Hier klinken wir uns ein und schieben dem System den Varnish Cache unter.

Im Ordner custom können eigene Konfigurationen abgelegt werden, die Plesk statt der eigenen verwendet.

Kopieren Sie die default/nginx.php aus dem default in den custom Ordner.

Bearbeiten Sie die Datei custom/nginx.php und fügen oben (Zeile 3) zwischen den beiden PHP Zeilen den upstream backend_varnish ein:

[lokale ip adresse] ersetzen Sie bitte durch die Adresse, über die Ihre Webseite erreichbar ist.

Der Upstream Server dient nun als Deklaration, woher der NGinx seine Daten bekommen soll, sobald er als proxy_pass den Namen des Upstreams übergeben bekommen hat.

Sollte der Varnish Cache mal nicht Online sein, verwendet NGinx den Apache Server da dieser als Backup Verbindung hinterlegt ist.

Kopieren Sie die default/domain/service/proxy.php Datei in den custom/domain/service Ordner.

Bearbeiten Sie diese nun wie folgt (custom/domain/service/proxy.php):

An der file_exists Funktion läßt sich gut sehen, dass das Script erst prüft, ob eine Datei im /etc/varnish ordner liegt, die als Namen den Domainnamen gefolgt von .enable hat (z.B. lcube-webhosting.de.enable). Ist dies der Fall wird der Varnish aktiviert. Wenn nicht, werden die Dateien normal vom Webserver abgerufen. Auf diese Weise kann der Varnish durch setzen einer Datei aktiviert oder deaktiviert werden.

Nach dem setzen oder löschen der enable Datei muss

ausgeführt werden.

Ggf. muss ein Addon installiert werden. Für Magento kommt z.B. Turpentine in Frage.

Nicht für jede Anwendung ist der Varnish Cache geeignet. Wenn viele Dynamische Daten abgerufen werden und die Aktualität der Daten von entscheidender Bedeutung ist (z.B. bei Warenkörbe sowie beim SVN Hosting oder Git Hosting) sollte man entsprechende URLs in die Ausnahmen eintragen bzw. auf Varnish verzichten.