3-Tier Anwendungen

[Rainer L.]

Wann sollte man sich für 3 oder 4 Tier Anwendungen entscheiden?

Die meisten Programme die wir entwickelt haben, waren einfache Client-Server Anwendungen in Java oder C++. Wann sollte man sich für 3 oder sogar 4 Tier Anwendungen entscheiden? Gibt es dafür eine Art Checklist?

Unser Problem ist, dass wir eine große Anwendung in der Firma haben, die in PHP geschrieben ist. Da die Anwendung sehr schön Programmiert wurde, entsteht leider ein großer Overhead, da PHP sämtliche gewrappten Funktionen und Klassen nicht wegoptimieren kann(die Performance bei nur 30 Usern wird bedenklich).

Da diese Anwendung zu groß ist, um sie komplett neu zu schreiben haben wir uns überlegt, die weiteren Module in Java zu schreiben. Das Frontend wird weiterhin von PHP erzeugt, indem das PHP Skript auf Java Webservices auf dem selben Server zu greift. Da ich diese Lösung mehr als "unschön" finde, würde ich gerne von euch Vorschläge hören wie ihr das Problem lösen würdet.

Vielen Dank im voraus!

[Shade Of Mine]

Rainer L. schrieb:

Unser Problem ist, dass wir eine große Anwendung in der Firma haben, die in PHP geschrieben ist. Da die Anwendung sehr schön Programmiert wurde, entsteht leider ein großer Overhead, da PHP sämtliche gewrappten Funktionen und Klassen nicht wegoptimieren kann(die Performance bei nur 30 Usern wird bedenklich).

Dann ist sie nicht schoen programmiert.
Installiert mal mmcache oder apc

aber 30 user gleichzeitig ist nichts, da muss die anwendung wohl mal ordentlich ueberarbeitet werden...

Da diese Anwendung zu groß ist, um sie komplett neu zu schreiben haben wir uns überlegt, die weiteren Module in Java zu schreiben.

Inwieweit wuerde das etwas bringen? die anwendung ist ja _jetzt_ lahm und nicht erst durch etwaige erweiterungen.

Das Frontend wird weiterhin von PHP erzeugt, indem das PHP Skript auf Java Webservices auf dem selben Server zu greift. Da ich diese Lösung mehr als "unschön" finde, würde ich gerne von euch Vorschläge hören wie ihr das Problem lösen würdet.

Vorallem langsam. Aber PHP und Java koennen auch gemeinsam: http://de.php.net/java

[Rainer L.]

Hallo und Danke "Shade Of Mine"

Shade Of Mine schrieb:

Rainer L. schrieb:

Unser Problem ist, dass wir eine große Anwendung in der Firma haben, die in PHP geschrieben ist. Da die Anwendung sehr schön Programmiert wurde, entsteht leider ein großer Overhead, da PHP sämtliche gewrappten Funktionen und Klassen nicht wegoptimieren kann(die Performance bei nur 30 Usern wird bedenklich).

Dann ist sie nicht schoen programmiert.
Installiert mal mmcache oder apc

aber 30 user gleichzeitig ist nichts, da muss die anwendung wohl mal ordentlich ueberarbeitet werden...

Ja, wir haben uns schon für mmcache entschieden. Allerdings sehen wir das Problem darin, dass auf Dauer ca. 70 User damit gleichzeitig arbeiten und wahrscheinlich auch dann der mmcache einfach nicht mehr ausreichend sein wird.

Shade Of Mine schrieb:

Da diese Anwendung zu groß ist, um sie komplett neu zu schreiben haben wir uns überlegt, die weiteren Module in Java zu schreiben.

Inwieweit wuerde das etwas bringen? die anwendung ist ja _jetzt_ lahm und nicht erst durch etwaige erweiterungen.

Siehe oben. Durch die neuen Module wird es nicht besser. Ein bischen Performance können wir noch mittels mmcache rausholen.

Shade Of Mine schrieb:

Das Frontend wird weiterhin von PHP erzeugt, indem das PHP Skript auf Java Webservices auf dem selben Server zu greift. Da ich diese Lösung mehr als "unschön" finde, würde ich gerne von euch Vorschläge hören wie ihr das Problem lösen würdet.

Vorallem langsam. Aber PHP und Java koennen auch gemeinsam: http://de.php.net/java

Vielleicht liegt das auch daran, dass bei uns in der EDV noch niemand etwas mit PHP gemacht hat und deshalb die Vorurteile kommen.

Hast Du Erfahrung mit PHP und großen Anwendungen, die keine klassischen Websites ausliefern. Also sprich richtige Anwendungen wie Warenwirtschaft und co. auf PHP Basis?

Was würdest Du machen? Lieber den ganzen Code überarbeiten oder auch langsam auf ein neues Pferd satteln?

[Shade Of Mine]

Rainer L. schrieb:

Ja, wir haben uns schon für mmcache entschieden. Allerdings sehen wir das Problem darin, dass auf Dauer ca. 70 User damit gleichzeitig arbeiten und wahrscheinlich auch dann der mmcache einfach nicht mehr ausreichend sein wird.

mmcache ist halt nur ein optimierer, aber unendlich viel kann er nicht optimieren... das problem ist, dass die anwendung lahm ist (wieviel muss sie denn machen?)

Siehe oben. Durch die neuen Module wird es nicht besser. Ein bischen Performance können wir noch mittels mmcache rausholen.

ihr koenntet die php-java-bridge verwenden oder die lahmsten stellen in C schreiben (PHP laesst sich mit extensions ja super erweitern)

Vielleicht liegt das auch daran, dass bei uns in der EDV noch niemand etwas mit PHP gemacht hat und deshalb die Vorurteile kommen.

PHP scaled, dass ist tatsache. schau dir zB dieses forum hier an. laeuft mit PHP ohne probleme (die probleme sind die schlechte DB implementierung vom phpBB) ich habe aber auch schon groessere seiten mit php gemacht als dieses forum hier. also php scaled

natuerlich kann man dennoch langsamen code in php schreiben, keine frage. ist sogar relativ leicht, weil php eben doch nicht so einfach ist wie es aussieht.

Was würdest Du machen? Lieber den ganzen Code überarbeiten oder auch langsam auf ein neues Pferd satteln?

Wenn es zuviel code ist, wird ueberarbeiten und umsatteln nicht gut gehen (ohne enormen aufwand - und den will man ja vermeiden).
ich wuerde mir mal anschauen ob man die hotspots optimieren kann (uU sind ja nur die DB queries so lahm, oder es wird auf zuviele shared resourcen zugegriffen, etc. apd hilft hier beim profilen). uU kann man langsame funktionen in C schreiben und als extension einbinden.

dann wuerde ich mir mal die php-java-bridge ansehen (habe selber aber noch nicht damit gearbeitet) um php und java enger zusammenzubringen und so die kosten fuer die kommunikation niedrig zu halten.

bessere hardware bringt uU auch etwas, haengt aber davon ab wo der flaschenhals ist - also mal extensiv profilen.

vielleicht kann man ja auch an ein paar wesentlichen stellen caches einbauen. eine idee waere auch noch die php seiten ausgabe selber zu cachen und nur alle 2-3 minuten neu zu generieren (haengt davon ab, wie aktuell die daten sein muessen).

wenn die PHP anwendung stark OO ist, dann lohnt sich ein update auf php5 uU auch - da hat sich das object model von php ordentlich verbessert.

[Rainer L.]

Shade Of Mine schrieb:

Rainer L. schrieb:

Ja, wir haben uns schon für mmcache entschieden. Allerdings sehen wir das Problem darin, dass auf Dauer ca. 70 User damit gleichzeitig arbeiten und wahrscheinlich auch dann der mmcache einfach nicht mehr ausreichend sein wird.

mmcache ist halt nur ein optimierer, aber unendlich viel kann er nicht optimieren... das problem ist, dass die anwendung lahm ist (wieviel muss sie denn machen?)

Bisher beinhaltet sie Stammdatenerfassung, Projektabwicklung und Ressourcenmangement. Jetzt soll noch die Warenwirtschaft kommen. Das Problem ist, dass die Entwickler alles objektorientiert gelöst haben und jede Menge Queries an die DB schicken.

Shade Of Mine schrieb:

Was würdest Du machen? Lieber den ganzen Code überarbeiten oder auch langsam auf ein neues Pferd satteln?

Wenn es zuviel code ist, wird ueberarbeiten und umsatteln nicht gut gehen (ohne enormen aufwand - und den will man ja vermeiden).
ich wuerde mir mal anschauen ob man die hotspots optimieren kann (uU sind ja nur die DB queries so lahm, oder es wird auf zuviele shared resourcen zugegriffen, etc. apd hilft hier beim profilen). uU kann man langsame funktionen in C schreiben und als extension einbinden.

dann wuerde ich mir mal die php-java-bridge ansehen (habe selber aber noch nicht damit gearbeitet) um php und java enger zusammenzubringen und so die kosten fuer die kommunikation niedrig zu halten.

wenn die PHP anwendung stark OO ist, dann lohnt sich ein update auf php5 uU auch - da hat sich das object model von php ordentlich verbessert.

Das mit den C-Extensions hört sich gut an, nur leider ist der Flaschenhals die enorme Menge an Queries die ausgeführt werden müssen.

PHP5 werde ich mir anschauen. Benötigt man dafür einen extra Optimizer? Bei den anderen steht PHP3/PHP4?

Gibt es eigentlich eine schöne Möglichkeit PHP mit C++ zu koppeln? Das ich sozusagen das Backend des Warenmanagement in C++ schreibe und nur die Auswertung, Aufbereitung in PHP mache?

Wenn ich dich richtig verstanden habe, kann man auch mit PHP+Cache schnellen Code schreiben?

Auf jeden Fall schon mal besten Dank an dich!

[Power Off]

Moeglicherweise hilft es, die Datenbankzugriffe zu vereinfachen. Also keine seitenlangen SQL-Statements. Man kann auch mit Einzeilern auskommen. Dafuer ist es allerdings erforderlich, dass die Datenbanken gut organisiert sind, und dass es somit leicht ist, sie abzufragen.

Es kann auch helfen, alle Operationen als Stored Procedures im Datenbank-Server abzulegen, und dann nur noch die Stored Procedures aufzurufen.

Vielleicht ist es dafuer schon zu spaet, aber ggf. kann man statt Scriptsprachen wie PHP ein Webserver-Plugin schreiben (z.B. ISAPI fuer IIS oder Apache Modul), das in C oder C++ geschrieben ist.

Die Performance von PHP laesst sich uebrigens dramatisch steigern, wenn PHP als ISAPI-Modul oder Apache-Modul in den Webserver eingebunden ist. Wenn der Webserver PHP jedes mal als externes Programm startet, geht viel Zeit verloren.

Ein weiterer Performance-Killer sind oft die Webserver selbst, da sie meistens mit synchronen TCP/IP Zugriffen arbeiten (d.h. ein Thread muss auf die Abarbeitung warten).

Meiner Erfahrung nach bringen 3- oder 4-Tier Anwendungen in Java kaum was, da Java ohnehin schon relativ langsam ist.

Fuer eine ordentliche Loesung, die auf EJB basiert, muss man sich unbedingt an die EJB-Vorgaben halten (also z.B. Entity-Beans nehmen, um Datenbankzugriffe zu kapseln), damit die EJB-Server die Leistung optimieren koennen. Das lohnt sich aber nur, wenn die Server entsprechend dimensioniert sind. Das gilt auch fuer den Datenbank-Server.

Der Entwicklungsaufwand fuer eine 3- oder 4-Tier-Loesung mit EJB bedeutet wahrscheinlich eine komplette Neuentwicklung der Anwendung. Und ob die Performance hinterher besser ist, haengt von vielen Faktoren ab (korrekte Einrichtung und Konfiguration der Server etc.).

Daher lohnt es sich unter Umstaenden, zuerst nach Alternativen zu suchen (siehe oben).

[Unix-Tom]

Ihr sollte bei der Datenbank ansetzen. Dort liegt der Flaschenhals und nicht bei PHP.

Wenn jede Anfrage 0,5 Sekunden dauert und es sind 20 Anfragen pro Seite dann sind das 10 Sekunden Wartezeit. Das kann man nicht auf PHP schieben. Es kommt auch darauf an welche Datenbvank und welche SChnittstelle zur DB. ODB ist sehr langsam. Verwendet man MySQL und PHP kann man an der Schnitstelle nicht mehr verbessern da PHP bereits die C-API von MySQL selbst verwendet.
Dann wird es das Datenbankdesign sein.
Genauso wie Shade schon sagte: PHP schaut einfach aus ist es aber nicht wenn es um Designfehler geht. Genauso verhält es sich mit Datenbanken und 2 DIM Tabellen. Das kann jeder aber wenn es um Tempo geht braucht es schon mehr.

[Rainer L.]

Danke an euch!

Meine Meinung zu PHP habe ich schon geändert. Projekte wie eAccelerator schauen schon recht vielversprechend aus.

Das DB Design ist ansich nicht schlecht. es läuft auf einer MySQL DB mit MyISAM Tabellen. Das Problem ist die Anzahl der Queries. Es werden die Rechte des Anwenders überprüft, die Anwendungdaten geladen, es muss überprüft werden ob ein Mitarbeiter der Abteilung A das Projekt B sehen darf, darf der Benutzer Einstellungen zu dem Projekt D vornehmen und und und. Also das Problem ist leider die komplexität der Anwendung. Die Anwendung + eAccelerator hat schon erhebliches gebracht. Der Rest lässt sich wohl kaum mehr vermeiden.

Hat jemand Erfahrungen ob man mit PHP MVC Anwendungen schreiben sollte oder ist das ein Performancekiller? Das Problem ist halt, dass man die Skripte durch strikte Trennung von UI-PHP, Controlling-PHP und DB-PHP schon einiges an Übersichtlichkeit erreichen kann. UI-PHP gibt z. B. die Daten an die Template-Engine weiter, Controlling-PHP, überprüft die Rechte und DB-PHP schreibt die Daten in die Datenbank.

[Power Off]

Vielleicht kann man ja die Datenbankabfragen buendeln, also statt vielen Abfragen nur eine oder wenige. Man macht einfach eine Tabelle, in der alle benoetigten Daten stehen, und die entweder ueber einen Prozess auf dem Datenbankserver oder durch relationale Beziehungen auf dem laufenden gehalten wird. Dann muss fuer jeden Benutzer nur ein Datensatz geholt werden.

MVC (3-Tier) Anwendungen sind von der Idee her auf jeden Fall gut, da sie die Lesbarkeit und Wartbarkeit des Codes erhoehen. Jedoch bringt es wenig, wenn Skript A auf Skript B, und Skript B auf Skript C wartet.

Die groesste Performancesteigerung ist unter Umstaenden durch eine Job-Basierte Loesung zu erreichen: Der Client schickt eine UI-Anfrage an den Server A. Der prueft, ob es schon vorhandene Daten gibt, die er verwenden kann, und schickt diese ggf. gleich zum Client. Server A prueft selbsttaetig im Hintergrund, wie er UI-Anfragen besser beantworten kann, und schickt zu diesem Zweck Controlling-Anfragen an Server B. Server B beantwortet diese mit Daten, die ihm bereits zur Verfuegung stehen, und versucht seinerseits, seine Daten mittels dem Datenbankserver C aktuell zu halten. Der Datenbankserver arbeitet die Liste seiner Anfrage, soweit moeglich, ebenfalls im Hintergrund ab und versucht seine Daten zu optimieren.

Soweit die Theorie ... !

Man koennte dies mit Hilfe dreier Webserver (ggf. auf derselben Maschine mit unterschiedlichen Portnummern) und PHP realisieren. Auf den Servern A und B wuerde man nur mit Textdateien arbeiten, da eine Datei zu lesen schneller geht als ein Datenbankzugriff. Auf Server C wuerde mit Dateien und Datenbankzugriffen gearbeitet. Die im Hintergrund laufenden Dienste koennte man beim Serverstart hochfahren und auch in PHP schreiben (laesst sich auch von der Kommandozeile aus benutzen).

Nur so (also durch asynchrone Verfahren) wuerde sich ein MVC-Architektur wirklich lohnen. Nach aehnlichem Prinzip arbeiten auch EJB-Systeme, bei denen die 3-Tier Architektur durch getrennte Dienste realisiert wird. Die von mir vorgeschlagene Loesung mittels PHP waere allerdings moeglicherweise wesentlich schneller!

[Shade Of Mine]

Rainer L. schrieb:

Also das Problem ist leider die komplexität der Anwendung.

Dann setz einmal gute caching strategien ein.
bei vielen queries bringt es sich manchmal folgendes zu machen:
eine cache tabelle die sich merkt, dass man für seite A die werte C, D und E braucht und für seite B die werte C, D und F.

jetzt kannst du am anfang mit nur einem query die meisten notwendigen werte auslesen und hast nur selten cache misses, weil die sachen dynamisch geupdatet werden.

sowas läuft recht gut.

andere caching strategien sidn natürlich auch sinnvoll. caching ist so ziemlich das effektivste was man im web machen kann.

Hat jemand Erfahrungen ob man mit PHP MVC Anwendungen schreiben sollte oder ist das ein Performancekiller?

wirklich komplettes framework ist zB mojavi
aber idr ist sowas unnötig und natürlich kostet es performance. ein doc/view reicht und das lässt sich mit hilfe von smarty recht leicht erreichen.