Java als Servertechnologie

Ich möchte mich gerne weiterbilden und bin grad am überlegen ob ich mein BG in Java (Serverseitig) entwickeln soll. Was benötige ich als Betriebssystem, Webserver, Datenbank und dergleichen? Sollte möglichst kostenlos ablaufen. Bzw. ist es sinnvoll Java für Browsergames zu verwenden?

1. Java ist toll um nicht zu sagen göttlich
jegliche kritik an java (in diesem gebiet wohlgemerkt) entsteht aus unwissen

so wenn du diesen schritt getan hast kann ih diesen bg24 post empfehlen:
(weis nicht ob du den schon kennst) www.browsergames24.de/modules.php?name=Forums&file=viewtopic&t=1744
betriebssystem: Java rühmt sich durch plattformunabhängigkeit
webserver: apache->tomcat ist am meisten verbreitet
datenbank: man kann alle möglich datenbanken ansprechen. auch hier ist mysql nicht unüblich aber ich persönlich (subjektive meinung) empfehle es nicht da es für Java die wahre macht des einzig wahren OODBMS db4o gibt, das sich steigender beliebtheit erfreut

Sollte möglichst kostenlos ablaufen. Bzw. ist es sinnvoll Java für Browsergames zu verwenden?

JA! Java ist dort sinnvoll wo php an der komplexität scheitert

ich würde in betracht ziehen, java nicht in form von servlets zu benutzen, sondern das bg als komplett eigenständigen server zu konzipieren. dadurch eröffnen sich dir (meiner meinung nach) eine fülle an zusätzlichen möglichkeiten, oder stellen sich zumindest einfacher dar. unsere momentane entwicklung basiert im übrigen auf genau diesem konzept. dauert zwar wohl noch ein bisschen, aber bis jetzt hatte ich keine nennenswerten probleme...

Java ist toll um nicht zu sagen göttlich

dem stimm ich nicht ganz zu. java ist zwar meine "lieblingssprache", ich arbeite sehr gerne damit, aber hier und da gibt es kleine macken, an denen man sich zurecht stören darf, und die woanders besser gelöst wurden.
mfg atrox

Wie kann ich Java als eigenständigen Server verwenden und wa

Zitat:
Java ist toll um nicht zu sagen göttlich

dem stimm ich nicht ganz zu. java ist zwar meine "lieblingssprache", ich arbeite sehr gerne damit, aber hier und da gibt es kleine macken, an denen man sich zurecht stören darf, und die woanders besser gelöst wurden.
mfg atrox
das wahr ja auch nicht ganz so ernst gemeint
nur im prinzip

ich würde in betracht ziehen, java nicht in form von servlets zu benutzen, sondern das bg als komplett eigenständigen server zu konzipieren. dadurch eröffnen sich dir (meiner meinung) nach eine fülle an zusätzlichen möglichkeiten, oder stellen sich zumindest einfacher dar. unsere momentane entwicklung basiert im übrigen auf genau diesem konzept.

das ist zwar eine möglichkeit aber das sehe ich als wenig sinnvoll an weil die servlet klassen lediglich die requests und reponses abstrahieren dh die arbeit mit dem http protokoll abnehmen und dir zeit für das wesentliche geben
ausserdem sind auch Listener und Filter gute werkzeuge, und um diese ohne servlet umzusetzen ist wieder teuere arbeitszeit

Original von duschendestroyer
das ist zwar eine möglichkeit aber das sehe ich als wenig sinnvoll an weil die servlet klassen lediglich die requests und reponses abstrahieren dh die arbeit mit dem http protokoll abnehmen und dir zeit für das wesentliche geben
ausserdem sind auch Listener und Filter gute werkzeuge, und um diese ohne servlet umzusetzen ist wieder teuere arbeitszeit

vielleicht sollte ich nachtragen, dass dieser server später auf verschiedene weisen erreichbar sein soll. http stellt nur eines der möglichen verbindungsprotokolle dar. so haben wir die möglichkeit, ein und das selbe spiel mit der absolut identischen logik über verschiedene schnittstellen verfügbar zu machen, sei es ganz klassisch über eine html-oberfläche oder über ein client-seitiges java-programm.
mfg atrox

jo genau das selbe habe ich mir auch überlegt
aber bei mir habe ich klassen die die ganze logik übernehmen und dann die servlets die eigentlich nur zwischendrinnen hängen
zb: (Page ist ein child von HttpServlet)

public class Register extends Page {
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
UserFactory userfactory = getUserFactory();
StringTemplate template = getTemplate("register");
if(request.getParameter("register") != null){
String name = request.getParameter("name");
String pass = request.getParameter("pass");
String pass2 = request.getParameter("pass2");
String mail = request.getParameter("mail");
User user = userfactory.create(name, pass, pass2, mail);
if(user != null){
template.setAttribute("registered", true);
template.setAttribute("name", name);
template.setAttribute("mail", mail);
}
else{
template.setAttribute("error", userfactory.getErrorHtml());
}
}
display(template, EXTERN_FRAME, response);
}
}
diese servlets überschreiten eigentlich nie 50 zeilen
wenn man dann neue spielarten wie über einen client nutzen will so kann man einfach andere servlets (es bleiben trotzdem servlets aber halt keine httpServlets) schreiben und fertig is

ok, das konzept ist bei mir auch sehr ähnlich, ich habe ebenfalls die logik in klassen abgekapselt, allerdings muss ich nicht für jede anfrage neue handler implementieren, sondern ich kann einmal global einen handler erstellen, der also den eigentlichen server darstellt, und alle anfragen eines bestimmten protokolls entgegennimmt und bearbeitet.
eine eventuelle verarbeitung von eingabedaten etc. erfolgt deshalb bei mir auch nicht in den handlern, sondern im fall einer html-oberfläche in definitionsdateien, einer mischung aus template und verarbeitung von eingabe-/ausgabedaten.
mfg atrox

Original von AtroX
vielleicht sollte ich nachtragen, dass dieser server später auf verschiedene weisen erreichbar sein soll. http stellt nur eines der möglichen verbindungsprotokolle dar. so haben wir die möglichkeit, ein und das selbe spiel mit der absolut identischen logik über verschiedene schnittstellen verfügbar zu machen, sei es ganz klassisch über eine html-oberfläche oder über ein client-seitiges java-programm.

Und dafür der Aufwand einen völlig eigenständigen Server zu entwickeln und auf die ganzen Annehmlichkeiten der Apache Produkte in dem Umfeld zu verzichten? HTTP ist doch eigentlich nur ein Envelope. Ich spiele auch mit der Idee eventuell später einen Client anzubieten. Aber der wird auch über HTTP kommunizieren, halt über XML-RPC oder SOAP. Oder noch besser über REST, dann sollte die Schnittstelle auch für Nicht-Breitband-Verbindungen nutzbar sein.

Original von Agmemon
Und dafür der Aufwand einen völlig eigenständigen Server zu entwickeln

ich habe ja nicht vor, einen neuen http-server zu entwickeln, in diese richtung gibts es schon genug, unter anderem auch für java

Original von AtroX

Original von Agmemon
Und dafür der Aufwand einen völlig eigenständigen Server zu entwickeln

ich habe ja nicht vor, einen neuen http-server zu entwickeln, in diese richtung gibts es schon genug, unter anderem auch für java
was hast du dann vor?
scheinbar willst du die servlet technik oder ein protokoll neu entwickeln
auch nicht gerade notwendig

Wie steht ihr zu Java Server Faces?

in die tonne damit

ich will nicht für jede mögliche anfrage ein servlet schreiben müssen, sondern die behandlung von einkommenden anfragen soll zentral in einem modul dieses servers passieren. natürlich könnte man auch dies umgehen, indem ich alle anfragen an ein spezielles servlet weiterleite, welches dann über eine factory eine instanz der passenden klasse erzeugt, aber das finde ich persönlich ein wenig überzogen. ausserdem find ich ich auf diese weise logik und ausgabe viel besser und schöner auseinandergehalten, da ich nicht in einem servlet ein template laden muss, werte zuweisen, eingaben überprüfen etc, sondern eine kleine abwandlung eines gewöhnlichen templates nutzen kann, welches den server anweist, was er tun soll. diese anweisungen kann ich auf das allernötigste beschränken. solche definitionen kann man im übrigen nicht nur für html-ausgaben einsetzen, sondern in etwas abgewandelter form auch für eine art cli-modus, bzw für plain tcp, als sprungbrett für ein eigenes protokoll zur kommunikation zwischen server und client (das soll nicht heissen, dass ich das vorhabe, techniken wie xml-rpc sind mir bekannt). solange sich an der logik nichts ändert, sollten damit auch nicht versierte programmierer die möglichkeit haben, eine zusätzliche ausgabemöglichkeit anzulegen, beziehungsweise eine bestehende leicht abzuändern. wenn ich falsch liege, klärt mich bitte auf.
mfg atrox

@TheHawk ...
JSPs sind zwar sehr bequem, aber doch recht langsam.
Ich glaube der Artikel wurde schonmal hier im Forum genannt: www.heise.de/ix/artikel/2005/10/124/ ... Bild1 gibt dir jedenfalls mal einen Anhaltspunkt zu den Geschwindisgkeitsunterschieden einiger "View"-Technolgien der Darstellungsschicht.
MrMaxx

@TheHawk:
Ich weiß jetzt nicht, wie JSF genau implementiert sind. Diese Komponenten-Konzept ist aber z.B. gerade aus Rails verbannt worden, da es zu viel Datenbanklast verursacht hat.
@AtroX:
Du willst alle eingehenden Fragen in einem zentralen Modul behandeln, gegebenfalls auf mehreren Protokoll-Ebenen. Wenn das so gemeint ist, wie ich es verstehe, dann wünsche ich schon mal viel Spaß mit der Wartung. Eigentlich geht der Trend doch in die genau gegen gesetzte Richtung, und das aus gutem Grund.

wenn alle browser clientseitige XSL-transformation unterstützen würden könnte man nurnoch mit xml um sich werfen
hach wär das toll

so mal als vorwarnung - ich habe keine ahnung von Java im Server umfeld
ich habe tage gebraucht um mal nen tomcat zum laufen zu bekommen und ne einfache war zu installieren und gekotzt wegen irgend wlechen lib abhängigkeiten.
so nun zum thema:
wegen db4o - schön und gut, und ich finde den ansazt auch super aber dafür die komplette applikation unter die gpl stellen?
und auch die MySQL Connectoren für Java sind doch GPL also auch wieder alles unter die GPL
ich bin auch ein großer fan von mysql und der gpl - aber bitte bei libaries oder sowas wie db40 ist die eher schädlich und nur zur geldmacherei
meine emfpehlung mal sqlite, firebird oder pgsql anschauen.

Original von woodworker
wegen db4o - schön und gut, und ich finde den ansazt auch super aber dafür die komplette applikation unter die gpl stellen?

Da ich das hier jetzt schon mehrfach gelesen habe, muss ich einfach mal nachfragen, auch wenn es nicht direkt zum Thema gehört. Wie kommt Ihr immer darauf, dass eine Nutzung von GPL Komponenten immer gleich bedeuten soll, die eigene Anwendung unter der GPPL zu veröffentlichen? Es gibt bei Nutzung keine Veröffentlichungspflicht. Nur bei Änderung an der GPL Komponente.

bei db4o ist es auf jedenfall so
weil man durch nutzen der einmaligen API ein derivat erstellt
eigenartig aber leider wahr

3. Derivative Works
For the purpose of this Agreement, software is deemed a derivative work of the Software ("Derivative Work") where it is based on the Software, including without limitation in the following circumstances:
a. the software is compiled against the Software;
b. the software contains specific references to the Software;
c. the software requires the Software to work; or
d. the software uses the proprietary API to the Software.
aber es muss aber nicht unbedingt gpl sein sondern man kann auch eine andere OS-lizenz nehmen irgendwie über deren dOCL lizenz
siehe
www.db4o.com/about/company/legalpolicies/docl.aspx
und
best-practice-software-engineering.blogspot.com/2006/12/tech-db4o-license-issues.html
zum glück nutz ich db4o nicht *unschuldigpfeif*

Java als Technologie für Browsergames ist grundsätzlich keine schlechte Idee. Diese Games gehen von der technischen Seite oft doch sehr stark über simple dynamische Websites (wo PHP seine Stärken hat) hinaus. Man muss sich aber darüber im Klaren sein, dass man für Java wesentlich mehr Einarbeitungszeit benötigt als für PHP. Gerade als Neuling in Java kann man gut und gerne mit 2-3 Monaten Zeit rechnen (wenn man nicht Vollzeit daran arbeitet), sich in den verschiedenen Technologien und Frameworks einzudenken, um eine benutzbare Umgebung zu erhalten. Man kann da halt nicht wie in PHP einfach drauflosprogrammieren sondern muss sich überlegen ob man Servlets oder JSPs oder JSF verwendet und wenn das entschieden ist welche Frameworks verwendet werden. HTML hardkodiert mit Servlets auszugeben ist ziemlich unschön, genau so wie es unschön ist reines JDBC für die Datenbank zu programmieren. Dafür gibts in Java viele feine Frameworks - aber in die muss man sich auch erst einarbeiten. Ansonsten wird man von Java sehr schnell sehr bitter abgestraft.
Ich entwickel mein Spiel ebenfalls in Java. Da ich aber kein Freund von Frameworkmonstern wie Spring und Hibernate bin, setze ich auf relativ simple aber umso effektivere Lösungen.
Als Datenbank läuft bei mir PostgreSQL. Postgres spielt IMHO wunderbar mit Java zusammen. Zum einen ist es einfach grundsätzlich eine vernünftige Datenbank, darüber hinaus gibt es aber viele feine Features wie z.B. die Tabellenvererbung die gut in eine Javaanwendung passen.
Als Servletcontainer benutze ich vorzugsweise Jetty. Der hat den Vorteil, dass man ihn sehr einfach in eine Javaanwendung einbetten kann. So läuft der Webserver bei mir einfach als eine von mehreren Komponenten in der Gameengine. Innerhalb von Jetty wird das Frontend als Standardwebapp deployed, was wiederum den Vorteil hat, dass das Frontend auch einfach in einem Tomcat oder anderem Applicationserver deployed werden könnte. Requests laufen wie gehabt durch ein Servlet durch, welches die benötigen Daten zusammenstellt, in ein Templateobjekt packt und den Request an die Viewkomponente (realisiert mit der Freemarker Templating Engine) weiterleitet.
Anbindung an Postgres läuft via iBatis Sql Maps. In meinen Augen eines der besten ORM-Tools für Java überhaupt. Der große Vorteil ist in meinen Augen, dass man die SQL-Statements und deren Mappings in Java-Objekte (anders als in Frameworks wie Hibernate z.B.) selber schreibt. Dadurch kann man sehr viel einfacher komplexe Statements verwenden als dass SQL generierende Frameworks ermöglichen. Zum anderen ist man nicht an ein 1:1-Mapping von Java-Objekten zu Datenbanktabellen gebunden sondern kann seine Datenklassen etwas natürlicher gestalten.
Ansonsten kommen noch ein paar kleinere Sachen zum Einsatz wie XML-Parser, Log4j fürs logging etc.pp. Und neben dem Webserver laufen noch ein paar andere Dienste wie z.B. das event schedulung & handling.
Der Rest wurde von mir nach Bedarf dazugeschrieben. So habe ich im Lauf der Zeit z.B. viele Makros für Freemarker geschrieben die semiautomatisch Formulare erzeugen, ausfüllen oder Ajaxantworten generieren. Damit erfinde ich teils das Rad natürlich neu, allerdings habe ich damit sehr schlanke Lösungen die ich - anders als in einem Framework wo meine Daten durch 150 verschiedene Objekte durchlaufen bis sie mal bei mir ankommen - schnell durchschaue und schnell anpassen kann.
Trotz Java ist meine Devise nach wie vor "Keep it Simple"
Long story short: wenn du Interesse an Java hast, dann nimm dir erstmal viel Zeit dich in die verschiedenen Möglichkeiten einzuarbeiten. Java ist mächtig und wenn man ganz frisch in die Thematik einsteigt wird man vom Umfang der Möglichkeiten schnell erschlagen. Aber es lohnt sich auch wieder, wenn man sich die Zeit genommen hat.

Da ich selber Java nutze, auch von mir noch ein Hinweis:
Im Gegensatz zu exe bin ich Freund und Anwender der "Frameworkmonster", wie er sie nennt Warum ist glaube ich eine Religionsfrage, nur sollte jedem, der sich entscheidet zum Beispiel HIbernate zu verwenden klar sein, dass er es mit (ich nenne es mal so) Business-Software zu tun hat. Software, die eigentlich in mittleren- bis großen Softwareprojekten zur Anwendung kommen mit der für gewöhnlich bezahlte Profis mit entsprechender Ausbildung und/oder bezahltem Support arbeiten. Das kann einen etwas frustrieren, wenn man die ersten Schritte macht und merkt, dass es für diese Art der Java-Anwendung nicht hunderte Skript-Kiddie-Foren gibt in denen man sich schnell einen Hack für ein Problem besorgen kann wie das bei PHP der Fall ist.
Zudem wird man gerade zu Anfang sicher mehrere Male das Framework für seine Anwendung neu aufbauen oder überdenken, weil das entwerfen einer Architektur geübt sein will und viel Erfahrung braucht, welche man als Anfänger natürlich nicht hat. Ich kann hier nur empfehlen, gängige "best practices" weitestgehend einzuhalten. Auch wenn es teilweise mühsam erscheint kann einem ein ordentliches MVC-Pattern viel Ärger ersparen, während es schlampig umgesetzt in einem Framework welches das eigentlich fordert (bsp. Struts) mit Sicherheit für Probleme sorgt. Auch sollte man, wenn man zum Beispiel von PHP umsteigt, einen längeren Blick auf Objekt-Orientierte Programmierung werfen und sie verinnerlichen! Eclipse (nur als Beispiel) starten und auf die selbe prozedurale Art weiter programmieren wie unter PHP bringt keinem was

Ich kann mich meinen beiden Vorpostern nur anschliessen. Java ist sehr mächtig und es gibt eine Menge Frameworks, die einem viel Arbeit abnehmen. Auf jeden Fall sollte sich jeder Entwickler einmal mit Java beschäftigt haben.
(Eigentlich hatte ich schon einen größeren Beitrag erfasst, aber er ist leider bei der Vorschau verloren gegangen ^^)
Ich arbeite mich gerade in Freemarker ein. Schaut sehr interessant aus.
Habt ihr schon Spiele live sie in Java geschrieben sind? Was sind Eure Erfahrungen hinsichtlich Last auf dem Server, Wartbarkeit usw?

Anmerkung / OffTopic:

Original von the-architect

(Eigentlich hatte ich schon einen größeren Beitrag erfasst, aber er ist leider bei der Vorschau verloren gegangen ^^)
dazu kann man sich mal flgenden thread zu gemüte führen: save quick, save often - hier hakt nämlich einiges .. und somit ist strg+a; strg+c quasi pflicht.

> Habt ihr schon Spiele live sie in Java geschrieben sind? Was sind Eure Erfahrungen hinsichtlich Last auf dem Server, Wartbarkeit usw?
Kann nur über ASP.Net sprechen, da wird Java nicht hinten dran stehen. Ich bin sehr zufrieden mit den 'modernen' Technologien und spare wirklich viel Arbeit dadurch, dass ich nicht PHP verwende, sondern auf einem gigantischen Framework aufbaue, dass anfangs viel Stress verursacht, aber man im Nachhinein mit einem Lächeln programmiert.

Original von the-architectHabt ihr schon Spiele live sie in Java geschrieben sind? Was sind Eure Erfahrungen hinsichtlich Last auf dem Server, Wartbarkeit usw?

Bei sehr kleinen Projekten dürfte es eigentlich keinen Unterschied in der Geschwindigkeit geben. Wenn man es genau misst dürfte das Ganze bedingt durch das dicke Framework (sowohl bei .NET als auch bei Java) sogar etwas langsamer laufen. Vorteile werden dann sichtbar, wenn viele User das System belasten. Liegt in meinen Augen vor allem daran, dass eine Java-Web-Applikation eher einem üblichen "Programm" als einer losen Skriptsammlung wie bei PHP entspricht. Wichtige Resourcen werden bei Start einmal initialisiert und stehen dann bis zum abschalten des Servers/der Anwendung zur Verfügung mit vielfältigen Möglichkeiten für Caching etc. Bei PHP muss jedes Skript seine ganze Umgebung erst nochmal neu aufbauen, bevor es sie nutzen kann. Das merkt man dann auch, wenn es an intensive Backgroundjobs geht. Bei PHP-Lösungen neigt man dann oft dazu, diese in C/C++ oder sonstige Programme im Hintergrund auszulagern, ergo, man schreibt Code doppelt. Von den Problemen bei der Synchronisation und sich überschneidenden Datenbankzugriffen ganz zu schweigen. Bei Java sind die Backgroundjobs ein Teil des Ganzen wie alles andere auch und können beispielsweise bequem in eigene, getimete Threads gepackt werden.

Original von Lunikon

Original von the-architectHabt ihr schon Spiele live sie in Java geschrieben sind? Was sind Eure Erfahrungen hinsichtlich Last auf dem Server, Wartbarkeit usw?

Bei sehr kleinen Projekten dürfte es eigentlich keinen Unterschied in der Geschwindigkeit geben. Wenn man es genau misst dürfte das Ganze bedingt durch das dicke Framework (sowohl bei .NET als auch bei Java) sogar etwas langsamer laufen. Vorteile werden dann sichtbar, wenn viele User das System belasten. Liegt in meinen Augen vor allem daran, dass eine Java-Web-Applikation eher einem üblichen "Programm" als einer losen Skriptsammlung wie bei PHP entspricht. Wichtige Resourcen werden bei Start einmal initialisiert und stehen dann bis zum abschalten des Servers/der Anwendung zur Verfügung mit vielfältigen Möglichkeiten für Caching etc. Bei PHP muss jedes Skript seine ganze Umgebung erst nochmal neu aufbauen, bevor es sie nutzen kann. Das merkt man dann auch, wenn es an intensive Backgroundjobs geht. Bei PHP-Lösungen neigt man dann oft dazu, diese in C/C++ oder sonstige Programme im Hintergrund auszulagern, ergo, man schreibt Code doppelt. Von den Problemen bei der Synchronisation und sich überschneidenden Datenbankzugriffen ganz zu schweigen. Bei Java sind die Backgroundjobs ein Teil des Ganzen wie alles andere auch und können beispielsweise bequem in eigene, getimete Threads gepackt werden.
Dem kann ich nicht so ganz zustimmen.
Unter PHP gibt es viele mächtige Frameworks. Wenn man keine mag, kann man diese selbst erstellen.
Mit Tools wie ZendOptimizer oder eAccellerator erspart man sich das Aufbauen einer neuen Laufzeitumgebung.
In unseren Benchmarks (PHP 4.0.8 vs. Java 1.3 vs. .NET 1.0), war .NET mit abstand das schnellste, dann kam PHP und knapp dahinter Java. Unter Last ist Java ziemlich runtergegangen, da wegen des großen RAM-Verbrauchs viel geswapped werden musste.
Würde ich meine Projekte nochmal anfangen, würde ich aber eindeutig auf Ruby (on Rails) setzen. .NET ist ebenfalls sehr nett, allerdings leider nicht 100% Plattformunabhängig, ein unabdingbares kriterium für mich.

Original von Kampfhoernchen
Unter Last ist Java ziemlich runtergegangen, da wegen des großen RAM-Verbrauchs viel geswapped werden musste.

Dann ist der Test nichtig.
Im Gegensatz zu PHP überleben Java-Objekte einen Request und verweilen im RAM, was Java skalierbarer macht. Wenn die User in die Tausende gehen, merkt man das auch. PHP ist bei kleinen Projekten schneller, Java aber skalierbarer und bei der Performance bei Mega-Projekten (Flughäfen, Versicherungen, Banken... Enterprise Applications eben) dann irgendwann auch besser.
Dass für solch einen Test die Hardware stimmen muss versteht sich von selbst.
Das Argument "alles auf gleicher Hardware" greift nicht, da J2EE von Haus aus nicht für das gleiche konzipiert ist wie PHP, will man also die Performance vergleichen, muss man an Hardware jedem das zugestehen, was er verlangt.

Dies ist aber dann kein Test mehr!!
Bei einem Test ist Vorraussetzung das die Umgebung eine Konstante ist. Sonst könnte ich ja nie die Vor- oder Nachteile eines Systems ermitteln, wenn ich mich immer nach den Anforderungen der Systeme richte.

Original von thecruel
Dies ist aber dann kein Test mehr!!
Bei einem Test ist Vorraussetzung das die Umgebung eine Konstante ist. Sonst könnte ich ja nie die Vor- oder Nachteile eines Systems ermitteln, wenn ich mich immer nach den Anforderungen der Systeme richte.

In der Tat...in so einem Fall kommt dann aber eine J2EE-Lösung schlicht nicht in Frage, wenn ich mein Projekt maximal auf einem handelsüblichen Server laufen lassen will. Im Gegenteil...wenn das Projekt mit sowas auskommt, kann man sich den Aufwand mit Java sparen und weiter PHP verwenden, weil dann offensichtlich ein derartiges Framework nicht benötigt wird.
Bei der Begründung schließe ich mich einfach mal Riki an, er hat das m.E. treffend formuliert.

Original von thecruel
Dies ist aber dann kein Test mehr!!
Bei einem Test ist Vorraussetzung das die Umgebung eine Konstante ist. Sonst könnte ich ja nie die Vor- oder Nachteile eines Systems ermitteln, wenn ich mich immer nach den Anforderungen der Systeme richte.

Umgedreht wird auch ein Schuh daraus.. denn sonst sage ich ab sofort (zur Not muss ich dann noch umständlich Testobjekte kaufen, zum Beweisen), dass Linux State-of-the-art Suse ich weiß nicht was wesentlich schlechter als das gute alte MS-DOS 6.22 ist. Jawohl! Ich darf die Hardware (Umgebung) aussuchen. Ich hab zwei unvergleichbare Produkte verglichen? Wieso.. man kann sie doch vergleichen.
Verstehst du was ich meine?
Natürlich muss ein Test feste Konstanten haben, aber man darf diese nicht so wählen, dass ein Testprodukt dadurch beeinträchtigt wird. Das wird wohl auch der Grund sein, warum a) Tests gar nicht so leicht sind und man b) Tests immer mit Misstrauen begegnen sollte. Direkt nach Statistik.

Falsch.
Man testet ja nicht einfach ins Blaue. Man weiß doch vorher genau, was man erreichen will. Und dementsprechend wählt man dann seine Möglichkeiten. Willst du also nur ein paar Dateien verwalten (blödes Beispiel), kann es durchaus sein, dass dein DOS besser abschneidet als Suse Linux. Wenn ich weiß, dass ich ein BG für 500 Spieler realisieren will, dann reicht mit ein üblicher Server mit 512MB oder 1GB RAM und ich kann bequem auf LAMP setzen oder eben etwas anderes, was unter diesen Umständen am besten passt. Wenn ich aber weiß ich will ein BG eröffnen, dass mit 2000 Spielern anfängt und irgendwo bei 50.000 aufhören könnte, dann ist ein Test auf einer 2GB-Maschine von der Stange einfach hinfällig. Ich denke das ist doch einleuchtend, oder?

So, erstmal zum Thema Skalieren: Ich habe gerade gestern folgende Slides von einem Vortrag eines Sun-Mitarbeiters bekommen: tbray.org/talks/php.de.pdf
Wie man den Slides entnehmen kann, ist Sun der Meinung, dass PHP besser skaliert, als Java. Folgenden Artikel fand ich auch ganz informativ: blogs.codehaus.org/people/tirsen/archives/001041_ruby_on_rails_and_fastcgi_scaling_using_processes_instead_of_threads.html
Zu dem Thema Test: also eigentlich ist es doch totaler Schwachsinn, Sprachen und Frameworks, in Hinblicke auf Performance, gegeneinander zu vergleichen. Die Parameter und Anforderungen sind viel zu weit
gestreut. Man sucht eine Sprache ja nicht aufgrund der Performance aus, zumindest nicht nur. Und gerade bei Webbasierten Anwendungen hat man mit so vielen zusätzlichen Komponenten zu tun, das die Performance der Sprache völlig in den Hintergrund gerät.
Wenn ich mir das Rails Umfeld ansehe, könnte ich jetzt hundert Vergleiche und Diskussionen posten, bei denen es allein um das Thema Webserver-Performance geht: Lighty allein, Lighty hinetr Apache mit mod_proxy, Mongrel, Mongrel hinter Apache, Mongrel hinter Lighty, Lightspeed, WebBrick, usw.
Bei Thema Skalierbarkeit, dass gleiche: Wie skaliert die Anwnedung als solche, wie skaliert die ganze Umgebung auf einem Rechner, wie skaliert das ganze im Netzwerk, usw.
Mein Fazit zu den Tests: Es gibt nichts, was viel schwerer ist, als effektive Tests einer Webanwendung zu machen, da so viele Faktoren einspielen, dass man gar nicht alles im Vorfeld beachten kann und man schon irgendwie ins blaue hinein testen muss.
Ich handhabe es bei meinem Projekt nach dem Entscheiden und Optimieren verfahren. Ein Teil der Komponenten entscheide ich nach Vorlieben, bzw. dem Bauchgefühl und allgemeinem Kenntnisstand. So steht bei mir fest: RoR, Lighty, FastCGI, MySQL. Und wenn die Anwendung damit steht, wird Test-basiert optimiert. Und da gibt es eine ganze Liste an Möglichkeiten (alternativer gepatchter MySQL Connector, memchached, inline C und vieles mehr). Und alles was Performance bringt, und einen guten Kosten/Nutzen Faktor hat, wird integriert). Und dann entscheide ih mich erst, wie viel RAM der Server braucht.

Original von AgmemonIch handhabe es bei meinem Projekt nach dem Entscheiden und Optimieren verfahren. Ein Teil der Komponenten entscheide ich nach Vorlieben, bzw. dem Bauchgefühl und allgemeinem Kenntnisstand. So steht bei mir fest: RoR, Lighty, FastCGI, MySQL. Und wenn die Anwendung damit steht, wird Test-basiert optimiert. Und da gibt es eine ganze Liste an Möglichkeiten (alternativer gepatchter MySQL Connector, memchached, inline C und vieles mehr). Und alles was Performance bringt, und einen guten Kosten/Nutzen Faktor hat, wird integriert). Und dann entscheide ih mich erst, wie viel RAM der Server braucht.

Ich glaube dieser Absatz verdeutlicht sehr gut, wo einige der Vorteile von Java liegen. Hier werden bald ein dutzend unterschiedliche Produkte/Möglichkeiten genannt um ein einziges Produkt zu erzeugen. Und hier geht es nicht um einzelne Funktionsbereiche, sondern mehrere Komponenten dienen dem Ziel, einen Aspekt zu bewältigen. Klingt jetzt sehr unverständlich, ich versuchs mal in ein Beispiel zu packen:
sein Projekt
Framework, Darstellung: RoR
Server: Lighty/FastCGI
DB: MySQL
Performance: FastCGI, memcache, inline C, gepatchter MySQL Connector
mein Projekt
Framework: Struts
Server: Tomcat
DB: MySQL
DB-Abstraktion: Hibernate
Darstellung: JSP
Performance: -
Zusätzlich verwende ich natürlich noch andere Libraries für spezielle Funktionalitäten. Ich weiß nicht, was da jetzt alles von RoR abgedeckt wird (kenne mich damit nicht aus), aber ich denke es wird deutlich was ich meine. Er bastelt hier und da an seinem Setup rum, um evt. die Performance zu verbessert. In dieser Zeit habe ich schon mehrere Funktionen für mein Spiel geschrieben

Original von Lunikon
Er bastelt hier und da an seinem Setup rum, um evt. die Performance zu verbessert. In dieser Zeit habe ich schon mehrere Funktionen für mein Spiel geschrieben

Das siehst Du jetzt aber gehörig falsch. Eigentlich hast Du sogar mehr zu basteln als ich. Nehmen wir mal den Performance-Sektor raus, weil Du scheinbar keine Performance-Optimierung machst:
Framework: RoR <-> Struts
Server: Lighty mit FastCGI <-> Tomcat
DB: MySQL <-> MySQL
DB-Abstraktion: RoR (ActiveRecord) <-> Hibernate
Darstellung: RoR (ActiveView) <-> JSP
Du hast 5 Komponenten mit denen Du dich rumschlagen musst, ich nur drei Komponenten, da RoR O7R-Mapping und Template-System schon beinhaltet.
Und was die Performance-Optimierung betrifft, betrifft dass Deine Java-Umgebung genauso, wenn nicht noch mehr. So ist memcached sicherlich auch für das Java-Umfeld nützlich. Und wenn es an das Thema Skalieren geht, habe ich viel weniger zu tun, als das bei Java der Fall ist. Mein Setup ist nämlich schon darauf ausgerichtet, in einem Cluster zu laufen, ohne das ich groß was machen muss. Das übernimmt Lighty mit FastCGI.
Bei Java wird es an der Stelle dann spannend. Die ganze Anwendung läuft einer einer Maschine wunderbar in einer VirtualMachine, mit Shared Memory, und denn fleissigen zeitgesteuerten, synchronisierten Threads. Und was ist dann, wenn du ein Cluster brauchst? Bis das bewerkstelligt ist, habe ich nicht ein paar neue Spielfunktionen geschrieben, sondern vermutlich schon ein neues Spiel.

Das gesamte Caching erledigt nach etwas Konfiguration Hibernate für mich. Also das ist nicht das Problem
Ich muss zugeben, dass ich kein Experte auf bin, was die gesamte Peformance-Tunerei angeht. Daher bin ich wohl auch bei Java gelandet. Ich schlage mich einfach ungerne mit Sachen rum, die eher technischer Natur sind und weniger der Sache dienlich. Was Clustering betrifft: Bei AirlineSim setzen wir ja gerade auf Java, um kein Clustering zu brauchen
Unser Problem waren immer die Updates im Hintergrund, die Einfach sehr komplex und daher nicht wirklich ein Ding für PHP waren. Und da ein Auslagern dieser Prozesse auf ein C/C++-Programm oder ähnliches zu aufwendig gewesen wäre, haben wir alles in Java gemacht und sind ganz glücklich damit. Aber auch mit Java ist ein Clustering möglich, sonst wäre es nicht so erfolgreich im Bereich der großen und sehr großen Anwendungen. Den Aufwand dafür zu verallgemeinern ist aber m.E. auch wieder schwierig, denn Clustering kann man auf unterschiedlichste Arten und Weisen betreiben, auch über mehrere JVMs hinweg.

Original von riki1512

Original von Kampfhoernchen
Unter Last ist Java ziemlich runtergegangen, da wegen des großen RAM-Verbrauchs viel geswapped werden musste.

Dann ist der Test nichtig.
Im Gegensatz zu PHP überleben Java-Objekte einen Request und verweilen im RAM, was Java skalierbarer macht. Wenn die User in die Tausende gehen, merkt man das auch. PHP ist bei kleinen Projekten schneller, Java aber skalierbarer und bei der Performance bei Mega-Projekten (Flughäfen, Versicherungen, Banken... Enterprise Applications eben) dann irgendwann auch besser.
Das ist auch nur bedingt richtig. RIchtig ist, dass man in Java Objekte im RAM halten kann, da ein Request kein Servlet neu initialisiert sondern nur ein Methodenaufruf an einem bestehenden Objekt ist. Und so bleibt ein Objekt, dass ausserhalb des lokalen Namensraums der Funktion referenziert wird, über den Request hinaus erhalten. Damit kann ich mir natürlich auch wunderbar Memory Leaks bauen. Das, oder ein schlechter Servletcontainer welcher unter Last zuviel RAM in seinen Threads verbraucht, kann dazu führen, dass mir unter Last der RAM verloren geht. Dass ist dann allerdings kein Javaproblem sondern ein Anwendungsproblem. Genauso wie ein memory leakender Apache kein Problem von PHP wäre
DIe Mär vom langsamen und Ressourcenschluckenden Java ist nunmal nicht mehr ganz aktuell. Ich habe bei mir ebenfalls vor kurzem ein paar Tests gemacht. Das Resultat war, dass Java in der reinen Ausführungsgeschwindigkeit um den Faktor 2-3 schneller ist als PHP und Perl. Eine frisch gestartete VM verbraucht bei mir ziemlich genau 10mb RAM, die komplette Gameenginge frischt gestartet rund 30mb. Sobald die Template und Konfigurationscaches gefüllt sind liegt der Ramverbrauch bei knapp 40 MB und bleibt im Normalbetrieb konstant. Der Verbrauch ist damit ziemlich identisch zum normalen Apache, der auf der gleichen Maschine liegt, und für Javaverhältnisse extrem puristisch (ich erwähnte ja bereits, dass ich auch unter Java auf schlanke Lösungen stehe) Unter Last geht der RAM-Verbrauch etwas nach oben (83mb etwa), bleibt dort aber konstant und liegt immernoch niedriger als der RAM-Verbrauch der Apache/PHP-Variante im gleichen Test. (Gleich bis auf die Tatsache, dass die PHP-Komponente im Test wesentlich einfacher arbeitet als die Java-Komponente).
Es ist allerdings kein Vergleich mit aufgemotztn Application Servern. Wenn ich da einen habe der frisch gestartet 400mb RAM frisst ist klar, dass ich das nicht auf einer Hardware mit 1GB RAM wo noch ein Datenbankserver läuft performant hinkriege. Ist dann aber auch ein schlechter Vergleich mit ein paar PHP-Scripts ...

Original von Agmemon

Und was die Performance-Optimierung betrifft, betrifft dass Deine Java-Umgebung genauso, wenn nicht noch mehr. So ist memcached sicherlich auch für das Java-Umfeld nützlich. Und wenn es an das Thema Skalieren geht, habe ich viel weniger zu tun, als das bei Java der Fall ist. Mein Setup ist nämlich schon darauf ausgerichtet, in einem Cluster zu laufen, ohne das ich groß was machen muss. Das übernimmt Lighty mit FastCGI.
Das ist aber keine Frage der Programmiersprache sondern eine Frage der Laufzeitumgebung. Wenn ich meine Javaanwendung in einem Server laufen lasse, der von sich aus Clustering unterstützt, habe ich damit auch keine Sorgen mehr.

Bei Java wird es an der Stelle dann spannend. Die ganze Anwendung läuft einer einer Maschine wunderbar in einer VirtualMachine, mit Shared Memory, und denn fleissigen zeitgesteuerten, synchronisierten Threads. Und was ist dann, wenn du ein Cluster brauchst? Bis das bewerkstelligt ist, habe ich nicht ein paar neue Spielfunktionen geschrieben, sondern vermutlich schon ein neues Spiel.

Wenn er quer durch die Anwendung seine Threads synchronisieren muss, hat er einfach was falsch gemacht - ist dann aber wieder kein Problem der Programmiersprache. Zum beispiel das Eventhandling wie es bei mir läuft: ein Schedulerobjekt läuft in einem Thread, hat eine Queue von Events und gibt die bei Bedarf an seine Handler weiter. Der Scheduler ist aber als Dienst innerhalb der Engine abgekapselt, also nur über eine Schnittstelle anzusprechen. Synchronisation macht die Seite des Schedulers an der Schnittstelle, der Rest der Anwendung muss sich da nicht drum kümmern. Genauso sind die einzelnen Eventhandler an den Scheduler angebunden. Wenn mir nun die Performance auf einer Hardware ausgeht, kann ich den Scheduler und sogar die einzelnen Handler auf verschiedene Server in eigene Virtuelle Maschinen packen und muss nur die interne Implementierung der Schnittstelle von Methodenaufrufe zu TCP-Sockets umstellen.
Wenn ich nun natürlich direkt von den Servlets aus auf die Eventhandler zugreifen würde hätte ich allerdings ein Problem wenn ich die Anwendung zwecks Clusterung auf mehrere Rechner aufteile. Aber das ist dann ein Programmierfehler meinerseits, kein Fehler der Sprache oder des Servers.

@riki1512:
Ergebnis war: Java ewigst lahm auf ner doch recht fetten Kiste (2x 2,2 GHz, 4 gig ram).
PHP hat die Reaktionszeiten auf dem gleichen System unter 1,5 Sekunden gehalten, Java hat für das gleiche gut 1,6 Sekunden gebraucht. ASP.NET (ebenfalls mit persistenten Objekten) übrigens nur 1,1, wenn auch mit vielen Ausreißern nach oben (bis 1,5).
Das ganze abgeleitet aus dem Request-Verhalten des Vorgängersystems, also nix mit unrealistischen Testfällen.

Nochmal zum Thema Clustering und Java: Hier sieht Terracotta (www.terracotta.org/) sehr interessant aus, hatte und werde in nächster Zeit aber keine Zeit haben, mir das näher anzuschauen. Hat damit schon jemand Erfahrungen gemacht? Hibernate scheint ja noch nicht offiziell unterstützt zu werden.

Original von Kampfhoernchen
@riki1512:
Ergebnis war: Java ewigst lahm auf ner doch recht fetten Kiste (2x 2,2 GHz, 4 gig ram).
PHP hat die Reaktionszeiten auf dem gleichen System unter 1,5 Sekunden gehalten, Java hat für das gleiche gut 1,6 Sekunden gebraucht. ASP.NET (ebenfalls mit persistenten Objekten) übrigens nur 1,1, wenn auch mit vielen Ausreißern nach oben (bis 1,5).
Das ganze abgeleitet aus dem Request-Verhalten des Vorgängersystems, also nix mit unrealistischen Testfällen.

Das finde ich Interressant bzw. erschreckend. 1, irgendwas Sekunden sind ja eigentlich Welten in der Informatik. Was war den die zu erledigende Aufgabe. Man müste solche Tests auch mal mit Google vergleichen ;-) Die schaffen es offensichtlich Millionen von Anfragen in Bruchteilen von Sekunden zu beantworten, die werden aber wahrscheinlich auch nicht von IBM oder Sun beraten ;-)

Sieht interessant aus, ist aber - soweit ich das überblicke - auch mit einem gewissen Aufwand in der Implementierung verbunden. Will heissen: man kann das nicht schnell installieren und hat sofort sein Grid-Computing.
Ich denke auch, dass das für Browsergames eher uninteressant ist. Der Punkt ist doch, dass trotz gewisser Animositäten mancher Leute bestimmten Programmiersprachen gegenüber, die Wahl der Programmiersprache keine bahnbrechende Auswirkung auf das Spiel hat. Egal ob ich jetzt in C#, Java, PHP, Perl, Python oder Ruby programmiere, ein Browsergame kriege ich damit problemlos hin. Und auch ein paar Tausend aktive Spieler bringen nicht die Sprache in Schwierigkeiten sondern bestenfalls einen schlechten Programmierer. Und auch wenn das Spiel die 15.000 Spieler in einer Spielwelt überschreitet, so komm ich mit vorhandenen einfachen Clusteringmöglichkeiten (Datenbankcluster + Loadbalancing im Frontend via mod_proxy und ähnlichem) immernoch problemlos auf 50.000 oder auch 100.000 aktive Spieler in einer Spielwelt. Ohne programmiertechnisch himmlische Lösungen zu zaubern.
Sauber auf Clustering designte Lösungen oder sogar Spielzeuge wie Terracotta, mit denen man in Richtung verteilte Anwendungen bzw. Grid-Computing, geht sind für Browsergames im Grunde irrelevant. Das Spiel, dass von so einer Lösung wirklich profitieren würde wäre im Grunde ein OGame mit einem einzigen Universum - etwas, dass nicht existiert, wahrscheinlich auch nie existieren wird und selbst wenn jemand so ein Spiel hinkriegt - bis dahin hat das so lange gelebt, dass du es sowieso 2 mal neu programmiert hast, bis sich so ein extremes Clustering rentieren würde und eine Implementierung in Frage kommen könnte.
Kurz gesagt: man sollte das Spiel einfach entwickeln und sich nicht mit akademischen Fragen aufhalten die bestenfalls in 3 Jahren interessant sein könnten ..

eine sprache besteht ja auch aus viel mehr als aus performance
viel wichtiger sind effektivität in der implementation, wartbarkeit und das wichtigste ist das die gewählte sprache an das problem angepasst ist

Zum Thema Geschwindigkeit möchte ich folgendes sagen: Es hängt sehr viel davon ab, wie man seine Anwendung konstruiert und programmiert hat.
Qforces.de ist komplett in Java geschrieben. JSP als Frontend und im Hintergrund laufen ein Paar Servlets für Requests und ganz normale Klassen für die Logik.
Zur Zeit läuft das Spiel auf einem P3-700 Server mit 256mb RAM und hält so einiges aus.

Nun Hörnchen, da scheinen sich deine Ergebnisse mit denen (zugegebenermaßen überraschenden) von exe zu beissen. Wird wohl sehr viel von Rahmenbedingungen abhängen, wie ich vermute. Bei mir waren Java-Test-Webapplikationen stets etwas langsamer, als PHP-Pendants. Nur habe ich mit Objekten von gerade mal 1-2 Servletklassen hantiert.
Dass PHP besser skaliert als Java klingt für mich überraschend. Was geschieht, wenn in einem Unternehmen für ein Request Instanzen von 40 verschiedenen Klassen benötigt werden, und gleich mehrere Requests "gleichzeitig" reinkommen ? Die Objekte sind womöglich alle schon im RAM, unter Umständen handhabt Java das, ohne auf die Platte zu "gucken". Und PHP ? PHP muss erstmal die Klassendefinitionen der Klassen laden, dann instanziieren, und dann verarbeiten. Für den nächsten Request das gleiche von vorn ! Nun, keine Ahnung wie gut die Accelerators mittlerweile sind, ich dachte aber, sie hielten lediglich eine Art Kompilat der PHP-Dateien auf Platte fest und würden dieses abrufen, so dass nicht noch mal PHP interpretiert werden muss. Den Vorteil, dass das ganze in C geschrieben ist und direkt in Maschinencode vorliegt und nicht über die JVM ausgeführt werden muss wie auf der anderen Seite hielt ich für vernachlässigbar. Offensichtlich scheinen die Prozesse, die über Antwortzeiten entscheiden aber doch etwas komplexer zu sein. Gefühlsmäßig hätte ich im Prinzip sowas vorhergesagt:

Performance
^
|
| x
| x
| x
|oooooo x
| oooooo
| x oooooo
| x
| x
+------------------->
Komplexität (User/Requests/Klassen)
xx PHP
oo Java
Nun, um zum Thema zurückzukommen. Grundsätzlich rate ich (insbesondere Anfängern) für Browsergames von der Verwendung von Servlets/JSP (in einem Webcontainer), oder gar + EJBs (dann das ganze im Application Server) ab, weil ich glaube dass Java für komplexeres konzipiert ist. Wenn ihr glaubt, das Spiel könnte mal so groß werden, dass das ganze auf mehrere Kisten verteilt werden muss, fängt es für J2EE erst an interessant zu werden. (Übrigens lässt sich eine saubere PHP Applikation mit MVC/Data Access Layer im Sinne einer n-tier Architektur auch locker verteilen). J2EE ist eben das was es ist, EINE PLATTFORM FÜR KOMPONENTENBASIERTE, VERTEILTE SYSTEME (.NET ist übrigens nichts anderes). Und den Web-Teil (Tomcat, JSP, Servlets) sehe ich immer nur als einen Teil davon, der alleine, seit mir nicht böse, neben einfachen Skriptsprachen nun mal keinen einfachen Stand hat.
Wenn ich eine riesige Applikation baue, wo ich Verteilung, implizite Middleware (also kein CORBA), abstrachierte Persistenz, Multithreading, Transaktionssicherheit, Asynchronen Messaging Service, Sessions, Security usw. brauche, nehme ich eine fertige Mega Kiste (z.B. IBM Websphere, BEA Weblogic, JBoss...) wo genau das schon alles drin ist - nämlich einen Application Server. Der hat dann halt auch einen Webcontainer, in dem Servlets laufen können (und JSP, was ja letztendlich auch Servlets sind). Daher sehe ich JSP/Servlets/Tomcat eben immer als Teil der ganzen J2EE - klar, gibts möchtige Frameworks für und läuft tausendfach auch nur mit Webcontainer - ich denke aber wenn man nur den Webteil braucht fährt man mit PHP besser.
Die vielen Fehlerquellen bei Java (Compilieren, Verifizieren nach dem Deployen, die von Haus aus vorgegebene Struktur der zu deployenden jar files) haben mich immer zur Weißglut gebracht. Ich habe alles andere gemacht als Kernlogik programmiert, was ja eigentlich der Sinn der Application-Server ist. Ganz zu schweigen von dem Versuch, Programme die auf JBoss liefen mal in einem anderen Application-Server laufen zu lassen (CD und CD-Player Prinzip) - nee, nee, mein Favorit für reine Webapplikationen kleineren Ausmaßes bleibt PHP.
@Atrox
Von einem Abfangen der HTTP-Requests außerhalb der Servlets nur um später einen Client anbinden zu können rate ich ab. Wenn du die Spiellogik klar von der Darstellung und dem Controlling trennst (MVC), kannst du später locker einen Client anbieten, der bisherige Code bleibt unberührt, wird lediglich erweitert, das ist ja gerade der Sinn von MVC. Wenn du schon so krass abgehst, kapsle deine Spiellogiken halt in EJBs, dann ist deine Architektur so, wie es von Sun für den Idealfall propagiert wird: View sind die JSPs, Controller sind Servlets, und das Spielmodell EJBs, für nen neuen Client wird lediglich die View auf Desktop-Java ausgelagert(z.B. Swing) und ein Controller benötigt, der ein eigenes Protokoll handelt, du kannst die EJBs aber auch direkt anquatschen, denn für Requests aus dem Netz sind sie mitunter ausgelegt, J2EE ist auch eine Art Netzwerk-Betriebssystem (Die evtl. spätere Verteilung der Lasten ist dann übrigens auch schon totgeschlagen). Habe mal mit EJBs und View-Schichten im Browser einerseits und Swing-Clients andererseits rumgespielt (kleine Testprogramme) - lustige Sache. Aber wie gesagt, nicht mein Ding. Nen Java Client kannste locker auch für ein Browsergame in PHP basteln.
Na ja, was für mich immer noch die Mutter aller Grundlagen ist (um mit "Mutter aller Schlachten" Saddam Hussein zu zitieren): MVC + Data Access Layer ! Ist die Basis aller Frameworks und des kompletten J2EE Monsters.
[Recht-, Stil- und Grammatikfehler dürfen behalten werden, war erschrocken, als ich das ganze nochmals überflog, kein Bock ein drittes mal zu lesen]

Original von exe
Kurz gesagt: man sollte das Spiel einfach entwickeln und sich nicht mit akademischen Fragen aufhalten die bestenfalls in 3 Jahren interessant sein könnten ..

Amen :-) Ich denke es gibt wichtigere Themen als performance und Skallibarkeit. Performance bekomme ich mit mehr hardware, besserer Konfiguration und ggf. durch bessere Algorithmen hin. Skallierbarkeit bekommt man bei Browser-Spielen einfach durch mehrfache Instanzen des gleichen Spiels hin. Es macht doch keinen Unterschied, ob ich mit 500 oder 10.000 aktiven Spielern zusammen in einem Spiel zusammen spiele, die meisten von denen werde ich so oder so nie kennen lehrnen. Und als aktiver Spieler es nicht in die Top 100 schaffen zu können, könnte auch frustrierend wirken.
Zuverlässigkeit und Wartungsfreiheit halte ich für wesentlich wichtigere Themen. Mangelnde Zuverlässigkeit frustet den Anwender und hält einen von der eigenen Arbeit ab.
Arrg, weit OT geworden :-)

Original von Todi42
...
Man müste solche Tests auch mal mit Google vergleichen ;-) Die schaffen es offensichtlich Millionen von Anfragen in Bruchteilen von Sekunden zu beantworten, die werden aber wahrscheinlich auch nicht von IBM oder Sun beraten ;-)

Das Geheimnis von Google liegt wohl mehr im Weltklasse-Lasten-Balancing / Clustering als in der eingesetzten Programmiersprache. Werden bestimmt Hallen voll mit Servern sein, und die Anfragen perfekt verteilt. Wie macht man das eigentlich ?

Der Punkt ist doch, dass trotz gewisser Animositäten mancher Leute bestimmten Programmiersprachen gegenüber, die Wahl der Programmiersprache keine bahnbrechende Auswirkung auf das Spiel hat. Egal ob ich jetzt in C#, Java, PHP, Perl, Python oder Ruby programmiere, ein Browsergame kriege ich damit problemlos hin. Und auch ein paar Tausend aktive Spieler bringen nicht die Sprache in Schwierigkeiten sondern bestenfalls einen schlechten Programmierer. Und auch wenn das Spiel die 15.000 Spieler in einer Spielwelt überschreitet, so komm ich mit vorhandenen einfachen Clusteringmöglichkeiten (Datenbankcluster + Loadbalancing im Frontend via mod_proxy und ähnlichem) immernoch problemlos auf 50.000 oder auch 100.000 aktive Spieler in einer Spielwelt. Ohne programmiertechnisch himmlische Lösungen zu zaubern.

Amen :-)

Die teilen alles in kleine Stückchen und verarbeiten parallel die Anfragen über ihr Google File System.
Schau mal hier: labs.google.com/papers.html
PS: Interessant ist auch der MapReduce Ansatz, der es ermöglicht massiv parallel Daten zu verarbeiten.

Original von Todi42
Amen :-) Ich denke es gibt wichtigere Themen als performance und Skallibarkeit. Performance bekomme ich mit mehr hardware, besserer Konfiguration und ggf. durch bessere Algorithmen hin. Skallierbarkeit bekommt man bei Browser-Spielen einfach durch mehrfache Instanzen des gleichen Spiels hin. Es macht doch keinen Unterschied, ob ich mit 500 oder 10.000 aktiven Spielern zusammen in einem Spiel zusammen spiele, die meisten von denen werde ich so oder so nie kennen lehrnen. Und als aktiver Spieler es nicht in die Top 100 schaffen zu können, könnte auch frustrierend wirken.

In der Tat, in 90% der Fälle trifft das für BGs zu. Wenn sich die Rechenaufgaben auf ein oft genanntes Kampfsystem beschränken und die ganze Spiellogik ansonsten über die Klicks der User läuft ist PHP wohl wirklich die beste Lösung. Aber um mal AirlineSim als Beispiel zu nehmen: Über 4000 Flughäfen, mindestens 1000 Spieler pro Server, und jeder plant mit dutzenden oder sogar hunderten Maschinen (je nach Skill des Spielers) Flüge in dieser Welt, also nach einigen Wochen eine halbe oder dreiviertel Millionen Flügen in der Datenbank. Und nun müssen diese Flüge durchgeführt, abgerechnet und Passagiere darauf verteilt werden. Vor allem letzteres bereitet Kopfzerbrechen, wenn man es realistisch hinkriegen will, was wir definitiv wollen.
Ich hoffe ihr versteht was ich meine. BG ist nicht gleich BG. Wenn ich OGame entwickeln würde, würde ich mir den Stress sparen, aber ich entwickle nun mal etwas anderes

Das finde ich Interressant bzw. erschreckend. 1, irgendwas Sekunden sind ja eigentlich Welten in der Informatik. Was war den die zu erledigende Aufgabe. Man müste solche Tests auch mal mit Google vergleichen ;-) Die schaffen es offensichtlich Millionen von Anfragen in Bruchteilen von Sekunden zu beantworten, die werden aber wahrscheinlich auch nicht von IBM oder Sun beraten ;-)

Diese Reaktionszeiten waren zu erwarten. Da waren Abfragen mit einigen hunderttausend Treffern dabei, aber auch einfache Listen. Ich habe hier einfach die Mittelwerte genommen (gewichtetes Mittel nach Anzahl der Abfragehäufigkeit). Hinter dem ganzen steckt eine recht komplexe Business-Logik.
Bevor jetzt wieder einer kommt: Wir haben genau die gleichen Klassen mit genau den gleichen Funktionialitäten verwendet. Als DB-Backend wurde MaxDB eingesetzt.
Außerdem haben wir den Service wirklich massiv überlastet (5 Rechner haben im ms-takt ständig Requests losgelassen). Eine Last die wir bis heute auf inzwischen 2 moderneren Maschinen (2x Opteron) nur sehr sehr selten erreichen.

Original von Lunikon
Ich hoffe ihr versteht was ich meine. BG ist nicht gleich BG. Wenn ich OGame entwickeln würde, würde ich mir den Stress sparen, aber ich entwickle nun mal etwas anderes

Da sehe ich genau so. Es kommt immer darauf an was man machen will. Also das richtige Werkzeug für das Problem zu finden. Manchmal reicht PHP oder RoR vollkommen aus. Wenn man aber komplexere Systeme bauen will, wird es schwierig ohne .Net oder Java auszukommen. Vor allem wenn man Threads braucht sieht es bei den PHP oder Ruby schwach aus.

Threats machen bei einer Web-Applikation aber nicht wirklich Sinn, oder?

och threads kann man immer gebrauchen
mein daemon ist zb ein thread

bei mir ist der daemon ein prozess, der für jede aufgabe slave-threads hat ...
threads an sich braucht man bei "normalen" webapplikationen idr. nicht.

> Threats machen bei einer Web-Applikation aber nicht wirklich Sinn, oder?

Handler oTemplateHandler = BeginInvoke (LoadTemplates);
Handler oDatabaseHandler = BeginInvoke (ConnectToDatabase)
// Schreibe Log-Daten, etc
oDatabaseHandler.WaitForEndOperation();
// Nun führe die Datenbankaktionen aus
oTemplateHandler.WaitForEndOperation();
Handler oMailHandler = BeginInvoke (SendMails);
// Nun die Templates ausführen
echo ( Templates );
// Fertig, die Mails werden im Hintergrund versandt
Habe ich persönlich noch nie gemacht, aber wäre prinzipiell möglich...

Original von Drezil
bei mir ist der daemon ein prozess, der für jede aufgabe slave-threads hat ...
threads an sich braucht man bei "normalen" webapplikationen idr. nicht.

Was soll denn das heißen? Entweder man braucht sie, oder man braucht sie nicht. Ob das eine Webapplikation oder ein Desktopprogramm ist spielt doch dabei absolut keine Rolle? Ist wie als würde man sagen, "In Webapplikationn braucht man kein switch, geht auch mit if-else". Also irgendwie verstehe ich den Grund deiner Aussage nicht

Bei Webanwendungen braucht man Threads nicht innerhalb eines Requests, da so einer eine lineare Sache ist. Insofern ist schon richtig, das Threading für den Frontendteil nicht nötig ist (die Tatsache dass jeder Request in einem Thread läuft aussen vor gelassen).
Threads braucht man erst dann, wenn Aufgaben eben nicht linear ausgeführt werden sollen. Wie eben das Eventscheduling, welches von den linearen Abfolgen im Frontend vollkommen losgelöst ist.

Vielleicht bin ich zu sehr in dem Gedanken verhaftet, dass ich ein einzelnes File packe, das auf den Server lade und die gesamte Applikation steckt da drin. Da denk ich nicht dran, zwischen Requests und Hintergrund zu differenzieren

Ich meinte natürlich im Backend

Die Applikation wäre in deinem Fall Apache.
Du würdest die Prozesse starten, die die einzelnen aktionen ausführen. Bei ner Apache-PHP-Anwendung tut das eben der Indianer.
Vorteil: Ich muss mich nicht drum kümmern.
Nachteile hat das sicherlich auch.

Original von Kampfhoernchen
Die Applikation wäre in deinem Fall Apache.
Du würdest die Prozesse starten, die die einzelnen aktionen ausführen. Bei ner Apache-PHP-Anwendung tut das eben der Indianer.
Vorteil: Ich muss mich nicht drum kümmern.
Nachteile hat das sicherlich auch.

Wo ich gerade Apache lese: Es gibt auch Alternativen, gerade wenn es um Performance geht.
Ich habe für mein Browsergame lighttpd installiert und PHP über fastcgi angebunden, gegen die Geschwindigkeit kann Apache nicht anstinken. Skaliert auch besser.
Kann ich jedenfalls empfehlen.
Und zur Diskussion ob PHP oder JSP: Das kommt drauf an, was man machen will. Aber ich glaube, dass PHP inzwischen ganz gut mithalten kann, was die Performance angeht, aber JSP hat natürlich den Vorteil, dass es nicht bei jeden Aufruf geparsed wird, wie es ja bei PHP der Fall ist, sofern kein Accelerator eingesetzt wird.
(BTW: PHP 5.2.1 ist seit heute raus, verbraucht wieder weniger Speicher als die letzte Version...)
Gruß,
Marc

Und zur Diskussion ob PHP oder JSP

aber bitte nicht serverseitiges Java mit JSP gleichsetzen
JSP ist kurz gesagt nur EINE möglichkeit den View umzusetzen
und man kann damit Logik und darstellung vermischen

Original von duschendestroyer

Und zur Diskussion ob PHP oder JSP

aber bitte nicht serverseitiges Java mit JSP gleichsetzen
JSP ist kurz gesagt nur EINE möglichkeit den View umzusetzen
und man kann damit Logik und darstellung vermischen
Kann man. Muss man aber nicht. Kann man mit PHP übrigens auch. Muss man aber nicht.

...Ich habe für mein Browsergame lighttpd installiert und PHP über fastcgi angebunden, gegen die Geschwindigkeit kann Apache nicht anstinken. Skaliert auch besser.
Kann ich jedenfalls empfehlen...

Interessant. Muss ich mir mal vermerken. In dem Fall kannst du auch problemlos die fork-Methoden von PHP verwenden, oder ? Im Apache-Modul wird ja dringenst davon abgeraten, da das dann Unterunterprozesse wären mit unabsehbaren Folgen - soll man nur mit CGI-PHP machen.

Original von riki1512
Interessant. Muss ich mir mal vermerken. In dem Fall kannst du auch problemlos die fork-Methoden von PHP verwenden, oder ? Im Apache-Modul wird ja dringenst davon abgeraten, da das dann Unterunterprozesse wären mit unabsehbaren Folgen - soll man nur mit CGI-PHP machen.

Also die Prozesskontrollfunktionen müsste man verwenden können mit lighttpd, ich habe jedenfalls noch nichts gegenteiliges gelesen.

Original von raufaser
Also die Prozesskontrollfunktionen müsste man verwenden können mit lighttpd, ich habe jedenfalls noch nichts gegenteiliges gelesen.

Ach läuft fast-cgi auch als Modul des Webservers ? Beim Apache + Modul-PHP soll man ja nicht forken, weil das letzlich alles Unterprozesse des Apache wären, was eben unvorhersehbare Folgen soll haben können (warum auch immer). Daher soll man dies nur mit CGI-PHP tun, dachte daher, dann wird PHP als CGI als separater, eigener Prozess aufgerufen. Habe ich nie gemacht, weil galt früher als sehr lahm (immer noch?).

Original von riki1512
Ach läuft fast-cgi auch als Modul des Webservers ? Beim Apache + Modul-PHP soll man ja nicht forken, weil das letzlich alles Unterprozesse des Apache wären, was eben unvorhersehbare Folgen soll haben können (warum auch immer). Daher soll man dies nur mit CGI-PHP tun, dachte daher, dann wird PHP als CGI als separater, eigener Prozess aufgerufen. Habe ich nie gemacht, weil galt früher als sehr lahm (immer noch?).

Die PHP Prozesse laufen als Kindprozesse vom Webserver, bzw, jeder Webserverprozess hat einen eigenen PHP Prozess für das Parsen. Als ich von Apache (mit fest integriertem PHP Modul) nach lighttpd in dieser Konfiguration gewechselt habe, ist die Sache merklich ein wenig flüssiger geworden. Man sagt lighttpd aber nach, erst bei wirklich vielen Zugriffen performanter zu werden als Apache. Auf www.lighttpd.net/ gibt's mehr Infos (hoffe ich, die haben die Webseite umgestellt).
Apache mit PHP als CGI kommt mir nicht mehr ins Haus, weil dann HTTP AUTH buggy ist und das eine Funktion ist, auf die ich nicht verzichten möchte.
Ciao,
Marc