![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Empfohlene Methoden für die Konfiguration von Warteschlangen
Es gibt eine Methodik für die Konfiguration von Warteschlangen für WebSphere Application Server. Die Dynamik eines individuellen Systems kann durch das Verschieben und Ändern von Ressourcen drastisch beeinflusst werden. Sie könnten beispielsweise den Datenbankserver auf eine andere Maschine verschieben oder leistungsfähigere Ressourcen wie schnellere CPUs mit mehr Speicher bereitstellen.
- Anzahl der Anforderungen in den Warteschlangen von WebSphere Application Server auf ein Minimum reduzieren.
Generell sollten die Anforderungen in dem Netz warten, das dem Web-Server vorgeschaltet ist, und nicht innerhalb von WebSphere Application Server. In dieser Konfiguration können nur die Anforderungen in das Warteschlangennetz gelangen, die für die Verarbeitung bereit sind. Sie können dies erreichen, indem Sie die Warteschlangen um so größer konfigurieren, je weiter vorne (vorgeschaltet) oder näher am Client sie sind. Entsprechend müssen die Warteschlangen, die weiter unten (nachgeschaltet) oder am weitesten vom Client entfernt sind, die kleinsten Warteschlangen sein.
Die Warteschlangen im Warteschlangennetz werden immer kleiner, während die Arbeitslast nach unten weitergegeben wird. Wenn 200 Clientanforderungen beim Web-Server ankommen, warten 125 dieser Anforderungen im Netz, da der Web-Server für nur 75 parallele Clients konfiguriert ist. Von diesen 75 Anforderungen bleiben 25 in der Warteschlange des Web-Servers und 50 werden zur Bearbeitung an den Web-Container übergeben. Dieser Prozess wird in der Datenquelle fortgesetzt, bis 25 Benutzeranforderungen den Zielort (den Datenbankserver) erreicht haben. Da es an jedem übergeordneten Punkt anstehende Operationen gibt, muss keine Komponente dieses Systems auf Arbeit warten. Die Masse der Anforderungen wartet außerhalb von WebSphere Application Server im Netz. Diese Art der Konfiguration sorgt für eine hohe Stabilität, weil keine Komponente überlastet wird.Edge Server kann eingesetzt werden, um wartende Benutzer an andere Server in einem Cluster von WebSphere Application Server umzuleiten.
- Mit Durchsatzkurven bestimmen, wann das Leistungsspektrum des Systems maximal ausgeschöpft ist.
Sie können ein Anwendungsbeispiel verwenden, das die wesentlichen Aspekte der Produktionsanwendung repräsentiert. Dazu ist es erforderlich, alle relevanten Codepfade zu testen oder die Produktionsanwendung selbst für den Test zu verwenden. Führen Sie eine Reihe von Experimenten durch, um festzustellen, wann das Leistungsspektrum des Systems voll ausgeschöpft ist (Leistungsgrenze). Diese Tests sollten Sie durchführen, nachdem die Mehrzahl der Engpässe der Anwendung beseitigt wurde. Ziel dieser Tests ist es, die CPUs an ihre Auslastungsgrenze (von 100 %) zu führen. Beginnen Sie Ihre Experimente mit großen Warteschlangen, um so viele gemeinsame Zugriffe wie möglich im System zu unterstützen. Für das erste Experiment könnten Sie beispielsweise für jede der Warteschlangen im Warteschlangennetz (Web-Server, Web-Container und Datenquelle) die Größe 100 festlegen. Experimentieren Sie dann mit zunehmender Arbeitslast durch parallele Benutzer und zeichnen Sie eine Durchsatzkurve. Führen Sie beispielsweise Experimente mit 1 Benutzer, 2 Benutzern, 5, 10, 25, 50, 100, 150 und 200 Benutzern durch. Erfassen Sie nach jedem Durchlauf den Durchsatz (Anforderungen pro Sekunde) und die Antwortzeiten (Sekunden pro Anforderung). Die resultierende Kurve sollte so ähnlich aussehen, wie die nachfolgend gezeigte typische Durchsatzkurve:
Der Durchsatz von WebSphere Application Server ist direkt von der Anzahl paralleler Anforderungen im Gesamtsystem abhängig. Im Abschnitt A (dem Bereich mit geringer Belastung) ist zu sehen, dass der Durchsatz fast linear mit der steigenden Zahl von Benutzeranforderungen zunimmt. Daraus lässt sich ableiten, dass parallele Anforderungen bei niedriger Belastung kaum Engpässe in den Systemwarteschlangen von WebSphere Application Server verursachen. Ab einem bestimmten Punkt kommt es zu einer Überlastung. Der Durchsatz steigert sich nur noch geringfügig und stößt schließlich, bedingt durch einen Engpass im System von WebSphere Application Server, an seine obere Grenze. Der Engpass, der sich am einfachsten beseitigen lässt, ist die volle Auslastung der CPUs in den Maschinen von WebSphere Application Server.
Im Abschnitt B (dem Bereich mit starker Belastung) bleibt der Durchsatz trotz steigender Clientarbeitslast relativ konstant. Die Antwortzeit erhöht sich jedoch proportional zur Benutzerlast. Im Bereich mit starker Auslastung bedeutet eine Verdopplung der Benutzerlast somit eine Verdopplung der Antwortzeit. Ab einem bestimmten Punkt (dargestellt im Abschnitt C) kippt die Kurve, weil eine der Systemkomponenten an ihre Leistungsgrenze stößt. Hier beginnt der Durchsatz zurückzugehen. Das System könnte beispielsweise in diese Zone kommen, wenn die Netzverbindungen des Web-Servers die Kapazität des Netzwerkadapters erschöpfen oder die Anforderungen die Systemgrenzwerte für die Bearbeitung von Dateien überschreiten.
Wenn die CPU-Auslastung bei annähernd 100 % liegt und die Leistungsgrenze somit erreicht ist, können Sie mit dem nächsten Schritt fortfahren. Sollte die CPU-Leistungsgrenze erreicht sein, bevor die Systemauslastung 100 % erreicht hat, gibt es wahrscheinlich noch einen anderen Engpass, der durch die Anwendung verschlimmert wird. Es wäre möglich, dass die Anwendung Java-Objekte erstellt, die eine umfangreiche Garbage-Collection verursachen und so im Java-Code zu einem Engpass führen.
Auf Anwendungsengpässe sind zwei Reaktionen möglich: Sie können den Engpass beseitigen oder die Komponente, bei der der Engpass auftritt, klonen. Die beste Methode ist das Beseitigen des Engpasses. Nutzen Sie einen Java-basierten Profiler für Anwendungen wie z. B. Rational Application Developer, Performance Trace Data Visualizer (PTDV), Optimizeit von Borland, JProbe oder Jinsight, um die Objektnutzung insgesamt zu untersuchen.
- Größe der Warteschlangen mit zunehmender hierarchischer Entfernung vom Client verringern..
Die Anzahl der parallelen Benutzer an der Durchsatzgrenze stellt die maximale Konkurrenzbedingung für die Anwendung dar. Führt die Anwendung beispielsweise dazu, dass WebSphere Application Server bei 50 Benutzern an die Leistungsgrenze kommt, könnte bei 48 Benutzern ein ausgewogenes Verhältnis von Durchsatz und Antwortzeit gegeben sein. Dieser Wert wird auch als Maximum paralleler Anwendungsanforderungen bezeichnet. Dieses Maximum paralleler Anwendungsanforderungen ist der bevorzugte Wert für die Anpassung der Systemwarteschlangen von WebSphere Application Server. Da es erwünscht ist, dass die meisten Benutzer im vorgeschalteten Netz warten, sollten mit zunehmender hierarchischer Entfernung vom Client kleinere Werte für die Größe der Warteschlangen konfiguriert werden. Beispiel: Bei einem Maximum paralleler Anwendungsanforderungen von 48 sollten Sie für die Systemwarteschlangen folgende Anfangswerte festlegen: Web-Server 75, Web-Container 50, Datenquelle 45. Führen Sie anschließend eine Reihe weiterer Tests durch, bei denen Sie diese Werte etwas höher und etwas niedriger einstellen, um den optimalen Wert zu ermitteln.
Anhand der Option "Servlet Engine Thread Pool - Concurrently Active Threads" des Tivoli Performance Viewer können Sie die Anzahl paralleler Benutzer feststellen.
- Warteschlangeneinstellungen an die Zugriffsmuster anpassen.
In vielen Fällen wird nur ein Bruchteil der Anforderungen, die durch eine Warteschlange geleitet werden, an die nächste untergeordnete Warteschlange weitergegeben. Bei einer Site mit vielen statischen Seiten werden viele Anforderungen vom Web-Server erfüllt und nicht an den Web-Container weitergegeben. Die Warteschlange des Web-Servers kann in diesem Fall sehr viel größer sein als die des Web-Containers. Im vorherigen Beispiel wurde die Warteschlange des Web-Servers auf 75 gesetzt und nicht auf einen Wert, der annähernd dem Maximum gleichzeitiger Anwendungsanforderungen entspricht. Ähnliche Anpassungen müssen Sie vornehmen, wenn verschiedene Komponenten unterschiedliche Ausführungszeiten haben.
Wenn eine Anwendung beispielsweise 90 % der Zeit für ein komplexes Servlet und nur 10 % für eine kurze JDBC-Anfrage benötigt, werden Datenbankverbindungen durchschnittlich nur von 10 % der Servlets jederzeit genutzt, so dass die Warteschlange für Datenbankverbindungen erheblich kleiner als die Warteschlange des Web-Containers sein kann. Umgekehrt sollten Sie aber die Werte für die Warteschlangen des Web-Containers und der Datenquelle erhöhen, wenn ein Servlet den Hauptteil seiner Ausführungszeit für eine komplexe Abfrage in einer Datenbank verbraucht. Überwachen Sie in jedem Fall die CPU- und die Speicherauslastung für WebSphere Application Server und für die Datenbankserver, um sicherzugehen, dass es weder zu CPU- noch zu Speicherengpässen kommt.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprf_queuetip
Dateiname:cprf_queuetip.html