Performance Java Application Server

[/dev/NULL]

Hintergrund soll ein Browsergame werden was als Techdemo als Java/JSP entstehen wird.
Vorteile von nem App-Server wären ja vorhandenes Benutzermanagement und ggf möglichkeiten der Skalierung. Wie schaut das Performancemäßig aus? Deutlich langsamer als PHP? Wie tuned man sowas? Bei PHP gibt es ja mit eAccelerator, XCache und wie sie alle heissen zumindest bytecode caches. Wie sieht sowas bei Java aus?

[Shink]

Es gibt sicher Java-Server, die wesentlich leistungsfähiger sind als PHP; Dinge wie Bytecode-Caches und Threadpools bekommt man AFAIK bei allen aktuell verfügbaren Implementierungen.
Die Server (z.B. Tomcat) lassen sich mit diversen Parametern auf die zu erwartende Last optimieren.
Dass eine Java-Lösung deutlich langsamer ist als eine PHP-Lösung kann ich mir beim besten Willen nicht vorstellen - Tests sind mir hierzu aber leider nicht bekannt.

[SavageX]

Ich würde annehmen, dass Java gerade unter Lastbedingungen sehr gut dasteht (robustes Threading, gute Server-Runtime). Kann mich Shink nur anschließen: Glaube nicht, dass Java langsamer ist als eine PHP-Umgebung.

[Hamud]

Java ist an einigen Stellen mittlerweile schneller als C++. Also wegen der Performance brauchst du keine Angst zu haben.

[The_Invisible]

Java ist an einigen Stellen mittlerweile schneller als C++. Also wegen der Performance brauchst du keine Angst zu haben.

und wo/wie bitte schön?

alle benchmarks die ich kenne zeigen eigentlich nur hohen bis sehr hohen vorteil für c/c++

mfg

[Köppchen]

Bei Java Applicationservern läuft der Server als eigener Prozess. In dem sorgt der JIT Compiler des Java dafür das oft durchgeführter Code in nativen Code der Platform übersetzt wird.
Performanceprobleme gibt's erfahrungsgemäß eher durch schlechten Programmcode. Z.b wenn man keine prepared Statements für den DB zugriff verwendet.

Gruß Markus

[Der_Donnervogel]

und wo/wie bitte schön?

alle benchmarks die ich kenne zeigen eigentlich nur hohen bis sehr hohen vorteil für c/c++

mfg
Wenn man will findet man zu allem die richtigen Benchmarks, z.B. Java ist schneller als C++ (http://kano.net/javabench/). Im Prinzip aber unerheblich, Java hat andere Vorteile als Geschwindigkeit, die es gegenüber von C++ attraktiv macht.

[Endorphine]

Die Frage ist doch viel eher, wie viel Kosten (Hardware-Aufwand) erzeugt werden für die selbe Performance. Und da ist Java wohl bei kleinen und mittleren Anwendungen bei weitem teurer als PHP.

Gibt es denn auch billige shared Webserver mit Tomcat? Sonst stehen die Kosten eines Rootservers denen eines virtuellen Servers gegenüber.

[Shink]

Die Frage ist doch viel eher, wie viel Kosten (Hardware-Aufwand) erzeugt werden für die selbe Performance. Und da ist Java wohl bei kleinen und mittleren Anwendungen bei weitem teurer als PHP.

Gibt es denn auch billige shared Webserver mit Tomcat? Sonst stehen die Kosten eines Rootservers denen eines virtuellen Servers gegenüber.
Hmm... also dass DAS die Frage dieses Threads ist, kann ich irgendwie nirgends rauslesen...

[Endorphine]

Hmm... also dass DAS die Frage dieses Threads ist, kann ich irgendwie nirgends rauslesen... Das ist nicht die Frage. Aber es ist das einzig Relevante.

Es ist nämlich völlig irrelevant, wie gut oder schlecht irgendein Dienst auf Basis irgendeiner Sprache performed. Was zählt sind die Kosten, die vergleichbares Performance-Niveau erzeugen. Und wenn eine Plattform eben einen Rootserver für sich in Beschlag und sich mit sich selbst beschäftigt ohne auch nur einen Client zu bedienen sind die Kosten nunmal höher, als wenn man eine Skriptsprache verwendet, die nur Rechenzeit bei Anfragen an den Server verbraucht und dann auch recht linear nach oben skaliert pro Request. Und diese Skriptsprache auf jedem einfachen shared-Webserver von der Stange läuft und man mit 10 EUR pro Monat einen ganzen Haufen Clients parallel bedienen kann, statt 150+ EUR für einen größeren Rootserver auszugeben.

Es ist so wie mit der Taktfrequenz von CPUs: eine für den Kunden völlig irrelevante Größe. Relevant sind Rechenleistung und elektrische Leistungsaufnahme und Nebenkosten.

Genau so irrelevant und nur von akademischer Bedeutung ist irgendeine synthetische Performance-Angabe. Praxis zählt, keine Gedankenspielchen.

[SavageX]

Und wenn eine Plattform eben einen Rootserver für sich in Beschlag und sich mit sich selbst beschäftigt ohne auch nur einen Client zu bedienen sind die Kosten nunmal höher, als wenn man eine Skriptsprache verwendet, die nur Rechenzeit bei Anfragen an den Server verbraucht und dann auch recht linear nach oben skaliert pro Request.


Das hat nichts mit Skriptsprache versus Java zu tun, sondern mit dem, was Du da überhaupt treibst. Wenn Du im Hintergrund z.B. eine Spielewelt hast, die sich updaten soll, auch wenn kein Client bedient wird, dann muss halt zwangläufig dauernd etwas laufen, das dies tut, ganz gleich ob PHP oder Java oder Ruby oder Perl oder...

Wenn das Dingen nur aktiv sein braucht, wenn eine Anfrage gestellt wird, dann kann man das auch wieder mit allen möglichen Plattformen realisieren (und natürlich auch in Java).

Selbstverständlich ist eine normale PHP-Umgebung praktisch bei jedem Webhosting Paket dabei (und Java nicht unbedingt) - aber in diesem Anwendungsfall (Webbrowser-Game) brauchst Du sowieso einen dezidierten Server (oder eine "fast so gute" virtualisierte Umgebung), einfach weil Du die Spielewelt am ticken halten musst.

[Endorphine]

Stimmt so nicht. Ich hab mal ein Browser-Multiplayerspiel gespielt, in welchem der (einzige) Entwickler selbst bestätigt hat, dass das Spiel nur dann "läuft", wenn jemand das Skript anstösst. Nichts mit laufendem Prozess. Ein reines Skript.

Reicht ja auch völlig aus, immer den aktuellen Zustand zu berechnen. Wozu muss ein Browsergame auch im Hintergrund rödeln, wenn niemand sich für die Zwischenzustände interessiert.

Zudem: Spiele sind Spiele. Freizeit-Unterhaltung. Nichts, was wirklich die Welt am laufen hält, irgendjemandem Brot auf den Tisch bringt oder ein Dach über den Kopf.

[Shink]

Zudem: Spiele sind Spiele. Freizeit-Unterhaltung. Nichts, was wirklich die Welt am laufen hält, irgendjemandem Brot auf den Tisch bringt oder ein Dach über den Kopf.
... und im Gegensatz dazu sind alle wirklich wichtigen Anwendungen stateless oder was genau willst du jetzt aussagen?

[Ok, jetzt verkneif ich mir mal anzumerken dass bei manchen das Brot und das Dach durch Spieleentwicklung bezahlt wird]

Übrigens lässt mich die Sig des Threadstellers vermuten, dass er kein Problem damit haben sollte, einen passenden Server zu finden.
Aber wir sind ohnehin schon OT.

[/dev/NULL]

irgendjemandem Brot auf den Tisch bringt oder ein Dach über den Kopf.

Das stimmt nur bedingt.

Und nen Browsergame auf nem shared Hosting Account ist schon relativ anmassend, bei den meisten ISPs ist der Datenbankserver dann die Schwachstelle.. aber darum geht es nicht, nen eigenen Server hinstellen und nen Tomcat/JBoss zu installieren wäre nicht das Problem.

Ob die Spielwelt dauerhaft läuft oder nur zu bestimmten Zeitpunkten Auswertungen macht, oder auf jede Usereingabe reagiert ist natürlich Spiel(prinzip)abhängig.

[SimonX]

Java ist an einigen Stellen mittlerweile schneller als C++. Also wegen der Performance brauchst du keine Angst zu haben.
Das Problem von Java ist das Extrem-Object-Trashing. Aber im Vergleich zu PHP ist es sicher schneller.

[SimonX]

Die Frage ist doch viel eher, wie viel Kosten (Hardware-Aufwand) erzeugt werden für die selbe Performance. Und da ist Java wohl bei kleinen und mittleren Anwendungen bei weitem teurer als PHP.

Java wird mit Sicherheit deutlich mehr Speicher (Memory) benötigen als PHP. Aber ob das wirklich zählt bezweifel ich.

Das Java bei kleinen/mittleren Anwendungen teurer als PHP ist bezweifel ich auch. Aber das kann man nur an der jeweiligen Anwendung festmachen. Die erste Hürde ist die PHP App nach Java zu portieren. Dazu muss man Java aber kennen. Ob sich der Aufwand lohnt stellt sich erst dann heraus.

[Endorphine]

Java wird mit Sicherheit deutlich mehr Speicher (Memory) benötigen als PHP. Aber ob das wirklich zählt bezweifel ich.

Das Java bei kleinen/mittleren Anwendungen teurer als PHP ist bezweifel ich auch. Ich stelle gerne die Frage noch einmal: die Kosten zählen letzen Endes -- gibt es auch kleine shared Webserver-Hostingangebote mit Tomcat? Ich kenne da jetzt ausm Stegreif keins. Mein Wissensstand ist, dass man für Java-Webserver einen Rootserver benötigt. Und das ist deutlich teurer als ein kleiner virtueller Webserver mit PHP/Perl usw.

Auch wenn das Produkt nur in einem Intranet läuft: auf dem Server laufen viel mehr PHP-Dienste als welche in J2SE/J2EE, einfach schon deshalb weil wie du schon erwähnt hast der Speicherverbrauch ein ganz anderer ist. Umgerechnet ist Java auch dort für kleine/mittlere Projekte deswegen teurer bei gleicher Leistungsfähigkeit der Applikation. Es können eben nicht so viele Dienste auf dem selben Rechner laufen wie z. B. mit PHP.

Daher würde ich für kleine und mittlere Projekte aus Kostengründen kein Java verwenden.

[HellHorse]

Ich stelle gerne die Frage noch einmal: die Kosten zählen letzen Endes -- gibt es auch kleine shared Webserver-Hostingangebote mit Tomcat? Ich kenne da jetzt ausm Stegreif keins. Mein Wissensstand ist, dass man für Java-Webserver einen Rootserver benötigt. Und das ist deutlich teurer als ein kleiner virtueller Webserver mit PHP/Perl usw.
http://www.google.ch/search?q=java+web+hosting
Das Problem von Java ist das Extrem-Object-Trashing. Aber im Vergleich zu PHP ist es sicher schneller.
[ ]du weisst du ein Copy Garbage Collector arbeitet.

[Endorphine]

http://www.google.ch/search?q=java+web+hosting Danke, ich kenne Google. Wie sieht es preislich im Durchschnitt im Vergleich zu gewöhnlichen PHP-Angeboten aus?

[HellHorse]

Danke, ich kenne Google.
Den Eindruck hatte ich irgendwie nicht so.
Wie sieht es preislich im Durchschnitt im Vergleich zu gewöhnlichen PHP-Angeboten aus?
'tschudigung wie bitte?! Zuerst in einem Thread über Java Application Server Performance irgendwelche abstrusen Behauptungen über die angebliche Situation bzgl. low-end Hosting Angeboten in die Welt setzten und jetzt das?

[SimonX]

[url]
[ ]du weisst du ein Copy Garbage Collector arbeitet.

Nur das der halt zur Zeit nicht nicht so toll ist. Wir sehen das in der Firma wie gut der Garbage Collector bei mittelmässiger Java-Programmierung generell ist. Object-Trashing ist immer teurer als Object-Reusing. Object-Reusing ist aber überhaupt nicht der Programmier-Style der von einem 0815 Java-Programmierer umgesetzt (oder verstanden) werden kann.

Zum Glück ist bald Memory-Management in den Java-Standard integriert.

[Endorphine]

Den Eindruck hatte ich irgendwie nicht so. Das tut mir leid. Für die Zukunft darfst du gern davon ausgehen, dass mir der Dienst "Google Websuche" geläufig ist. :) 'tschudigung wie bitte?! OK, für dich noch einmal: Wie sieht es preislich im Durchschnitt im Vergleich zu gewöhnlichen PHP-Angeboten aus? Zuerst [...] irgendwelche abstrusen Behauptungen [...] Dir steht es überhaupt nicht zu, zu bewerten, was eine "abstruse Behauptung" ist. Zuerst in einem Thread über Java Application Server Performance irgendwelche abstrusen Behauptungen über die angebliche Situation bzgl. low-end Hosting Angeboten in die Welt setzten und jetzt das? Ich habe mehrfach geschrieben, dass mein Kenntnisstand ist, dass man im Regelfall für einen Java Application Server kein übliches billiges Allerweltsangebot für wenige Euro nehmen kann wie bei PHP. Es müssen Rootserver oder sonstige teurere Nischenprodukte her.

Du solltest Lesen lernen. :)

[HellHorse]

Nur das der halt zur Zeit nicht nicht so toll ist. Wir sehen das in der Firma wie gut der Garbage Collector bei mittelmässiger Java-Programmierung generell ist. Object-Trashing ist immer teurer als Object-Reusing. Object-Reusing ist aber überhaupt nicht der Programmier-Style der von einem 0815 Java-Programmierer umgesetzt (oder verstanden) werden kann.
Object-Reusing ist so extrem viel teuer als viele kurzlebige Objekte, dass es sogar ein Anti-Pattern ist. Da Object-Reusing die Lebenszeit von Objekten erhöht wandern sie in der Regel in die old-generation. Alte Objekte zu collecten ist exterm viel teurer als junge zu collecten. Bei einem Copy Garbage Collector ist der Aufwand für eine Collection proportional zur Anzahl lebender Objekte. Das heisst du kannst Speicher gegen CPU Aufwand für eine Collection tauschen. Neue Objekte zu erstellen ist praktisch gratis (bloss einen Pointer inkrementieren). Für sehr viele kurzlebige Objekte ist also ein Copy Garbage Collector wie geschaffen.

Bloss weil malloc scheisse ist, muss nicht für Java das Gleiche gelten.

[SimonX]

Object-Reusing ist so extrem viel teuer als viele kurzlebige Objekte, dass es sogar ein Anti-Pattern ist. Da Object-Reusing die Lebenszeit von Objekten erhöht wandern sie in der Regel in die old-generation. Alte Objekte zu collecten ist exterm viel teurer als junge zu collecten. Bei einem Copy Garbage Collector ist der Aufwand für eine Collection proportional zur Anzahl lebender Objekte. Das heisst du kannst Speicher gegen CPU Aufwand für eine Collection tauschen. Neue Objekte zu erstellen ist praktisch gratis (bloss einen Pointer inkrementieren). Für sehr viele kurzlebige Objekte ist also ein Copy Garbage Collector wie geschaffen.

Bloss weil malloc scheisse ist, muss nicht für Java das Gleiche gelten.

Tja, wenn aber Objecte die reused werden erst garnicht vom GC beobachtet werden, dann sind sie sehr viel billiger.

Das wird ja bald im Standard-Java enthalten sein.

Ausserdem sprechen wir hier nicht von dem eigentlichen Memory-Management. Memory-Management ist hier irrelevant. Das Teure hier ist das Initalisieren von Objekt-Hierrachieren. Wenn komplette Hierarchien reused werden fällt das gesammte Initialisieren weg. Natürlich nur wenn man es gut programmiert. Auch kann man beim Object-Reusen komplette Berechnungen cachen oder zu mindest vorbereiten. Das kann dann schnell eine ganze Potenz schneller werden, wenn man seine Hausaufgaben macht. Aber das alles ist nichts für 0815 Javaprogrammierer. Komplexe Invarianten zu finden bzw. das eigentliche Problem so umzuformen, das komplexe Invarianten entstehen ist nicht leicht.

"Für sehr viele kurzlebige Objekte ist also ein Copy Garbage Collector wie geschaffen"
Tja, wir haben da ganz andere Erfahrungen auf echten Hochlastproduktionssystemen gemacht. Von der Theorie sollte es vielleicht so sein. Bei echten, durchschnittlich programmieren, Anwendungen ist das nicht so. Das schlimme sind dann noch die vielen Stellschrauben am GC, die alle zur Anwendungen passen müssen.

[HellHorse]

Tja, wenn aber Objecte die reused werden erst garnicht vom GC beobachtet werden, dann sind sie sehr viel billiger.
BS, der GC muss natürlich rausfinden ob sie live sind oder nicht.