© saicle/Shutterstock.com
PHP Magazin
Die optimale Systemarchitektur finden

Die optimale Systemarchitektur finden

Mit dem Erfolg kommen früher oder später die Probleme: Der irgendwann mal aufgesetzte Server ist der ständig steigenden Last nicht mehr gewachsen. Keine Frage, mehr Hardware muss her! Doch die alte Systemarchitektur lässt die Verteilung der Last auf mehrere Server nur sehr bedingt zu. Der ideale Zeitpunkt also, die Architektur zu überdenken und dabei das Ganze auch auf der Softwareseite auf ein neues Fundament zu stellen.

Arne Blankerts


Moderne Webanwendungen sind weit weg von dem, was den LAMP-Stack einst hat groß und erfolgreich werden lassen: Vorbei die Zeit, in der man statistische Seiten mit ein wenig integriertem PHP aufgepeppt hat und somit die volle Kontrolle und vor allem die Hauptarbeit weiterhin beim Webserver lag. Heutige Anwendungen sind größer und komplexer geworden, bedürfen vielschichtigerer Infrastrukturen. Wer heute noch PHP mit HTML vermischt, gilt als rückständig – selbst wenn PHP unabhängig vom Rest der Anwendung auch als Templatesprache eine durchaus gute Figur machen kann. Betrachtet man den strukturellen Aufbau aktueller Webseiten jedoch einmal unabhängig von der eingesetzten Templatesprache und -Engine und aus der Sicht des Browsers, wird man schnell erkennen, dass auf den initialen Seitenabruf eine Vielzahl an weiteren Anfragen an den oder die Webserver geschickt werden müssen. Da wären zunächst die eingebundenen Bilder, CSS-­Sprites oder Icons sowie die CSS-Regeln. Letztere werden dabei oft und gerne in verschiedene Dateien – passend für die jeweiligen Browser – aufgeteilt. Und auch Java­Script darf heute in einer modernen Anwendung natürlich nicht fehlen. Weitere Dateien also, die der Client nachladen muss.

Webserver haben heute also mehr denn je zu tun, müssen sie doch das ständige Mehr an Daten über die Leitung schicken. Doch obwohl die zu übertragenden Datenmengen steigen, spielen die in den Server direkt integrierten Skriptsprachen bei der Hauptarbeit eine immer kleinere Rolle. Diese Erkenntnis stellt das Konzept einer in den Webserver eingebundenen Laufzeitumgebung wie PHP ganz deutlich in Frage: Warum muss diese Runtime für jeden Request, egal ob er durch PHP verarbeitet werden wird, instantiiert werden? Vor allem inklusive all der von PHP selbst dynamisch nachgeladenen Erweiterungen?

Wir brauchen ein CDN, oder?

Eine mögliche Konsequenz ist die Einführung eines so genannten Content Delivery Networks – kurz CDN –, um die Application Server von den Zugriffen auf statische Inhalte zu entlasten. Ein derartiges System kann, gerne auch geografisch verteilt, die Auslieferung der Inhalte ohne zusätzlichen und unnötigen Overhead vornehmen. Ideal und leicht umzusetzen, wenn es keinerlei zu prüfende Beschränkungen für den Zugriff gibt, wie dies zum Beispiel für Produktbilder in einem Shop der Fall sein dürfte. Schwieriger wird es erst, wenn die Auslieferung vom Nutzerstatus oder anderweitigen Bedingungen abhängt: Soll hier mehr als nur die Client-IP geprüft oder ein...

PHP Magazin
Die optimale Systemarchitektur finden

Die optimale Systemarchitektur finden

Mit dem Erfolg kommen früher oder später die Probleme: Der irgendwann mal aufgesetzte Server ist der ständig steigenden Last nicht mehr gewachsen. Keine Frage, mehr Hardware muss her! Doch die alte Systemarchitektur lässt die Verteilung der Last auf mehrere Server nur sehr bedingt zu. Der ideale Zeitpunkt also, die Architektur zu überdenken und dabei das Ganze auch auf der Softwareseite auf ein neues Fundament zu stellen.

Arne Blankerts


Moderne Webanwendungen sind weit weg von dem, was den LAMP-Stack einst hat groß und erfolgreich werden lassen: Vorbei die Zeit, in der man statistische Seiten mit ein wenig integriertem PHP aufgepeppt hat und somit die volle Kontrolle und vor allem die Hauptarbeit weiterhin beim Webserver lag. Heutige Anwendungen sind größer und komplexer geworden, bedürfen vielschichtigerer Infrastrukturen. Wer heute noch PHP mit HTML vermischt, gilt als rückständig – selbst wenn PHP unabhängig vom Rest der Anwendung auch als Templatesprache eine durchaus gute Figur machen kann. Betrachtet man den strukturellen Aufbau aktueller Webseiten jedoch einmal unabhängig von der eingesetzten Templatesprache und -Engine und aus der Sicht des Browsers, wird man schnell erkennen, dass auf den initialen Seitenabruf eine Vielzahl an weiteren Anfragen an den oder die Webserver geschickt werden müssen. Da wären zunächst die eingebundenen Bilder, CSS-­Sprites oder Icons sowie die CSS-Regeln. Letztere werden dabei oft und gerne in verschiedene Dateien – passend für die jeweiligen Browser – aufgeteilt. Und auch Java­Script darf heute in einer modernen Anwendung natürlich nicht fehlen. Weitere Dateien also, die der Client nachladen muss.

Webserver haben heute also mehr denn je zu tun, müssen sie doch das ständige Mehr an Daten über die Leitung schicken. Doch obwohl die zu übertragenden Datenmengen steigen, spielen die in den Server direkt integrierten Skriptsprachen bei der Hauptarbeit eine immer kleinere Rolle. Diese Erkenntnis stellt das Konzept einer in den Webserver eingebundenen Laufzeitumgebung wie PHP ganz deutlich in Frage: Warum muss diese Runtime für jeden Request, egal ob er durch PHP verarbeitet werden wird, instantiiert werden? Vor allem inklusive all der von PHP selbst dynamisch nachgeladenen Erweiterungen?

Wir brauchen ein CDN, oder?

Eine mögliche Konsequenz ist die Einführung eines so genannten Content Delivery Networks – kurz CDN –, um die Application Server von den Zugriffen auf statische Inhalte zu entlasten. Ein derartiges System kann, gerne auch geografisch verteilt, die Auslieferung der Inhalte ohne zusätzlichen und unnötigen Overhead vornehmen. Ideal und leicht umzusetzen, wenn es keinerlei zu prüfende Beschränkungen für den Zugriff gibt, wie dies zum Beispiel für Produktbilder in einem Shop der Fall sein dürfte. Schwieriger wird es erst, wenn die Auslieferung vom Nutzerstatus oder anderweitigen Bedingungen abhängt: Soll hier mehr als nur die Client-IP geprüft oder ein...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang