![[z/OS]](../images/ngzos.gif)
Optimierung für SOAP
Dieser Artikel beschreibt, wie Sie die SOAP-Nachrichten optimieren, die Sie für Ihre Web-Services verwenden.
Informationen zu diesem Vorgang
Vorgehensweise
- Geben Sie in servant.jvm.options noLocalCopies an (-Dcom.ibm.CORBA.iiop.noLocalCopies=1). Diese Angabe bewirkt, dass Parameter durch Referenz und nicht als Wert übergeben werden. Dies gilt nur, wenn Sie eine Enterprise-Bean als einen Web-Service zugänglich machen. Weitere Informationen finden Sie in den Beschreibungen der Einstellungen des ORB-Service.
- Vergewissern Sie sich, dass alle Traces inaktiviert sind, solange Sie nicht aktiv ein Fehler-Debug durchführen.
- Wenn Sie die Transaktionsrichtlinien für Ihre Anwendung definieren, geben Sie TX_NOT_SUPPORTED an, und wählen Sie lokale Transaktionen aus. Der Durchsatz lokaler Transaktionen ist besser als der globaler Transaktionen, weil WebSphere nicht den COMMIT-Bereich mehrerer Ressourcenmanager koordinieren muss.
- Vermeiden Sie die Übergabe leerer Attribute oder Elemente in SOAP-Nachrichten. Nehmen Sie keine überflüssigen Daten in SOAP-Nachrichten auf. Wenn Sie für den Aufruf eines Web-Service document/literal verwenden können, um mehrere Anforderungen in eine SOAP-Nachricht zu packen, sollten Sie diesem Ansatz den Vorzug vor dem mehrfachen Senden einzelner SOAP-Nachrichten geben. Der Durchsatz von SOAP-Anwendungen ist bei kleineren SOAP-Nachrichten mit wenigen XML-Elementen und insbesondere weniger XML-Attributen höher. Der Inhalt von SOAP-Nachrichten muss serialisiert und syntaktisch analysiert werden. Diese Operationen sind kostenintensiv und sollten auf ein Minimum reduziert werden. Das Senden einer Nachricht mit 10 KB ist daher vorteilhafter als das Senden von 10 Nachrichten mit 1 KB. Sehr große Nachrichten (beispielsweise mit mehr als 200 KB) können jedoch Systemressourcen wie die Speicherkapazität belasten.
- Möglicherweise müssen Sie den Wert für die Standardgröße des Java-Heapspeichers erhöhen. SOAP und XML (DOM) sind speicherintensiv. Eine kleiner Heapspeicher kann übermäßig viele Java-Garbage-Collections zur Folge haben. Bei den meisten Anwendungsbeispielen im Labor hat sich eine Heapgröße von 256 M (Standardgröße) als optimal erwiesen. Die Garbage-Collection können Sie mit der Java-Anweisung "verbose:gc" überwachen.
- Stellen Sie sicher, dass die TCP/IP-Sendepuffer und -Empfangspuffer für die Menge der gesendeten XML-Nachrichten groß genug sind.
- Erwägen Sie die Verwendung eines Dokumentmodells an Stelle des RPC-Modells. Mit einem Dokumentmodell haben Sie vollständige Kontrolle über das Format der XML. Der Programmierungsaufwand ist in diesem Fall jedoch größer.
- Wenn Sie mit RPC-Nachrichten arbeiten, versuchen Sie nach Möglichkeit, Zeichenfolgen zu senden.
- Für JAX-RPC-Web-Services sollte Sie eigene Serialisierungs- und Entserialisierungsprogramme schreiben und Reflexion vermeiden.