Original-URL des Artikels: https://www.golem.de/0401/29269.html    Veröffentlicht: 19.01.2004 11:01    Kurz-URL: https://glm.io/29269

Interview: Die Zukunft von PHP-Beschleunigern

Golem.de im Gespräch mit PHP-Accelerator-Entwickler Nick Lindridge

Der Wechsel des Turck-MMCache-Entwicklers Dmitry Stogov zu Zend und die damit verbundene Einstellung der Entwicklung des PHP-Beschleunigers Turck-MMCache hat für einige Verunsicherung bei PHP-Nutzern gesorgt, bietet Zend doch seinerseits ein entsprechendes kommerzielles Produkt an. Und auch um den kostenlosen, wenn auch nicht freien, PHP-Accelerator ist es seit geraumer Zeit ruhig geworden. Golem.de sprach mit Nick Lindridge, Entwickler des PHP-Accelerator, über die Zukunft seiner Software, Anforderungen an PHP-Encoder und Möglichkeiten, entsprechende Funktionen in die offizielle PHP-Distribution zu integrieren.

Der Ressourcenbedarf der Scriptsprache von PHP lässt sich durch so genannte PHP-Beschleuniger deutlich senken. Die kompilierten Scripte werden dabei im Speicher und auf der Festplatte zwischengespeichert, so dass die Scripte nicht bei jedem Aufruf erneut geparst und übersetzt werden müssen. Dabei bieten sich diverse Lösungen an, die zwar eine sehr ähnliche Leistung bieten, sich aber im Preis deutlich unterscheiden.

Während Zend mit der Zend Performance Suite eine kommerzielle Lösung im Angebot hat, buhlen mit dem PHP-Accelerator, Turck-MMCache und APC mindestens drei kostenlose und zum Teil freie Lösungen um die Gunst der Server-Administratoren. Doch die Entwicklung der kostenlosen Lösungen scheint auf eher wackeligen Beinen zu stehen. Ein Update des PHP-Accelerator gab es seit geraumer Zeit nicht, die Entwicklung der GPL-Software von Turck-MMCache ist zumindest ausgesetzt, da dessen Entwickler Dmitry Stogov mittlerweile für Zend an anderen Verbesserungen für PHP arbeitet. APC wird mittlerweile immerhin als PECL-Erweiterung angeboten, Nutzer berichten hier aber noch immer von kleineren Problemen.

Golem.de sprach mit Nick Lindridge, Entwickler des PHP-Accelerator und Gründer der Firma ionCube, die sich bislang allerdings in erster Linie auf die Entwicklung eines kommerziellen PHP-Encoders konzentriert. Diese Software nutzt einen ähnlichen Ansatz wie die PHP-Beschleuniger, um es PHP-Entwicklern zu erlauben, PHP-Scripte auch ohne Quelltext zu verbreiten.

Golem.de: Es gab seit geraumer Zeit kein neues Release des PHP-Accelerator (PHPA). Planen Sie weitere Updates der Software - schließlich wird sie kaum mit dem kommenden PHP 5 laufen?

Nick Lindridge: PHP5 ist eine neue Sprache, PHPA für PHP4 wird daher nicht mit PHP5 laufen. Ein Update für PHPA ist aber geplant.

Golem.de: Einige Leute haben von PHPA zu Turck-MMCache gewechselt, da sie einige Probleme mit PHPA hatten. Zudem ist Turck-MMCache GPL-Software, was möglicherweise ein weiterer Grund sein könnte, um zu wechseln. Hat ionCube Pläne, Turck-MMCache in Zukunft zu unterstützen?

Nick Lindridge: Wir tun das bereits mit dem aktuellen Loader in der Version 2.4, der vor einigen Wochen erschienen ist.

Aus unserer Sicht stellen Open-Source-Erweiterungen ein potenzielles Sicherheitsproblem dar, wenn auch ein geringes, und daher unterstützt der Loader zwar die Installation von Open-Source-Erweiterungen, erlaubt es aber nur, kodierte Dateien in einer solchen Umgebung auszuführen, wenn dies der jeweilige Entwickler erlaubt hat. Diese Option wird Nutzern des Encoders in der nächsten Version des Encoders zur Verfügung stehen. Ist MMCache installiert, bekommt die Software so letztendlich nur Dateien zu sehen, die nicht kodiert sind. Das heißt zum einen, dass MMCache diese Dateien nicht beschleunigen kann, zum anderen aber auch, dass es den von ionCube aus den kodierten Dateien wiederhergestellten Code nie zu Gesicht bekommt, was aus Sicherheitsgesichtspunkten ideal ist.



Golem.de: Wie steht es um die Zukunft der Beschleunigung von PHP-Applikationen? Es hat den Anschein, dass, auch wenn es einige Unterschiede in der Geschwindigkeit der verschiedenen Ansätze gibt, diese im Vergleich zu den Vorteilen, die ein Beschleuniger bietet, eher gering ausfallen. Gibt es noch viel Spielraum für weitere Verbesserungen?

Nick Lindridge: In der Tat, die meisten Caches nutzen mittlerweile dieselben Techniken. Als PHPA ins Leben gerufen wurde, war Zend Cache, wie es damals hieß (um kurz nach der Veröffentlichung von PHPA in Zend Accelerator umbenannt zu werden) klar führend. APC und andere Open-Source-Caches lagen leistungsmäßig deutlich abgeschlagen dahinter. Mir war klar, dass diesen anderen Caches ein bestimmter Kniff fehlte. Die Lösung für eine gesteigerte Leistung ist es, den kompilierten Code direkt aus dem Shared-Memory auszuführen, auch wenn man einen Datei-Cache hat, den PHPA als eigentlichen Cache benutzt. Drei Wochen, nachdem ich mit der Arbeit an PHPA angefangen habe, verfügte PHPA, ausgestattet mit dem gleichen SHM-Cache, über die gleiche Leistung wie der Zend Cache. APC und MMCache haben anschließend diese Technik übernommen, und so bieten alle eine ähnliche Leistung.

Es gibt Techniken, die man nutzen kann, um über das Maß hinauszukommen, was mit einem reinen Code-Cache machbar ist, und weitere Leistungssteigerungen zu erreichen, ohne Änderungen am Code vornehmen zu müssen. Vielleicht kommen noch in diesem Jahr Produkte auf den Markt, die dies leisten.

Abgesehen vom Cache-Code lassen sich Leistungssteigerungen erreichen, indem man sowohl weniger abarbeiten lässt als auch die Leistung dessen steigert, was abgearbeitet wird. Content-Caching wie das Zwischenspeichern der HTML-Ausgaben kann genau dies sehr effektiv leisten. Nach unserer Erfahrung lassen sich die meisten Applikationen von Endnutzern in den Bereichen Programm- und Datenbank-Design verbessern, um merkliche Leistungssteigerungen zu erreichen. Im Übrigen gilt bei Seiten, für die Performance ein echtes Problem darstellt, dass die Konzentration auf einen Bereich allein nicht ausreichend ist. Die maximale Leistung zu erreichen setzt die richtige Hardware in einer korrekten Konfiguration, eine wohl designte Systemarchitektur, eine optimierte Datenbank und Werkzeuge wie Caches voraus.

Golem.de: Die Notwendigkeit eines Beschleunigers, um die Geschwindigkeit von PHP zu erhöhen, scheint ein wenig lächerlich, schließlich sollte es kein großes Problem darstellen, solche Kernfunktionen zusammen mit PHP auszuliefern. Wo ist in diesem Fall das Problem?

Nick Lindridge: Ich sehe das weitgehend genauso und natürlich könnte auch ein Code-Optimierer als Standard mitgeliefert werden. Es gab zuletzt Bemühungen, die aktuelle Version des APC in PHP zu integrieren (Anm. der Redaktion: APC steht als PECL-Modul zu Verfügung), und dies ist ein positiver Schritt. Ich bin mir sicher, dass die Leser sich selber zusammenreimen können, warum PHP in einer eingeschränkten Version angeboten wird.



Golem.de: IonCube hat sich zunächst auf einen Encoder konzentriert, der es erlaubt, PHP-Scripte zu veröffentlichen, ohne deren Quelltext herauszugeben. Wie ist der aktuelle Status dieser Bemühungen?

Nick Lindridge: IonCube ist einer der Marktführer im Bereich von Encoding-Technologien für PHP. IonCube wurde im Jahr 2002 gegründet, um der Nachfrage nach einer bezahlbaren und qualitativ hochwertigen Encoding-Lösung nachzukommen. IonCube hat den Markt seitdem zunächst mit einem innovativen und einzigartigen Online-Encoding-Dienst angeführt und kurze Zeit später ein eigenständiges Encoding-Werkzeug veröffentlicht. Seit der ersten Version im Winter 2002 hat der eigenständige Encoder einen neuen Standard für Encoding-Software gesetzt. Bevor ionCube auf den Markt trat, gab es nur eine sehr teure, unzuverlässige Encoding-Software, die viele wirklich notwendige Funktionen vermissen ließ. Der ionCube Encoder hingegen wurde zu einem bezahlbaren Preis angeboten und mit nützlichen Funktionen ausgestattet, die funktionieren. Sicherheit ist eines der fundamentalen Design-Ziele von Encoding-Werkzeugen. Bei den meisten PHP-Encoding-Tools, die derzeit auf dem Markt sind, geht es vor allem darum, den Quelltext zu kodieren und während der Ausführung wieder zu dekodieren, um diesen dann mit Hilfe des eval()-Ausdrucks von PHP ausführen zu lassen. Zwar bieten diese Tools einen deutlichen Kostenvorteil gegenüber den teuersten Alternativen, allerdings darf man eben nicht nur diesen Kostenvorteil betrachten, da sie kaum oder gar keine Sicherheit bieten. Es mag einige Leser überraschen, aber der Mangel an Sicherheit von solchen Quelltext-basierten Produkten liegt vor allem daran, wie einfach es ist, die PHP-Engine dazu zu bringen, den wiederhergestellten Quelltext wieder sichtbar zu machen, wenn er kompiliert werden soll. Eine zusätzliche Zeile C in der PHP-Engine reicht aus, um den Quelltext bei diesen Produkten wiederherzustellen, was wir als großes Problem ansehen.

Unsere Encoding-Werkzeuge hingegen verwenden einerseits einen optimierten kompilierten Code, bei dem der Quelltext eliminiert wird noch bevor das Encoding stattfindet, zum anderen eine spezielle Ausführungseinheit innerhalb des Loader. Dies führt dazu, dass die kodierten Dateien nur in Form von Binärdaten, nicht als Quelltext wiederhergestellt und dann innerhalb des Loader ausgeführt werden statt in der Open-Source-Ausführungsroutine von PHP. Auch wenn kein System immun gegen Angriffe von Hackern ist, stellt dies doch eine signifikant größere Hürde für ein Reverse Engineering dar.

Golem.de: Könnten Sie sich ein allgemeines Framework vorstellen, das in die offizielle PHP-Distribution integriert verschiedene Encoder unterstützt und somit die Hürde eliminiert, zunächst einen Loader installieren zu müssen?

Nick Lindridge: Zunächst einmal ist es wichtig zu erkennen, dass es letztendlich aus Sicherheitsgründen notwendig ist, einen Closed-Source-Loader zu haben. Ein "One-Loader-Fits-All-Produkt" ist technisch möglich, aber es ist realistisch gesehen unwahrscheinlich, dass so etwas passiert. Ein Ansatz wäre aber, die Loader-Komponenten der wichtigsten Anbieter standardmäßig mit jeder PHP-Distribution auszuliefern, einschließlich der offiziellen Distribution der PHP-Group. Es gäbe zwar einige kleine logistische Herausforderungen, um dies umzusetzen, aber prinzipiell wäre dies ein gangbarer Ansatz, der der PHP-Community zugute kommen würde.  (ji)


Verwandte Artikel:
PHP-Beschleuniger vor dem Aus? (Update)   
(07.01.2004, https://glm.io/29137 )
PHP-Accelerator 1.3.2 wieder ohne Aktivierungs-Schlüssel   
(30.07.2002, https://glm.io/20995 )
Zend Performance Suite soll PHP-Applikationen beschleunigen   
(04.11.2002, https://glm.io/22465 )
PHP-Encoder soll Quelltexte vor Blicken Dritter schützen   
(24.07.2002, https://glm.io/20908 )
PHP-Encoder auf Basis des PHP Accelerator angekündigt   
(18.06.2002, https://glm.io/20383 )

Links zum Artikel:
ionCube: http://www.ionCube.com
PECL: Alternative PHP Cache (.net): http://pecl.php.net/package/APC
PHP Accelerator (.uk): http://www.php-accelerator.co.uk
Turck MMCache (.net): http://turck-mmcache.sourceforge.net/
Zend Technologies (.com): http://www.zend.com/

© 1997–2019 Golem.de, https://www.golem.de/