Larry Ratlos: Application Server und die Performance ...

Larry kommt aus seinem wohlverdienten Urlaub zurück und wird auch schon dringend erwartet. Seine Kollegen kämpfen mit einem Performance-Problem und hoffen nun, dass Larry, so frisch erholt, die zündende Idee zur Lösung findet.

"Ist ja wieder typisch", denkt Larry. "Kaum bin ich aus dem Urlaub zurück, warten auch schon wieder die nächsten Probleme auf mich. Kann ich nicht ein einziges Mal zurückkommen und einen ruhigen ersten Tag verbringen???"

Ein wenig resigniert ergibt er sich seinem "Schicksal" und hört sich an, was seine Kollegen zu berichten haben: Im Firmenarchiv läuft seit einiger Zeit eine kom­plett neue Server-Anwendung mit J2EE Technologie. Diese arbeitet im Application Server (AS) JBoss. Sie hat allerdings ein gravierendes Performance-Problem, nämlich extrem lan­ge Antwortzeiten für Recherchen in den Archiv­beständen.

Seine Kollegen haben bereits festgestellt, dass eine Stateless-SessionBean "FooBean" vorliegt. Sie arbeitet mit der Methode "Object doStuff()". Jetzt stellt sich Larry also die Frage, ob das Problem im Netzwerk oder in der Business-Logik liegt?

Der Zeitrahmen ist wie immer eng, denn in 2 Wochen ist Ferienende und das System muss wieder die volle Last tragen. Aber bekanntlich kommt vor der Lösung immer die Analyse des Problems. In einer Woche soll daher eine Statistik der vergangenen Tage vorliegen, die auf folgenden Werten basiert:

1. Wie lange muss der Client auf die jeweilige Methode warten?
2. Wie lange dauerte die Verarbeitung im AS (Methoden-Start bis Methoden-Ende)?
3. Wie groß ist die Differenz zwischen der Wartezeit des Clients und der Verarbeitungszeit im AS? (Ergeben sich daraus Rückschlüsse auf Ursachen im Netzwerk?)

Die statistische Auswertung soll im CSV-Format erfolgen und folgende Daten enthalten:

1. Datum in "YYYYMMDDhhmmss"
2. Wartezeit des Clients in ms
3. Verarbeitungszeit im AS in ms
4. Differenz aus 2. und 3.

Larry sucht nun nach einem Lösungsansatz für JBoss unter Nutzung von Interceptoren und Log4J. Auch alternative Lösungen (z. B. für andere AS) wären ihm willkommen - möglicherweise wären die ja übertragbar ...

Larry fängt also an, zu grübeln. Da fällt ihm plötzlich ein: Aus lizenzrechtlichen Gründen ;-) darf er die Session­Bean und den Client-Code nicht verändern! - Das macht es ihm natürlich nicht gerade leichter.

Larry ist ratlos. Können Sie ihm helfen?

Senden Sie Ihre Lösung, wie Larry seine Statistik am besten und schnellsten erstellen kann, bis zum 15. Oktober 2005 an kniffel@ordix.de. Wie immer wird sich Larry mit einer kleinen Aufmerksamkeit bei seinen Helfern bedanken und einige der eingesandten Lösungen veröffentlichen.

Die Lösung des Rätsels aus der ORDIX News 2/2005

In der letzten Ausgabe der ORDIX News hatte Larry mit einem etwas "widerspenstigen Oracle" zu tun. Geholfen haben ihm vor allem die Lösungen unserer Leser: Hubert Weyers, Frank Husar und Tim Hensel konnten jeweils zumindest die meisten der möglichen Ursachen ausmachen. Dafür nochmals vielen Dank!

Nachdem er alle Hinweise der Leser zusammengetragen hat, weiß Larry, dass es zahlreiche Einschränkungen für die Maximale I/O-Größe gibt. Dabei greift immer die jeweils erste Restriktion:

• MAX_IO_SIZE: Ein Oracle Prozess kann niemals mehr Daten mit einem I/O lesen als das darunter liegende I/O-System. Der Kernel-Parameter MAX_IO_SIZE bestimmt die maximale I/O-Größe bei vielen Unix-Derivaten.
• Blöcke im Buffer: Der Leseprozess überprüft, ob in den nächsten zu lesenden Blöcken bereits ein Block im Hauptspeicher liegt. Ist dies der Fall, liest der Prozess mit dem nächsten I/O nur die noch nicht im Speicher vorhandenen Blöcke.
• Extent Grenzen: Es wird maximal bis zur Grenze von Extents, sowie bis zu speziellen Blöcken wie Segment Header und Bitmap Free Lists gelesen.
• DB Block Buffer / 4: Eine eher theoretische Grenze für den Wert des Parameters ist die Anzahl der Blöcke im Default Block Buffer, geteilt durch 4.
• SSTIOMAX: Für die Oracle Versionen 7 und 8 ist der Parameter dfmrc durch die interne Konstante sstiomax beschränkt.

Seitenanfang

Seite drucken

Seite weiterempfehlen