Design/Performance-Frage beim servlet (static oder nicht)

[TangoFan]

Hallo mal wieder, hab nun eine Design/Performance Frage. Und zwar habe ich ein Servlet welches eingehende Requests verarbeiten soll. Dabei wird in der "doGet"-Methode, eine Methode einer anderen Klasse (nenne ich hier mal "Factory") aufgerufen, der Request als Parameter übergeben und dort ausgewertet und anschliesend ein Integer zurückgeliefert.

Nun möchte ich das ganze so performant wie möglich machen da ja ein Servlet mehrere Threads gleichzeitig verarbeitet und somit diese Factory dies ebenfalls tun soll. Soll ich diese "Factory" nun als Singleton implementieren oder die Methoden einfach nur alle "static" machen, oder... ? Meine Grundidee ist halt diese das wenn die JVM nicht ständig neue Factory-Klassen anlegen muss sondern immer nur die schon vorhandene Methode aufruft, man dadurch Zeit einspart.


Bisher ist der Code so:

class Test extends javax.servlet.http.HttpServlet..... {

...

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
         int berechnet;	
	
	// leite weiter an die Methode der anderen Klasse, welche den Request nun auswertet
	Factory fac = new Factory();  // <-- hier irgendwie Zeit einsparen
         berechnet = fac.tueAuswerten (request);
}

Idee 1:

class Test extends javax.servlet.http.HttpServlet..... {

private Factory fac = new Factory();  // <-- bringt das Zeitersparnis wenn ichs Objekt hier schon anlege?
...

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
         int berechnet;	
	
	// leite weiter an die Methode der anderen Klasse, welche den Request nun auswertet
         berechnet = fac.tueAuswerten (request);
}

Idee 2:

class Test extends javax.servlet.http.HttpServlet..... {

...

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
         int berechnet;	
	
	// leite weiter an die Methode der anderen Klasse, welche den Request nun auswertet
	berechnet = Factory.tueAuswerten (request);
}  	
}


public class Factory {
..
public static int tueAuswerten(HttpServletRequest request) {
... berechnen und Wert zurückgeben

    return wert;
}
}

Jemand ne Idee was nun "schneller" sein könnte?

 

[KSG9|sebastian]

1. probiers doch aus

davor und dannach System.currentTimeMillis()


2. wird es keinen merklichen Performanceunterschied bringen

 

[TangoFan]

Mein derzeitiger Favourit ist Variante 2 mit den statischen Methoden in der Klasse. Ist das Designtechnisch überhaupt ok so oder sollte ich lieber Variante 1 nehmen?
Ist es nicht so das bei Variante 2 dann die einzelnen Requests Schlange stehen müssen um die Methode "tueAuswerten" benutzen zu können?

 

[KSG9|sebastian]

Du solltest auf jeden Fall drauf achten dass sämtliche Funktionen/Klassen thread-sicher sind (Stichwort: synchronized).

Ich bin kein Freund von static-Funktionen. Würde dir Variante 1 empfehlen.

Auf den ersten Blick ist zwar das static in Ordnung, aber:
Was passiert wenn die Factory noch 15 weitere Aufgaben bekommen welche irgendwie zusammenhängen? Dann hast du
1) lauter statische Methoden
2) statische, private Klassenvariablen
und das ist imho nicht sinnvoll.

Benutze static bei sog. Helper/Util-Klassen. Sowas wie MathUtil, RandomUtil, HtmlUtil u.s.w. Sonst würde ich grundsätzlich zu ner Klasse/nem Objekt raten.

 

[TangoFan]

Hatte vor gehabt in der Factory-Klasse noch ein paar weitere statische Methoden einzubauen welche ebenfalls zur Auswertung des Requests benutzt werden (diese Methoden werden der Reihe nach ausgeführt). Diese werden allerdings alle von der Methode "tueAuswerten" angestossen und nicht vom Servlet selber. Gibt es dann in diesem Fall auch einen Datensalat oder nur wenn die Methoden vom Servlet einzeln aufgerufen werden (wegen den Threads) ?



Simples Beispiel:

class Test extends javax.servlet.http.HttpServlet..... { 

... 

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
         int berechnet;    
    
   // leite weiter an die Methode der anderen Klasse, welche den Request nun auswertet 
   berechnet = Factory.tueAuswerten (request); 
}      
} 


public class Factory { 
.. 
public static int tueAuswerten(HttpServletRequest request) { 
... stösst hier die Berechnungen an und gibt einen End-Wert zurück 

    int a;
    int b;
    int c;    

    a = auswertung1(request);
    b = auswertung2(request);
    c = auswertung3(request);

    return a+b+c; 
} 


public static int auswertung1(HttpServletRequest request)
{
   .. tue was
   return berechnet;
}

public static int auswertung2(HttpServletRequest request)
{
   .. tue was
   return berechnet;
}

public static int auswertung3(HttpServletRequest request)
{
   .. tue was
   return berechnet;
}


}

 

[KSG9|sebastian]

wie ich schon geschrieben hab:

Nimm ne Klasse, erzeug n Objekt und durchlauf die (synchronisierten) Methoden. In deinem Fall macht es wahrscheinlich nicht viel Unterschied, aber ich bin halt kein Freund von static

 

[miketech]

Hi,

also von static halte ich auch nicht sonderlich viel. Du musst Dir halt auch überlegen: Wenn du statische Methoden, oder das Muster Singleton verwendest, arbeiten alle Anfragen auf demselben Objekt. D.h. dass die Werte von Anfrage X zum Zeitpunkt t, auch in Anfrage Y zum Zeitpunkt t+1 noch gültig sind.

Ist die Frage, ob Du das überhaupt möchtest, dass Variablen, die in X gesetzt werden noch den Wert haben sollen, wenn Y bearbeitet wird.

Ansonsten würde ich zum Singleton, oder Idee1 raten, weils einfach "schöner" ist, als zig statische Methoden.

Ob nun Singleton, oder eine lokale Instanz Deiner Klasse ist auch wieder ne logische Frage: Willst Du, dass von Deiner Factory nur eine Instanz existieren darf? Also auch, wenn Du z.B. die Factory außerhalb des Servlets verwenden willst? Oder ist das jetzt nur für das Servlet gedacht? Wenn Du von der Logik her wirklich nur eine Instanz haben möchtest, dann wähle das Singleton.

Wenn Du aber nur im Falle vom Servlet nur eine Instanz nutzen möchtest, später aber vielleicht weitere Instanz erstellt werden sollen, geht Singleton natürlich nicht. Dann ist der unter Idee 1 gepostete Code vielleicht besser. Aber das ist nur meine Meinung als jemand, der noch nicht viel mit Servlets gemacht hat

Gruß

Mike

 

[TangoFan]

Gut dann verwerfe ich die Idee mit dem Static und benutze nur eine normale Klasse welche ich als Instanzvariable anlege. Viele dank für eure Hilfe!!

 

[miketech]

Was mich persönlich ja grad noch interessieren würde:

Was macht der Servlet Container mit dem Servlet? Wieviele Instanzen erzeugt er denn davon? Benutzt er immer nur eine Instanz? Oder legt er selbst mehrere Instanzen vom Servlet an, je nachdem, wieviele Anfragen kommen?

Dann würde die lokale Instanz der Factory-Klasse ja auch dazu führen, dass mehrere Instanzen erzeugt werden. Zwar nicht soviele, wie wenn bei jedem Request eine Instanz erzeugt werden würde, aber jedenfalls mehr als eine.

Gruß

Mike

 

[TangoFan]

@miketech
Mir gings halt darum was nun performanter ist in einer Multithreading-Umgebung. Also das ständige neue anlegen einer neuen Instanz von "Factory" (wie in Idee 1) oder aber eine statische Factory zu benutzen, welche schon vorhanden ist aber halt die Requests dort in ner Schlange stehen müssen um abgearbeitet werden zu können.

 

[miketech]

Hi,

ja schon klar. Aber verwendet der Servlet Container eine bereits erstellte Instanz vom Servlet nochmal und hält sie im Speicher, bis sie wieder gebraucht wird? Oder verwirft er diese nach der Verwendung und erzeugt jedes mal eine neue Instanz vom Servlet?

Gruß

Mike

 

[TangoFan]

Das Servlet erzeugt (hoffe ich irre mich jetzt nicht) jedesmal eine neue Instanz wenn ein neuer Request auf dem Server eintrifft und explizit dieses Servlet benötigt.

 

[miketech]

Ok, danke. Würde auch Sinn machen, da ja auch lokale Variablen usw. wieder zurückgesetzt werden müssen.

Also dann: Singleton, wenn wirklich nur eine Instanz existieren soll, ansonsten Instanz anlegen

Gruß

Mike

 

[miketech]

Nochmal ganz kurz: So ganz scheint das doch nicht zu stimmen, mit der Instanz:

http://www.galileocomputing.de/open...sel17_016.htm#Rxx747java17016040006BA1F02410E

Vielleicht ist das ja für Dich interessant. Offensichtlich wird nämlich die init()-Methode nur einmal aufgerufen, wenn eine Instanz erzeugt wird und dann mehrmals die service()-Methode aufgerufen.

D.h. Du könntest wie in dem Beispiel eine statische Variable mit Deiner Factory belegen. Die Belegung nimmst Du in der init() Methode vor. Und später kannst Du die statische Variable jederzeit verwenden und Deine Methoden aufrufen.

Gruß

Mike

 

[TangoFan]

Versteh ich grad nicht ganz. Kannst du mein Beispiel mal kurz so umcoden wie du es meinst?

 

[miketech]

Hi,

also Du hast Dein Servlet und dort die init-Methode:

  static Factory fac;
  public void init()
  {
    synchronized ( Factory.class ) {
      if ( fac == null )
      fac = new Factory();
    }
  }

Und dann kannst in den doGet und doPost Methoden fac verwenden:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
   int berechnet;
   berechnet = fac.tueAuswerten (request);
}

Dann hast eine statische Variable in Deinem Servlet, die einmalig gesetzt wird, d.h. Du hast für alle Instanzen des Servlets nur eine Instanz von Factory, ohne dass Factory nur statische Methoden hat, oder ein Singleton sein muss.


Gruß

Mike

 

[TangoFan]

Danke für dein Beispiel!

Wie ist das dann wenn nun mehrere Threads auf diese static-Factory zugreifen wollen. Können diese das gleichzeitig tun, oder muss jeder Thread warten bis der vorherige Thread fertig ist? Könnte die Factory somit zum Flaschenhals werden in Punkto Performance?

 

[HLX]

Servlets werden vom Servlet-Container verwaltet und oft nur 1x erzeugt bzw. der Servlet-Container entscheidet je nach Last, wieviele Instanzen eines Servlets erforderlich sind.

Meist ist jedoch nur 1 Instanz vorhanden. Diese wird im Falle mehreren Benutzern vom Servlet-Container über unterschiedliche Threads angesprochen. Hier brauchst du dich also nicht um Thread-Issues zu kümmern.

Bei eigenen Klassen, wie deiner Factory wird es allerdings kriminell. Hier solltest du tatsächlich über 1 Instanz pro Request, oder je Session nachdenken, denn alle Threads verwenden die eine Instanz deines vorhandenen Singleton.

 

[HLX]

Danke für dein Beispiel!

Wie ist das dann wenn nun mehrere Threads auf diese static-Factory zugreifen wollen. Können diese das gleichzeitig tun, oder muss jeder Thread warten bis der vorherige Thread fertig ist? Könnte die Factory somit zum Flaschenhals werden in Punkto Performance?

1. Bei synchronized warten Threads aufeinander
2. Bei vielen Anwendern entsteht natürlich ein Flaschenhals - schonmal versucht ein Kamel durch ein Nadelöhr zu ziehen?
3. Es ist unschön
4. Es ist fehleranfällig

Was spricht gegen mehrere Instanzen einer Klasse? Bei Session-bezogenen Instanzen könntest du z.B. zwei aufeinanderfolgende Requests eines Benutzers gegeneinander auswerten = viel mächtiger als die Singleton-Lösung.

 

[TangoFan]

Bei Session-bezogenen Instanzen könntest du z.B. zwei aufeinanderfolgende Requests eines Benutzers gegeneinander auswerten = viel mächtiger als die Singleton-Lösung.

Kannst mir das mal bitte erklären (ein Beispiel wäre schön) ?

 

[HLX]

Du hängst die Instanz von deinem Auswerter an die Session des Benutzers.

Auswerter ausw = (Auswerter)request.getSession().getAttribute("nameAuswerter");
if(ausw==null) {
     ausw = new Auswerter();
}     
ausw.doSomething(request); // hier können Informationen in Instanzvariablen gespeichert werden
request.getSession().setAttribute("nameAuswerter", ausw);

Werte in Instanzvariablen sind beim nächsten Request des Benutzers wieder verfügbar.

 

[Ralf Ueberfuhr]

Ich verstehe euer Problem mit den statischen Methoden nicht. Wenn die Methoden untereinander keinen Zusammenhang haben, sondern die Factory nur eine Sammlung von Hilfsmethoden ist (wie Math), dann mach die Methoden statisch. Setze auch kein synchronized, denn dann hättest du keine parallele Abfrageverarbeitung mehr.

Übrigens wird nur eine Instanz deines Servlets erzeugt, die service()-Methode (doGet, doPost...) aber multithreaded aufgerufen.

 

[miketech]

Hi,

aber er kann doch nicht einfach das synchronized weglassen? Das ginge nur, wenn die Methoden keine Membervariablen verändern, sprich es einfach nur Methoden sind, die nur auf Variablen operieren, die ausschließlich innerhalb der Methode gültig sind.


Ansonsten: Wie gesagt habe ich das ganze dem Buch entnommen und dort wird das dafür verwendet, um eine Datenbankverbindung herzustellen und zu verhindern, dass diese bei jedem Request erneut aufgebaut werden muss.

Ist die Frage, inwiefern sich das von Factory unterschiedet. Denn theoretisch hat die Datenbankverbindung ja auch das Problem, dass sie synchronisiert werden muss, oder?

Oder ist es hier einfach so, dass man sagt: Die Synchronisation ist weniger aufwändig, als die ständige Erstellung einer Datenbankverbindung?

Wie schon vorher gesagt: Das eignet sich wirklich nur dafür, wenn man wirklich nur eine Instanz davon haben möchte(!). Man muss ja immer bedenken, dass die Inhalte der Factory (lokale Variablen) erhalten bleiben. Aber in diesem Fall scheinen es nur Methoden zu sein, die keinerlei lokale Werte verändern.


Vielleicht kann man es so zusammenfassen:

Wenn die Factory-Methoden keine Variablen der Klasse verändern, sondern jede Methode nur Variablen ändert, die ausschließlich innerhalb der jeweiligen Methode gültig sind, kann man auf das synchronized verzichten. Dann erreicht man auch mit statischen Methoden, oder einem Singleton (hier muss man nur die getInstance Methode synchronisieren(?)) parallele Ausführbarkeit.

Falls die Methode aber auch auf andere Variablen zugreift und somit eine Synchronisation nötig wäre ist es vielleicht besser mit jedem Request eine Instanz zu erzeugen. Dadurch steigt zwar der Speicherverbrauch, aber die Ausführungsgeschwindigkeit wird deutlich erhöht.

Der Speicher wird ja auch wieder freigegeben.

Gruß

Mike

 

[TangoFan]

Du hängst die Instanz von deinem Auswerter an die Session des Benutzers.

Auswerter ausw = (Auswerter)request.getSession().getAttribute("nameAuswerter");
if(ausw==null) {
     ausw = new Auswerter();
}     
ausw.doSomething(request); // hier können Informationen in Instanzvariablen gespeichert werden
request.getSession().setAttribute("nameAuswerter", ausw);

Werte in Instanzvariablen sind beim nächsten Request des Benutzers wieder verfügbar.

Vielen dank für dieses Beispiel. Ist dies ein Design-Muster (so wie das Singleton) - also gibts dafür irgendeine technische Bezeichnung oder Erklärung?

 

[TangoFan]

Wenn die Factory-Methoden keine Variablen der Klasse verändern, sondern jede Methode nur Variablen ändert, die ausschließlich innerhalb der jeweiligen Methode gültig sind, kann man auf das synchronized verzichten. Dann erreicht man auch mit statischen Methoden, oder einem Singleton (hier muss man nur die getInstance Methode synchronisieren(?)) parallele Ausführbarkeit.

Hm ich hab gedacht mit Singleton und statischen Methoden ist parallele Ausführbarkeit nicht möglich da es davon nur eine einzige Instanz gibt welche nicht vervielfacht wird. Oder lieg ich da gerade falsch?

 

[miketech]

Hi,

eine parallele Ausführung ist prinzipiell schon möglich. Das Problem existiert dann, wenn mehrere Threads auf gemeinsame Ressourcen zugreifen. Damit Du hier keine Probleme bekommst, verhinderst Du mit synchronized den gleichzeitigen Zugriff, d.h. die Threads warten, bis die Ressource frei ist, dann schnappt sich einer die Ressource und die anderen warten weiterhin. D.h. wenn Du synchronized verwendest ist die Parallelität etwas eingeschränkt, da die Threads teilweise aufeinander warten müssen.

Wie gesagt ist das Problem, wenn Du auf gemeinsame Ressourcen, also Variablen zugreifen willst.

private int a1;

public void myMethod1() {
  a1+=1;
}

public void myMethod2() {
  int a2 = 0;
  a2 += 1;
}

Würden mehrere Threads gleichzeitig myMethod1 aufrufen hättest Du das Problem, dass mehrere versuchen werden, auf die gleiche Variable zu schreiben.

Bei myMethod2 ist es aber so, dass die lokale Variable a2 nur für einen Thread sichtbar ist. D.h. jeder Thread wird eine Variable a2 erzeugen, die er alleine verwendet. Hier kommt es also zu keinen Konflikten.


Daher habe ich die parallele Ausführbarkeit auch darauf beschränkt, dass die Methoden nur lokale Variablen und keine Variablen der Klasse o.ä. verändern dürfen. Ansonsten musst Du Dich auch um die Synchronisierung der Threads kümmern, wodurch es wieder zu Einbußen in der parallelen Ausführung kommt.


Gruß

Mike

 

[TangoFan]

Morgen!

Das heisst also Singleton und Statische Methoden können also schon Parallel ausgeführt werden, allerdings sollten diese dann gemeinsame Klassenvariablen benutzen, dann muss man auf Synchronisation achten.

Somit könnte ich doch die Factory in ein Singleton verwandeln und dieses einmalig als Instanzvariable instantiieren in der Hauptklasse. Die Methoden in der Singleton arbeiten voneinander unabhängig und benutzen keine gemeinsame Datenstruktur.

Wäre diese Singleton-Variante nun schneller als die Variante mit der Factory, welche jedesmal erzeugt wird wenn jemand auf "doGet" zugreift?

 

[HLX]

Vielen dank für dieses Beispiel. Ist dies ein Design-Muster (so wie das Singleton) - also gibts dafür irgendeine technische Bezeichnung oder Erklärung?

Keine Ahnung. Es ist auf jeden Fall kein Geheimnis.

Wäre diese Singleton-Variante nun schneller als die Variante mit der Factory, welche jedesmal erzeugt wird wenn jemand auf "doGet" zugreift?

Wenn wir hier von merkbaren Geschwindigkeitsunterschieden reden wollen, dann muss schon eine größere Menge Benutzer gleichzeitig auf die Anwendung zugreifen. In dem Fall wird das Singleton zum Flaschenhals.

Der Vorteil von Singletons liegt im geringeren Speicherverbrauch. Wenn nicht ausreichend Speicherressourcen zur Verfügung stehen, dann ist das eine Alternative. Singletons sollten im Allgemeinen als Alternative und nicht als Default betrachtet werden.

 

[miketech]

Wieso wird das Singleton dann zum Flaschenhals? Aber nur wegen der getInstance - Methode, die synchronisiert werden muss, oder? Wenn er die anderen Methoden, die aufgerufen werden nicht synchronisieren muss, dann wird das ja auch nicht unbedingt zum Flaschenhals.

Gruß

Mike

 

[HLX]

Wenn nun eine größere Menge Benutzer gleichzeitig getInstance() aufruft, dann wird das Singleton zum Flaschenhals. Damit dies einen signifikanten Performance-Nachteil darstellt, muss sich schon eine gewisse Benutzergemeinde zusammenrotten und die Seite oft frequentiert werden. Von daher wird das wahrscheinlich kein echtes Problem sein. Es sollte jedoch klar sein, das Singletons nicht wg. der Geschwindigkeit gewählt werden sollten sondern aus "Platzgründen".

Und man sollte sich im klaren darüber sein, dass Singletons die Anwendung unflexibel machen können. Sollte die Geschichte mal erweitert werden, muss man evtl. alles umbiegen. Wenn die Web-Seite irgendwann mal oft und stark frequentiert wird ist man vielleicht ebenfalls unglücklich mit der Lösung. Daher sollte man sich überlegen, ob es trifftige Gründe für ein Singleton gibt - Platzbedarf gegen Performance abwiegen, Erweiterungsmöglichkeiten checken.

Übrigens (nur am Rande): Irgendwann kommt ja scheinbar jeder mal auf den EJB-Trichter. Bei SessionBeans ist soweit ich weiß "static" verboten.

 

[AlArenal]

Ein Singleton sollte auch nicht aus "Platzgründen" als Pattern gewählt werden, sondern aus Gründen, die sich auis spezifischen Anforderungen ans OO-Design ergeben. Es geht beim Singleton nicht um Ressourcenverbrauch, sondern um Verantwortlichkeit.

 

[miketech]

Hi,

yup, dass das Singleton weniger Speicher benötigt ist ein Nebeneffekt.

Aber klar: Singleton nur, wenn man das von der Logik her überhaupt möchte. Falls man kein Singleton möchte bleibt ja noch die Variante übrig, die ich vorher gepostet habe, wenn man nicht jedes mal eine neue Instanz erzeugen möchte. Dann hat man eine statische Klassenvariable, die eine Instanz zur Factory erhält und die kann man dann verwenden.

Man muss das noch nichtmal unbedingt statisch machen. Hätte halt nur den Vorteil, dass man die Instanz in allen Instanzen des Servlets verwenden kann.

Ich glaube wir sind uns hier alle ziemlich einig, was wann wie gut ist Es ist einfach nur eine Frage: Was möchte man haben?

Gruß

Mike

 

[HLX]

Das stimmt! Die Aussage bezog sich auch eigentlich auf die Performance-Sichtweise (Zeit/Speicherbedarf). Habe ich schlecht formuliert. Mea Culpa!

 

[Terminator]

Also Singleton funzen bestimmt, ausser man müsste über mehrere JVM hinweg was synchronisieren.
Trotzdem verwende ich hauptsächlich statische Methoden, find ich einfacher und schöner.

Bleibt die Frage was da problematisch sein soll -> gemeinsm genutzte Resourcen.
Hm - sind doch hauptsächlich die Session Objekte (sofern man keine eigenen Threads startet)

Allerdings wie will man das überhaupt richtig synchronisieren.
Also hab mich da noch nicht reingearbeitet, aber mein Kenntnisse von Synchronisation:
1. Nur ein Thread darf in den Block rein
2. Andere warten bis er fertig ist
3. Keine Sperre des Objekts selbst

So nun greift man aber auch in JSP Seiten selbst mit JSTL/EL oder was auch immer auf diese Objekte zu.
Um da wirklich ne konsistente Sicht zu bekommen, wärs ja dann nötig den Block bis letzten Zugriff auf das Objekt zu synchronisieren.
Also von ersten Zugriff in Java Klassen bis in letzten Zugriff in JSP Seiten.
Das kanns ja nicht sein, würde ja bedeuten kann gleich den ganzen Request synchronisieren!

 

[puddah]

So wie es aussieht greifst du in deiner Factory Klasse auf keine statischen Attribute zu, richtig? Dann ist es überhaupt kein Problem statische Methoden zu benutzen. Du hast ja keine Daten, die durch einen anderen Thread manipuliert werden können.

EDIT: Oh sorry, das wurde bereits gesagt. Ich sollte vielleicht vor dem Posten die Threads zu ende lesen.

 

[TangoFan]

Schon ok, freue mich über jede Antwort. Man lernt hier nie aus!
Danke an alle!!