Max Query Anfragen bei einer Multiuser Platform

Stelufl

Mitglied
Moin,

ich hoffe ich bin im richtigen Board. Folgendes: Wir haben hier eine 4 Tier Architektur bestehend aus Client Tier, Application Tier, Service Tiert und Data Tier.

Wobei bei uns ein Tomcat als Application Tier eingesetzt wird.
Nun meine Frage:
Aus dem Client heraus stoße ich derzeit 500 Threads gleichzeitig an, die alle auf dem Server rödeln und der wiederum Queries über die Service Tier auf der DB ausführt.

Nun kann ich mir vorstellen, wenn 10 User 500 Threads gleichzeitig starten, macht da sicherlich irgendwann der Server nicht mehr mit. Da ich aber zum Thema Serverauslastung keinerlei Erfahrung habe, wollte ich mal fragen, "Ist so eine 'Query Flut' von 500 Threads gleichzeitig "normal" in der EE Szene oder ist das schon eher grenzwertig"?

Es handelt sich bei den Queries um kleinere Queries, die einen expand über eine bestimmte Relation auf einem Objekt ausführen ("Hole alle Elemente von Objekt X mit der Relation Y"). Das ganze ist auch in ca. 2 Sekunden abgehandelt.


Wer hat da Erfahrung?

Grüße
 
Zuletzt bearbeitet:

FArt

Top Contributor
Das kommt darauf an, was so eine "Query" bei dir alles auslöst (Prozessorlast, IO, DB Auslastung, Bandbreite, ...) und wo dann im Endeffekt der mögliche Flaschenhals liegt.
Das musst du selber monitoren.

Prinzipiell kann man aber einen Tomcat recht gut skalieren, z.B. über einen vorgeschalteten Apache Webserver als einfacher Loadbalancer.
 

schalentier

Gesperrter Benutzer
Was meinst du mit 500 Threads? Echte Threads? Dann waere das glaub ich nich besonders geschickt. Java erstellt dann 500 echte OS Thread - das ist teuer! Zudem duerfte irgendwann der Javaprozess irgendwann aussteigen, da es ein Limit fuer die maximale Anzahl an Threads gibt (die ist OS spezifisch).

Warum 500 Threads? Zumal die sowieso hoechstwahrscheinlich nacheinander ausgefuehrt werden, wenn in diesen Threads die DB abgefragt wird.
 

Stelufl

Mitglied
Hi,


ich erstelle mir aus dem Client heraus x Threads. Mittlerweile habe ich mir einen Threadpool von max 20 Threads erstellt, in dem die einzelnen Anfragen abgearbeitet werden.
Ich sage halt Thread thread = new Thread.. ist scheinbar ein echter. Der Tomcat arbeitet das zwar trotzdem sequientiell ab, jedoch hat es trotzdem gewaltige Vorteile in der Performance. Mein Gedanke war einfach dass wenn zig User in kurzem Abstand Anfragen absenden, dass der Server irgendwann abkackt. Und da ich keinen Maßstab habe, was für Server so "normal" ist, hatte ich mal gefragt.
 
M

maki

Gast
Ich sage halt Thread thread = new Thread.. ist scheinbar ein echter. Der Tomcat arbeitet das zwar trotzdem sequientiell ab, jedoch hat es trotzdem gewaltige Vorteile in der Performance.
Dir scheinen noch etliche Grundlagen zu fehlen.
"trotzdem gewaltige Vorteile in der Performance" ist einfach so dahergesagt...

Tomcat arbeitet requests nicht sequentiel ab, er hat einen ThreadPool den man konfigurieren kann ;)
 

Stelufl

Mitglied
Ja, ich bin Prakikant in der SE und natürlich fehlen mir auch Grundlagen. Vor 3 Tagen habe ich angefangen zum ersten Mal auf dem Server zu programmieren. Unser Architekt meinte, dass wir kein Scheduling haben und das daher sequentiell abgearbeitet wird (Ob auf Tomcat oder Service Layer weiß ich nun nicht genau).

Edit:
Und mit Performance meine ich einfach Laufzeit.
 

schalentier

Gesperrter Benutzer
Mh, ich versteh das mit den gewaltigen Performancevorteilen noch nicht. Wie hast du das gemessen?

Normalerweise nimmt man einen Applicationserver, damit man sich (u.a.) nicht um Threadrumgefummel kuemmern muss. Du hast im Kern Methoden, die aufgerufen werden, wenn ein Request reinkommt - wie die konkret und genau abgearbeitet werden, sollte dir als "Fachentwickler" voellig egal sein. Das kann man halt einstellen, wie maki bereits sagte.

Natuerlich kannst du dennoch Threads in einem Request erzeugen, nur duerfte das nicht viel bringen. Besonders viele, kurz laufende Threads sind (bei Java) einfach Quatsch. Selbst fuer lang laufende Prozesse sind Threads im EE Umfeld eher ungewoehnlich.

Aber das haengt natuerlich auch von der konkreten Anwendung und deren Auslastung ab. Kommen viele Requests pro Sekunde, sollte der (oder die) Applicationserver lieber einen einzelnen laenger laufenden Request in einem Thread abarbeiten und parallel andere Requests verarbeiten. Kommen nur sehr wenige Requests, die zudem oft lange rechnen muessen, koennte das anders aussehen.

Aber wieso soll der Praktikant solche Dinge entscheiden? Haben die keine "normalen" Aufgaben fuer dich, bei denen du einfach Feature XYZ implementieren oder Bug ABC fixen kannst?
 

Stelufl

Mitglied
Hio,

getestet habe ich das mit 2 Timestamps im Client. Mit Multithreading kommt am Ende halt 28% Zeitersparnis raus bzw. anstatt 28 Sekunden 20 Sekunden Ladezeit für den Dialog. Mir wurde das eigentlich auch nicht aufgetragen, das mal zu untersuchen, sondern das habe ich selber einfach mal probiert, die Anfragen mit Multithreading abzuschicken. Kann sein, dass der Tomcat selbst ein Multithreading durchführt, aber nicht der CLient. Vielleicht habe ich mich auch undeutlich oder falsch ausgedrückt: Er führte bspw. 100 Serveranfragen clientseitig sequentiell mit einer For-Schleife aus. Sprich: Anfrage senden, Ergebnis abwarten, neue Anfrage senden usw.

Und um das zu umgehen, starte ich client seitig einen bestimmten Threadpool. Diese derzeit 20 Threadpools führen dann die insgesamt 100 Anfragen sequentiell durch (Also 5 sequentielle Anfragen je Thread).

Dass der Tomcat diese Anfragen alle parallel durchführt kann ich mir schon vorstellen und deshalb resultiert das dann auch in einer besseren Performance, oder?
 

schalentier

Gesperrter Benutzer
Ok, jetzt versteh ich. Hab das irgendwie falsch gelesen und dachte, du machst auf dem Server 500 Threads auf :)

In deinem Fall wird es mit clientseitigen Thread natuerlich schneller, wenn der Tomcat auf einem Mehrkernsystem laeuft.

Wird die Flut an eingehenden Requests zu hoch, gibt es verschiedene Moeglichkeiten (Warteschlange, dedizierte Messagequeue, ...). Wie das der Tomcat genau macht kann ich aber net genau sagen.
 

Ähnliche Java Themen

Neue Themen


Oben