Tomcat vs. JEE-Server

[der globus]

Hallo,

derzeit plane ich die Entwicklung eines Community-Portals und mache mir konkrete Gedanken über geeignete Plattformen. Da ich während meines Studiums ebenso wie nebenberuflich fast ausschließlich Java programmiert habe, sollte es auch diese Sprache sein. Allerdings habe ich keine Erfahrungen bezüglich Performance und Skalierbarkeit in diesem Umfeld. Ist es in diesem Hinblick eher sinnvoll einen „einfachen“ Tomcat in Kombination mit Hibernate einzusetzen oder bietet sich ein vollwertiger JEE-Server eher an? Letztgenannten stelle ich mir eher überladen und somit langsamer vor.

Im Rahmen des Portals soll keine großartige Business-Logik auf dem Server laufen. Vielmehr stellen die Servlets recht einfach gehaltene Schnittstellen zur Datenbank dar. Macht es Sinn die Datenbank „direkt“ aus den Servlets anzusprechen oder, im Falle eines JEE-Servers, eine Stateless-EJB dazwischen zu benutzen? Insbesondere gehts dabei um Lastenverteilung für den Fall, dass das Community-Portal überraschend gut läuft.

Vielen Dank und viele Grüße aus Hamburg. Stefan

[marc9022]

Hi Stefan,

Hallo,
derzeit plane ich die Entwicklung eines Community-Portals und mache mir konkrete Gedanken über geeignete Plattformen. Da ich während meines Studiums ebenso wie nebenberuflich fast ausschließlich Java programmiert habe, sollte es auch diese Sprache sein.

Willkommen im Club, ich arbeite in meiner Freizeit ebenfalls an einem solchen System, dass verblüffend passend auf deine Beschreibung zutrifft ;d

Zum Thema:
Um deine Frage zur Wahl der Sprache, nebst zugehöriger Runtime zu beantworten. Ja, Du liegst absolut richtig, b.z.w es gibt kaum ein Development
Entvironment das die Needs die Du beschreiben hast besser unterstützt.
Das konnte ich während einzelner Projekten immer weider festellen, so daß
ich mich, ohne es je zu bereuen mit Java auf dem Server sehr gut
arrangieren konnte und es nie wirklich bereut habe.

Allerdings habe ich keine Erfahrungen bezüglich Performance und Skalierbarkeit in diesem Umfeld. Ist es in diesem Hinblick eher sinnvoll einen „einfachen“ Tomcat in Kombination mit Hibernate einzusetzen oder bietet sich ein vollwertiger JEE-Server eher an?

Nun ja, dass kommt drauf an was dein Portal alles bieten soll.
Wenn wirklich "alles" via HTTP laufen soll und Du keine Remote API's
(z.B SOAP RPC oder Chatt Applet mittels Flash/Java Applet anbinden willst,
dann macht Tomcat auf jeden Fall Sinn. Zu Hibernate kann ich Dir nicht
viel sagen, da ich es nicht einsetze, weil ich Persistenzmapper nicht
wirklich für sinnvoll halte (egal ob nun CMP, Hibernate oder JDO oder SQLJ).
Oftmals versprechen sie nur vorgeblich eine Versimplifizierung, in der
Praxis kann es jedoch gerade bei der Datenbankoptimierung zu einem
Störfaktor oder gar zu einem ernsthaften Problem werden wenn man die
absolute Kontrolle über die DB Performance behalten will und darauf
kommt es meiner Meinung nach bei einer umfangreichen WebApplikation
am meisten an!

Letztgenannten stelle ich mir eher überladen und somit langsamer vor.
Im Rahmen des Portals soll keine großartige Business-Logik auf dem Server laufen. Vielmehr stellen die Servlets recht einfach gehaltene Schnittstellen zur Datenbank dar.

Die J EE Spezifikation 5 (und darunter solltest Du Dich wirklich nicht bewegen, weil sie viele Vereinfachungen und nützliche Goodies beinhaltet) bietet Dir ja einen reichhaltigen Stack an Technologien und Best Practices an die Du sicher nicht alle benötigen wirst ;D Tomcat ist ja nur ein Baustein aus J2EE/ J EE 5
(aktuell) aber bildet eben nicht den ganzen normierten Stack ab.

Es ist jedoch in der Regel fast nie ein Problem erstmal mit Tomcat loß zu legen
und bei Bedarf dann später die die anderen J EE Stacktechnologien nachzurüsten, so sie denn benötigt werden (ich schätze mal einen CORBA
Connector oder oder eine SOAP RPC Schnittstelle für Webservices wirst
Du nicht wirklich gleich am Anfang brauchen

Da die Frage nach "kompletten" J2EE / J EE 5 AppServern bei Dir aufkam, will
ich noch kurz darauf eingehen. Es ist meiner Meinung nach sehr wichtig
für welchen AppServer Anbieter man sich letztendlich entscheidet.
Am meisten vertreten im komerziellen Umfeld sind mit Sicherheit IBM's
Websphere / BEA-WebLogic und der ORACLE OC4J Server sowie die
OpenSource Pedants Apache Geronimo, SUN-GlassFish und JBoss.

GlassFish ist noch recht neu, ist jedoch fest mit NetBeans verdrahtet und
man hat hier alle Produktivitätsvorteile auf seiner Seite (mit Tomcat
standalone allerdings auch). Wenn Du eher mit Eclipse oder IntelliJ
IDEA programmieren willst, bietet sich hingegen eher Apache Geronimo an
oder JBoss an. Anmerkung zu JBoss: Apache ist in der J2EE/J EE 5 World
der Featureprovider schlechthin. Tomcat, sowie viele andere Apache Tools
sind im JBoss verbaut, JBoss selber gehört jedoch nun Redhat, die
einige Komponenten aber in Zulunft unter Verschluss gegen Lizengebüren
halten wollen, weshalb ich mich Apache Geronimo zugewandt habe.

Apache Geronimo ist eigentlich nur der längst überfällige Schritt der
Apache Foundation die ganzen großartigen Einzelprojekte wie z.B
Tomcat, Derby, ANT, OpenEJB, Maven, AXIS u.s.w in einen Server
J2EE/ JEE 5 Server zusammen zu fassen. Interressant ist hier wohl auch die
Option Geronimo im Smalsizemode zu betreiben, der es gestattet das
eigentlich nur Tomcat und wahlweise andere Module aufzuschalten,
so wie es benötigt wird ;D Du kannst dann später immer noch hergehen und
im laufenden Betrieb andere Module on the Fly zu aktivieren.

Macht es Sinn die Datenbank „direkt“ aus den Servlets anzusprechen oder, im Falle eines JEE-Servers, eine Stateless-EJB dazwischen zu benutzen?

Direkt aus einem Servlet macht es wirklich gar keinen Sinn, im Gegenteil, damit
fängt man sich schon das eine oder andere Problem ein ;D Sinnvoll
im Zusammenhang mit Tomcat ist eigentlich fast immer eine JNDI Datasource
zu definieren die mittels Apache DBCP eingebunden wird (ist bei den
neuerem Tomcat Releases sowieso das Standard DB Interface.

Insbesondere gehts dabei um Lastenverteilung für den Fall, dass das Community-Portal überraschend gut läuft.
Vielen Dank und viele Grüße aus Hamburg. Stefan

Für den Fall ist Tomcat Standalone oder als Teil eines J EE 5 Server wie
Geronimo, JBoss oder GlassFish eigentlich Ideal.

Eine bewährte Herrangehensweise WebApplikationen im J EE Umfeld zu
bauen ist IMHO der Weg, verschiedene, funktionale Säulen aufzubauen, die
getrennt voneinander lauffähig sind (z.B Suche kann deaktiviert werden,
Instant Message System bleibt davon aber unberührt).

Kleiner Hinweis noch zur DB. Die meiste Zeit wird deine WebApplikation
darauf warten dass sie Daten aus der DB angeliefert oder geinsertet
werden. Diesbezüglich kann ich Dir eigentlich nur folgende Empfehlungen
geben, die über Erfolg und Mißerfolg bei Hightraffic Websits entscheiden können.

1)
Nutze ein geeignetes SQL-Datenbanksystem
z.B:
PostgreSQL ab Vers. 8.x oder höher (OpenSource BSD Lizenz)

ORACLE Express (kostenlos nutzbar, upgradebar auf die grosse Version)
IBM-DB2 Express (kostenlos nutzbar, upgradebar auf die grosse Version)
Achtung: Beide haben Featureeinschränkungen, DB's können nicht beliebig
groß werden oder sind beim RAM b.z.w Anzahl der CPU's eingeschränkt!)
SYBASE ASE (nicht so gängig aber gute Datenbank)

keinesfalls:
MySQL, SQLLite, Derby, Firebird/Interbase, ADABAS D,/ SAPDB, MAXDB oder
MS-SQL! Klar lassen auch die sich via JDBC anbinden, ist aber ganz sicher
nicht zu empfehlen!

2)
Last vom DB Server nehmen!
Jede Connection die nicht aufgebaut werden muss ist gut!
Verwende unbedingt einen Connectionpooler. Die meisten J EE Server
haben einen derartigen Mechanismus, Tomcat Standalone auch (DBCP)
schicke nur Daten zum DB Server wenns nicht anders geht.

2)
Benutze Prepared Statements statt CREATE STATEMENT und Co, denn
jede "neue" SQL-Abfrage die der Query Optimizer des DB-Servers nicht
"kennt" muss erneut "dynamisch" analyisert und optimiert werden,
was Performance frisst. Darüber hinnaus vermeidest Du schon hier
potentielle Sicherheitsprobleme wie SQL-Injections als positiven Nebeneffekt.

3)
Verarbeite bereits auf der DB was auf der DB verarbeitet werden kann.
JDBC arbeitet Mengenorientiert. Soll heissen, wenn Du eine Query abfeuerst
liefert sie dir entweder keine oder die gewünschte oder eine grausame
Charzahl als Antwort. Im Endeffekt muss JDBC ein Array im Speicher anlegen
und mit der der Ergebnismenge Zwischenpuffern. Wenn nun eine JDBC-Query
auf das Ergebis einer anderen "JDBC-Query" warten muss, muss dafür
immer besagtes Array dynamisch im Speicher zugewiesen werden.
Um das zu verhinden kannst Du z.B auf ORACLE mittels SQL Plus einen
sogenannten anonymen Block definieren der Entscheidungen auf Ergebnismengenbasis auf der DB selbst fällt und nur das tatsächliche
"nutzdaten" Mengen Array zurückliefert und nicht nur Teilergebisse.

4)
Versuche Antwortmengen von SQL-Abfragen generell klein zu halten.
5)
Riesige Tabellen (über 400 GByte) sollten mittels Partitioning aufgeteilt werden.
Hier zeigen die grossen ORACLE und DB/2 Versionen Ihre Stärken (ist nicht billig)! aber auch PostgreSQL unterstützt dieses Highend Feature mittlerweile.

Hinweis Partitioning:
Bei sehr großen Tabellen werden die Suchanfragen natürlich länger.
Partitioning beugt dem dahingehend vor, dass es die Tabelle selbst
in logische Units, definierter grösse aufsplitten kann. Partitionen können
dann parallelisiert durchsucht werden. Wird der gesuchte Wert in irgend
einer Partition gefunden ist die Suche zu Ende.

5)
Datenbankkodierung:
Benutze UTF-8 oder Unicode, aber auf keinen Fall ASCII SQL, das ist
kein richtiges Encoding!

6)
DB-Server Hardware:
Überlege Dir eine eigene Maschine beim Provider als DB-Host anzumieten
wo die Möglichkeit besteht das der Webserver und DB-Server sich im
Provider LAN austauschen können.

7)
DB-Server Ausstattung:
1 bis 4-8 GByte RAM, am besten AMD Opteron Multicores HE oder Barcelona CPU's (solche Server gibts z.B bei Strato) Warum? Diese Opterons unterstützen Hardwareloadbalancing, die CPU-Cores schieben sich also
je nach Loadsituation die zu verarbeitenden Daten hin und her.

8)
DB-Server OS sollte 64-Bit sein (PostgreSQL lässt sich 64-Bit Übersetzen)

So, dass sollte fürs erste reichen ;d
Gruß Marc

[mavo]

Danke für sehr interessante Infos!