Transportkanalservices optimieren
Die Transportkanalservices verwalten Clientverbindungen und die E/A-Verarbeitung für HTTP- und JMS-Anforderungen. Diese E/A-Services basieren auf den NIO-Features (Non-Blocking I/O), die in Java™ verfügbar sind. Diese Services bilden eine hoch skalierbare Grundlage für die Anforderungsverarbeitung in WebSphere Application Server. Die Java-NIO-basierte Architektur ist hinsichtlich Leistung, Skalierbarkeit und Benutzerfreundlichkeit Einschränkungen unterworfen. Deshalb ist die Integration reiner asynchroner E/A implementiert. Diese Implementierung bietet erhebliche Vorteile in Bezug auf die Benutzerfreundlichkeit, eine einfachere E/A-Verarbeitung und verringert die erforderlichen Aktionen zur Leistungsoptimierung.
Informationen zu diesem Vorgang
- die Skalierbarkeit, die es dem Produkt ermöglicht, viele Anforderungen parallel zu verarbeiten,
- die asynchrone Anforderungsverarbeitung, die eine N:1-Zuordnung von Clientanforderungen zu Web-Container-Threads unterstützt,
- die gemeinsame Nutzung und Trennung von Ressourcen, die eine gemeinsame Nutzung von Thread-Pools durch Web-Container und einen Messaging-Service unterstützt,
- einen verbesserten Bedienungskomfort,
- die Einbindung autonomer Optimierungs- und Konfigurationsfunktionen.
Durch das Ändern der Standardwerte der Einstellungen für einen oder mehrere Transportkanäle, die einer Transportkette zugeordnet sind, können Sie die Leistung dieser Kette verbessern.

Vorgehensweise
- Passen Sie die Einstellungen für den TCP-Transportkanal an. Klicken Sie in der Administrationskonsole
auf Server
> Servertypen > WebSphere-Anwendungsserver > Servername >
Ports. Klicken Sie anschließend für den zugehörigen Port auf Zugehörige Transporte anzeigen.
- Wählen Sie die Transportkette aus, deren Eigenschaften Sie ändern möchten.
- Klicken Sie auf den für diese Kette definierten TCP-Transportkanal.
- Verringern Sie den Wert der Eigenschaft "Maximale Anzahl offener Verbindungen". Dieser Parameter steuert die maximale Anzahl an Verbindungen, die einem Server zur Verfügung stehen. Wenn Sie für diesen Parameter den Standardwert 20000 übernehmen, der die maximal zulässige Verbindungsanzahl angibt, kann dies bei Fehlerbedingungen zu blockierten Websites führen, da das Produkt weiterhin Verbindungen akzeptiert und damit der Verbindungsrückstand und der zugehörige Arbeitsrückstand anwächst. Ändern Sie den Standardwert in einen erheblich niedrigeren Wert, z. B. 500, und führen Sie anschließend weitere Optimierungen und Tests durch, um den optimalen Wert für eine bestimmte Website oder Anwendungsimplementierung zu bestimmen.
- Wenn Clientverbindungen geschlossen werden, ohne dass die Daten an den Client zurückgeschrieben werden, ändern Sie den Wert für das Inaktivitätszeitlimit. Dieser Parameter steuert die maximale Anzahl an Verbindungen, die einem Server zur Verfügung stehen.
Nach dem Empfang einer neuen Verbindung wartet
der TCP-Transportkanal so lange, bis genügend Daten angekommen sind, bevor er die Verbindung über den
TCP-Transportkanal an die protokollspezifischen Kanäle verteilt.
Wenn in dem mit dem Parameter "Inaktivitätszeitlimit" festgelegten Zeitraum nicht genügend Daten empfangen werden,
schließt der TCP-Transportkanal die Verbindung.
Der Standardwert für diesen Parameter ist 60 (Sekunden). Dieser Wert ist für die meisten Anwendungen geeignet. Erhöhen Sie den Wert für diesen Parameter, wenn die Arbeitslast viele Verbindungen erfordert und nicht alle Verbindungen innerhalb von 60 Sekunden bedient werden können.
Ordnen Sie einem bestimmten HTTP-Port einen Thread-Pool zu. Jeder TCP-Transportkanal wird einem bestimmten Thread-Pool zugeordnet. Thread-Pools können von mehreren TCP-Transportkanälen und anderen Komponenten gemeinsam genutzt werden. Die Standardeinstellung für einen TCP-Transportkanal sehen vor, dass der gesamte HTTP-basierte Datenverkehr dem Thread-Pool WebContainer und jeder andere Datenverkehr dem Thread-Pool Default zugeordnet wird. Verwenden Sie die Menüliste Thread-Pool, um jedem TCP-Transportkanal einen bestimmten Thread-Pool zuzuordnen. Die Standardeinstellungen für diesen Parameter sehen vor, dass der gesamte HTTP-basierte Datenverkehr dem Thread-Pool WebContainer und jeder andere Datenverkehr dem Thread-Pool Default zugeordnet wird. Die Informationen zur Thread-Poolsammlung beschreiben, wie zusätzliche Thread-Pools erstellt werden.
Optimieren Sie die Größe Ihrer Thread-Pools. Standardmäßig kann ein Thread-Pool mindestens 10 und maximal 50 Threads haben. Zum Anpassen dieser Werte klicken Sie auf Thread-Pools > Name_des_Thread-Pools, und passen Sie dann die Werte an, die für die Parameter "Mindestgröße" und "Maximale Größe" dieses Thread-Pools angegeben sind.
In der Regel benötigen Anwendungen nicht mehr als 10 Threads pro Prozessor. Diese Zahl reicht nur dann nicht aus, wenn eine außergewöhnliche Bedingung im Server eintritt, z. B. wenn Back-End-Anforderungen nur sehr langsam verarbeitet werden und dazu führen, dass ein Server-Thread auf den Abschluss einer Back-End-Anforderung warten muss. In einem solchen Fall ist die Prozessorauslastung gering, und eine höhere Arbeitslast führt nicht zu einem höheren Prozessordurchsatz. Thread-Speicherauszüge zeigen, dass fast alle Threads im Aufruf an die Back-End-Ressource gebunden sind. Wenn eine solche Bedingung eintritt und die Back-End-Ressource ordnungsgemäß optimiert ist, können Sie versuchen, die Mindestanzahl der Threads im Pool schrittweise zu erhöhen, bis Sie einen verbesserten Durchsatz feststellen und Thread-Speicherauszüge zeigen, dass auch Threads in anderen Bereichen der Laufzeitumgebung als dem Back-End-Aufruf vorhanden sind.
Die Einstellung für den Parameter "Bei Bedarf erweitern" sollte nur dann geändert werden, wenn die Back-End-Ressource für längere Zeit blockiert zu sein scheint. Diese Bedingung kann darauf hinweisen, dass alle Laufzeit-Threads blockiert sind und auf das Back-End warten, anstatt andere Anforderungen zu verarbeiten, an denen das blockierte Back-End nicht beteiligt ist.
- Passen Sie die Einstellungen für den HTTP-Transportkanal an. Klicken Sie in der Administrationskonsole
auf Server
> Servertypen > WebSphere-Anwendungsserver > Servername >
Ports. Klicken Sie anschließend für den betreffenden Port auf Zugehörige Transporte anzeigen.
- Wählen Sie die Transportkette aus, deren Eigenschaften Sie ändern möchten.
- Klicken Sie auf den für diese Kette definierten HTTP-Transportkanal.
- Optimieren Sie die Keepalive-Einstellung für HTTP.
Mit der Einstellung "Persistente (Keep-Alive-) Verbindungen verwenden" können Sie steuern, ob Verbindungen zwischen Anforderungen geöffnet bleiben sollen. Wenn die Verbindungen geöffnet bleiben, können Sie die Kosten für das Einrichten und Schließen von Sockets einsparen, wenn Clients mehrere Anforderungen senden. Der Standardwert ist "true" und gewöhnlich die optimale Einstellung.
Wenn Ihre Clients nur einzelne Anforderungen in relativen langen Abständen senden, ist es wahrscheinlich besser, diese Option zu inaktivieren und die Verbindungen sofort zu schließen, anstatt die Zeitlimits für das Schließen der Verbindung zu einem späteren Zeitpunkt vom HTTP-Transportkanal festlegen zu lassen.
- Ändern Sie den Wert des Parameters "Maximale Anzahl persistenter Anforderungen", um die Anzahl der Anforderungen zu erhöhen, die über eine
Verbindung übertragen werden können, bevor die Verbindung geschlossen wird.
Wenn die Option Persistente Verbindungen verwenden aktiviert ist, steuert der Parameter "Maximale Anzahl persistenter Anforderungen" die Anzahl der Anforderungen, die über eine Verbindung übertragen werden können, bevor die Verbindung geschlossen wird. Der Standardwert ist 100. Wählen Sie den Wert so, dass für die meisten, wenn nicht alle Clients immer eine offene Verbindung zur Verfügung steht, wenn sie in einer Verbindung mehrere Anforderungen absetzen. Eine ordnungsgemäße Einstellung dieses Parameters spart die Kosten für unnötiges Einrichten und Schließen von Sockets ein.
Für Testszenarien, in denen der Client nie geschlossen wird, können Sie mit dem Wert -1 die Verarbeitung inaktivieren, wodurch die Anzahl der Anforderungen in einer Verbindung beschränkt wird. Das Persistenzzeitlimit sorgt dafür, dass einige inaktive Sockets trotzdem geschlossen werden, und schützt Ihren Server vor einem Mangel an geöffneten Sockets.
- Erhöhen Sie den den Wert für den Parameter "Persistenzzeitlimit", damit eine Verbindung länger geöffnet bleibt, bevor sie wegen Inaktivität geschlossen wird. Der Parameter "Persistenzzeitlimit" steuert, wie lange eine Verbindung geöffnet bleibt, bevor sie aufgrund mangelnder Aktivität geschlossen wird. Der Standardwert ist 30 (Sekunden). Wählen Sie den Wert für diesen Parameter so, dass genügend Verbindungen geöffnet bleiben, damit den meisten Clients eine Verbindung zur Verfügung steht, wenn sie eine Anforderung absetzen müssen.
- Wenn Clients Schwierigkeiten haben, eine Anforderung abzuschließen, weil das Senden der Daten länger als 60 Sekunden dauert, ändern Sie den Wert für den Parameter "Lesezeitlimit". Einige Clients warten länger als 60 Sekunden, wenn sie im Rahmen einer Anforderung Daten senden. Um sicherzustellen, dass die Clients ihre Anforderungen abschließen können, geben Sie für diesen Parameter einen Wert (in Sekunden) an, der den Clients die Übertragung der Daten ermöglicht. Beim Ändern dieses Wertes müssen Sie darauf achten, dass der Server vor Clients geschützt bleibt, die unvollständige Daten senden und damit die Ressourcen (Sockets) übermäßig lange belegen.
- Wenn einige Ihrer Clients mehr als 60 Sekunden benötigen, um die an sie geschriebenen Daten zu empfangen, ändern Sie den Wert für den Parameter "Schreibzeitlimit". Einige Clients sind langsam und benötigen für den Empfang der an sie gesendeten Daten mehr als 60 Sekunden. Um sicherzustellen, dass die Clients alle Daten erhalten, geben Sie für diesen Parameter einen Wert (in Sekunden) an, der ihnen ermöglicht, alle Daten zu empfangen. Beim Ändern dieses Wertes müssen Sie darauf achten, dass der Server vor zerstörerischen Clients geschützt bleibt.
- Passen Sie die Einstellungen des Web-Containers für den Transportkanal an. Klicken Sie in der Administrationskonsole
auf Server
> Servertypen > WebSphere-Anwendungsserver > Servername >
Ports. Klicken Sie anschließend für den zugehörigen Port auf Zugehörige Transporte anzeigen.
- Wählen Sie die Transportkette aus, deren Eigenschaften geändert werden müssen.
- Klicken Sie auf den für diese Kette definierten Transportkanal des Web-Containers.
- Wenn mehrere Schreibvorgänge erforderlich sind, um Antworten an den Client zu verarbeiten, ändern Sie den Wert
für den Parameter "Größe des Schreibpuffers" in einen Wert, der für Ihre Clients angemessener ist. Dieser Parameter steuert, wie viele Daten pro Thread der Web-Container maximal puffert, bevor er die Anforderung zur Verarbeitung weitersendet.
Der Standardwert ist 32768 Byte, was für die meisten Anwendungen ausreicht.
Wenn eine Antwort größer ist als der Schreibpuffer, wird die Antwort abgeschnitten und in mehreren TCP-Schreibvorgängen zurückgeschrieben.
Wenn Sie den Wert für diesen Parameter ändern müssen, stellen Sie sicher, dass der neue Wert so gewählt ist, dass die meisten Anforderungen in einem einzigen Schreibvorgang geschrieben werden können. Zur Bestimmung eines für diesen Parameter geeigneten Wertes sehen Sie sich die Größe der Seiten an, die zurückgegeben werden, und fügen Sie diesem Wert einige zusätzliche Bytes für die HTTP-Header hinzu.
- Passen Sie die Einstellungen für die gebundenen Puffer an.
Auch wenn die Standardparameter für gebundene Puffer für die meisten Umgebungen optimal sind, müssen Sie die Standardwerte in bestimmten Situationen oder für manche Betriebssysteme ändern, um die Leistung zu verbessern. Das Ändern der Parameter für gebundene Puffer kann sich negativ auf die Leistung auswirken. Deshalb müssen Sie andere zugehörige Bereiche, wie z. B. den Web-Container oder die ORB-Thread-Pools unbedingt optimieren, bevor Sie die Parameter für gebundene Puffer ändern.
Gehen Sie zum Ändern der Parameter für gebundene Puffer wie folgt vor:
- Klicken Sie in der Administrationskonsole auf Server > Servertypen > WebSphere-Anwendungsserver > Servername.
- Klicken Sie im Abschnitt "Serverinfrastruktur" auf Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine.
- Klicken Sie auf Angepasste Eigenschaften.
- Geben Sie eine der folgenden angepassten Eigenschaften im Feld "Name" und einen entsprechenden Wert im Feld
Wert ein, und klicken Sie anschließend auf
Anwenden, um die angepasste Eigenschaft und ihre Einstellung zu speichern.
- com.ibm.ws.util.BoundedBuffer.spins_take=Wert
Gibt an, wie oft ein Web-Container-Thread versuchen darf, eine Anforderung aus dem Puffer abzurufen, bevor der Thread ausgesetzt und in die Warteschlange eingereiht wird. Mit diesem Parameter können Sie einen Kompromiss zwischen den Kosten für möglicherweise nicht erfolgreiche Abrufversuche und Kosten für das Aussetzen und anschließende Reaktivieren eines Threads bei einer put-Operation finden.
Information Wert Standardeinstellung Die Anzahl der für das Betriebssystem verfügbaren Prozessor minus 1. Empfohlen: Verwenden Sie einen nicht negativen ganzzahligen Wert. In der Praxis wurden mit einem Wert von 2 bis 8 die besten Leistungsergebnisse erzielt. Syntax: com.ibm.ws.util.BoundedBuffer.spins_take=6. Es sind sechs Versuche erlaubt, bevor der Thread ausgesetzt wird. - com.ibm.ws.util.BoundedBuffer.yield_take=true oder false
Gibt an, dass ein Thread den Prozessor nach einer bestimmten Anzahl von Versuchen, eine Anforderung aus dem Puffer abzurufen, für andere Threads freigibt. Gewöhnlich ist eine geringe Anzahl von Versuchen empfehlenswert.
Information Wert Standardeinstellung false Empfohlen: Die Auswirkungen für die einzelnen Plattformen sind implementierungsspezifisch. Syntax: com.ibm.ws.util.BoundedBuffer.spins_take=boolescher Wert - com.ibm.ws.util.BoundedBuffer.spins_put=Wert
Gibt an, wie oft ein InboundReader-Thread versucht, eine Anforderung in den Puffer zu stellen, bevor der Thread ausgesetzt und in die Warteschlange eingereiht wird. Verwenden Sie diesen Wert, um die Kosten für wiederholte, möglicherweise nicht erfolgreiche Versuche, eine Anforderung in den Puffer zu stellen, gegen die Kosten für das Aussetzen und Reaktivieren eines Thread als Antwort auf eine take-Operation abzuwägen.
Information Wert Standardeinstellung Der Wert von "com.ibm.ws.util.BoundedBuffer.spins_take" wird durch 4 dividiert. Empfohlen: Verwenden Sie einen nicht negativen ganzzahligen Wert. In der Praxis wurden mit einem Wert zwischen 2 und 8 die besten Leistungsergebnisse erzielt. Syntax: com.ibm.ws.util.BoundedBuffer.spins_put=6. Es sind sechs Versuche erlaubt, bevor der Thread ausgesetzt wird. - com.ibm.ws.util.BoundedBuffer.yield_put=true oder false
Gibt an, dass ein Thread den Prozessor nach einer bestimmten Anzahl von Versuchen, eine Anforderung in den Puffer zu stellen, für andere Threads freigibt. Gewöhnlich ist eine geringe Anzahl von Versuchen empfehlenswert.
Information Wert Standardeinstellung false Empfohlen: Die Auswirkungen für die einzelnen Plattformen sind implementierungsspezifisch. Syntax: com.ibm.ws.util.BoundedBuffer.yield_put=boolescher Wert - com.ibm.ws.util.BoundedBuffer.wait=Anzahl der Millisekunden
Gibt an, wie lange (in Millisekunden) eine Anforderung maximal verzögert werden kann, wenn der Puffer vollständig ausgeschöpft ist oder wenn er leer ist.
Information Wert Standardeinstellung 10000 Millisekunden Empfohlen: Der Wert von 10000 Millisekunden ist in den meisten Fällen mehr als angemessen. In seltenen Fällen, in denen der Puffer ausgeschöpft oder leer ist, kann ein kleinerer Wert eine rechtzeitigere Verarbeitung von Anforderungen sicherstellen, allerdings hat die Verwendung eines kleineren Wertes gewöhnlich Auswirkungen auf die Leistung. Syntax: com.ibm.ws.util.BoundedBuffer.wait=8000. Eine Anforderung kann um bis zu 8000 Millisekunden unnötig verzögert werden.
- com.ibm.ws.util.BoundedBuffer.spins_take=Wert
- Klicken Sie auf Anwenden und anschließend auf Speichern, um die Änderungen zu speichern.


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