Objektorientiert bei PHP ressourcig?

[*Markus]

Hallo,

im nächsten Jahr habe ich ein größeres Webprojekt geplant.
Abgesehen davon, dass ich mit MySQL auskommen muss, steht als serverseitige Technologie PHP zur Verfügung. Dabei habe ich mit eines gefragt. Wenn ich mit PHP objektorientiert programmiere, d.h. unter Einhaltung von MVC mit Design Pattern, ist es dann nicht eine enorme Ressourcenanforderungen an den Server, wenn er bei jedem neuen Besucher alles neu interpretieren muss? Oder passieren im Hintergrund ähnliche Instanzierungsprozesse wie bei Java? Ich weiß, dass PHP zwar im Prinzip interpretiert wird, aber vielleicht kennst sich jemand mit der Materie besser aus?
Bei Java mit Tomcat würde ja schließlich nur eine Instanz erzeugt werden, die immer wieder verwendet wird.
Von den Kosten her würde sich ein Rootserver derweil nicht rechnen. Allerdings wäre man dann zumindest nicht mehr auf MySQL angewiesen, aber das steht wieder auf einem anderen Blatt.

Markus

[dedlfix]

echo $begrüßung;

Wenn ich mit PHP objektorientiert programmiere, d.h. unter Einhaltung von MVC mit Design Pattern, ist es dann nicht eine enorme Ressourcenanforderungen an den Server, wenn er bei jedem neuen Besucher alles neu interpretieren muss?

Das kommt auf den Umfang des Codes an, nicht auf seine Art.

Oder passieren im Hintergrund ähnliche Instanzierungsprozesse wie bei Java?

Nein. Außerdem kommt es darauf an, ob PHP als Apache-Modul oder als CGI-Programm eingebunden wird. Beides hat Eigenschaften, die aus der einen oder anderen Perspektive (z.B. Geschwindigkeit, Sicherheit) als Vor- oder Nachteil angesehen werden können.

Bei Java mit Tomcat würde ja schließlich nur eine Instanz erzeugt werden, die immer wieder verwendet wird.

Gibt es bei PHP nicht (im normalen Lieferumfang). Es gibt aber diverse Opcode-Cache-Systeme, die den PHP-Code vorkompiliert vorhalten.

echo "$verabschiedung $name";

[*Markus]

Hallo,

danke für deine Antwort.
Naja, wie es scheint kann man bei einem Webspace-Provider wahrscheinlich nicht viel PHP-bezüglich konfigurieren. Aber ich werde mich mal erkundigen, wie PHP dort installiert ist.

Markus

[Sven Rautenberg]

Moin!

Abgesehen davon, dass ich mit MySQL auskommen muss, steht als serverseitige Technologie PHP zur Verfügung. Dabei habe ich mit eines gefragt. Wenn ich mit PHP objektorientiert programmiere, d.h. unter Einhaltung von MVC mit Design Pattern, ist es dann nicht eine enorme Ressourcenanforderungen an den Server, wenn er bei jedem neuen Besucher alles neu interpretieren muss?

Das muss er sowieso, egal ob du nun objektorientiert oder prozedural programmierst. Die jeweilige Menge an Quelltext muss geparst werden, entsprechende Datenstrukturen entstehen dann während des Programmablaufs, externe Ressourcen abzufragen (DB etc.) verbraucht ebenso Zeit, und am Ende wird das Resultat in den Ausgabepuffer des Webservers geschrieben und das Skript wieder restlos entfernt. Nächster Aufruf - wieder das Gleiche.

Oder passieren im Hintergrund ähnliche Instanzierungsprozesse wie bei Java? Ich weiß, dass PHP zwar im Prinzip interpretiert wird, aber vielleicht kennst sich jemand mit der Materie besser aus?

Auch Java wird im Prinzip "interpretiert", allerdings auf einer etwas anderen Ebene: Der vom Java-Compiler generierte Bytecode wird nämlich nochmal interpretiert bzw. uminterpretiert in plattformabhängigen Code, und je nach Bedarf, den die JVM feststellt, auch noch optimiert. Deswegen hat es so deutliche Vorteile, wenn Java auf dem Server eingesetzt wird (im Vergleich zum Einsatz beim Client als Applet), weil die kompilierten und optimierten Programme im Speicher bleiben (bzw. in diesem Zustand auf Festplatte ausgelagert würden), bis der Server mal neu gestartet wird.

PHP hat diesen Laufzeitvorteil des Skriptstarts nicht (es gibt Opcode-Caches, die dafür sorgen, dass ein Skript schneller startet), aber auch Java arbeitet erstmal jeden Request einzeln ab, der erstmal unabhängig von allen anderen Requests vorher, nachher und parallel zu bearbeiten ist. Wenn man mit Java Persistenz haben will, braucht man auch dort zusätzliche Hilfe, beispielsweise durch das Hibernate-Framework.

Ich möchte nicht ausschließen, dass es durchaus möglich ist, auch mit PHP etwas zu programmieren, was Persistenz realisiert. Schließlich sind ja entsprechende Funktionen z.B. für den Zugriff auf Shared Memory und Semaphoren vorhanden bzw. können eingebunden werden. Allerdings würde ich zunächst mal davon abraten, so etwas pauschal in das Projekt zu integrieren, denn es verkompliziert einerseits die Sache extrem, erzeugt bei falscher Nutzung einen Sack voller Probleme inklusive möglicher Sicherheitslücken, und löst andererseits nicht jedes Performanceproblem.

Mein alter Spruch zu dem Thema: Performanceprobleme sollte man lösen, wenn man sie hat - nicht vorher.

Von den Kosten her würde sich ein Rootserver derweil nicht rechnen. Allerdings wäre man dann zumindest nicht mehr auf MySQL angewiesen, aber das steht wieder auf einem anderen Blatt.

MySQL ist nicht so böse, wie gerne behauptet wird, allerdings könnte dieser Einwand für dich natürlich die Initiative sein, schon direkt einen DB-Abstraktionslayer zu benutzen.

- Sven Rautenberg

[dedlfix]

echo $begrüßung;

Von den Kosten her würde sich ein Rootserver derweil nicht rechnen. Allerdings wäre man dann zumindest nicht mehr auf MySQL angewiesen, aber das steht wieder auf einem anderen Blatt.
MySQL ist nicht so böse, wie gerne behauptet wird, allerdings könnte dieser Einwand für dich natürlich die Initiative sein, schon direkt einen DB-Abstraktionslayer zu benutzen.

Von solch einem Abstraktionslayer sollte man nicht nur die Vorteile betrachten sondern auch die Nachteile. Um portabel zu bleiben, reicht es nicht, einen DB-Abstraktions-Layer einzuschieben und beim Wechsel nur den Connectionstring anzupassen. Man muss auch auf sämtliche proprietären Features eines DBMS verzichten. Denn sonst ist es aus mit der Portabilität. Das bedeutet, dass man nur grundlegende Funktionalität und Syntax nutzen kann, die jedes (zumindest jedes, das als Wechselkandidat in Frage kommt) DBMS beherrscht.

Aus Ausweg kann man eine Daten-Abstrakttionsschicht verwenden, die zur Anwendung hin eine definierte Schnittstelle bereitstellt und zum DBMS hin beliebig gestaltet sein kann. Wechselt man das DBMS muss man diese Schicht anpassen. Testen, dass mit dem neuen DBMS alles funktioniert, muss man sowieso.

echo "$verabschiedung $name";

[*Markus]

Hallo,

danke für die Information.

MySQL ist nicht so böse, wie gerne behauptet wird, allerdings könnte dieser Einwand für dich natürlich die Initiative sein, schon direkt einen DB-Abstraktionslayer zu benutzen.

Das habe ich sowieso vor. Ehrlich gesagt könnte ich mir ein anderes Design auch schwer vorstellen. Wenn ich oft sehe, dass Logik von Datenbankabfragen direkt beeinflusst wird, läuft's mir eiskalt über den Rücken.

Markus