Viele benutzerdefinierte Anwendungen rufen Web-Services von AEM auf. Diese Anwendungen verwenden Apache Commons HTTP Client oder andere Bibliotheken. Wenn Leistungsprobleme bei den Back-End-Systemen auftreten, treten bei AEM nur geringe Antwortzeiten auf. Wenn zu viele Threads hängen, kann dies außerdem zu langsamen JVM-Speicherbereinigungen, Fehlern im Arbeitsspeicher, Betriebssystemauslastung usw. führen.
Wenn Sie Thread-Dumps oder Heap-Dumps von AEM erfassen, beobachten Sie viele Threads, die auf die Web-Service-Aufrufe warten.
Beispielszenario:
Unter [1] befindet sich ein Beispiel für eine Stack-Ablaufverfolgung aus einem JVM-Thread-Dump. Dieser wurde von einer AEM-Instanz erfasst, bei der eine Anwendung einen schlecht funktionierenden Back-End-Dienst aufweist.
Die Thread-Sicherheitskopie zeigte einige Probleme:
- Der unten aufgeführte Anfrage-Thread war auf einem Web Service hängen geblieben, der nicht geantwortet hat. Keine Socket-Lese-Zeitüberschreitung wurde gesetzt, so dass der Thread für immer warten musste. Siehe hier für die Lösung.
- Hunderte von Threads warten auf den einzelnen Anfrage-Thread. Der Grund dafür war, dass der Threadpool als Single-Thread konfiguriert wurde, in einer als Erster rein, als Erster raus Warteschlange. Die vielen ausstehenden vorhandenen Threads führten zu einer hohen Arbeitsspeicherauslastung. Siehe hier für die Lösung.
- Der Webdienst, der aufgerufen wurde, brauchte zu lange, um zu antworten. Dies führte dazu, dass sich der oben erwähnte Thread anhäufte.
Beachten Sie die markierten Stapelzeilen:
- In Gelb können Sie sehen, dass die benutzerdefinierte Anwendung die RestTemplate-Bibliothek vom Spring Framework verwendet, um einen Web-Service-Aufruf auszuführen.
- In Orange können Sie sehen, dass der Spring Framework einen Apache Commons HTTP Client für seine Web-Service-Aufrufe verwendet.
- In Rot können Sie sehen, dass der Thread in SocketInputStream.socketRead hängen geblieben ist, was bedeutet, dass er auf eine Antwort vom Web Service wartet.
[1]