Problem, wenn Undertow mit Spring-Boot-App verwendet

Question

Ich habe eine Spring-Boot-App mit Standard eingebettet Tomcat (mit Tomcat jdbc Verbindung Pooling). Es ist Produktion und läuft gut. Ich verwende mysql als meine Datenbank.

ich jetzt mache einige Stresstests in meiner Testumgebung und zu versuchen, um zu sehen, ob ich offensichtlichen Vorteil bekommen, wenn ich von eingebettet Tomcat zu eingebettet Undertow wechseln. Die Leute behaupten, dadurch eine sichtbare Verbesserung ihres Durchsatzes zu erhalten, aufgrund der asynchronen Art der Handhabung von Unwetteranforderungen.

Ich weiß, wie Tomcat ausschließen und Sog hinzufügen, um App zu starten. Nachdem ich das getan habe, versuche ich, mein Stresstest-Skript auszuführen, um ungefähr 500 Anfragen pro Sekunde zu generieren, führe es für 5 Minuten unter dieser Last aus und sehe, wie es sich verhält. Wenn ich dies tue, beginne ich nach ein paar Sekunden jdbc-Ausnahmen, wie untenstehend mit Unterbrechungen angegeben.

org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection 
    at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:431) ~[spring-orm-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373) ~[spring-tx-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:426) ~[spring-tx-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:275) ~[spring-tx-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) ~[spring-tx-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136) ~[spring-tx-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 
    at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:133) ~[spring-data-jpa-1.10.2.RELEASE.jar!/:na] 
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.3.2.RELEASE.jar!/:4.3.2.RELEASE] 

Es bedeutet jdbc Verbindung nicht erworben werden können.

HINWEIS: Wenn ich den eingebetteten Sog entferne und erneut den eingebetteten Tomcat zu meiner App hinzufüge, läuft derselbe Test ohne jegliche jdbc-verbindungsbedingte Ausnahmen.

Mein zugrunde liegender Tomcat-jdbc-Pool hat 100 db-Verbindung. Für den Sog habe ich mit 100 Arbeiter- und 100 Io-Fäden probiert.

Ich habe auch versucht, mit HikariCP anstelle von Tomcat-Jdbc-Pooling Standard. Ich habe HikariCP mit maximumPoolSize = 100 und connectionTimeOut = 60000 probiert. Erneut Embedded-Tomcat + HikariCP läuft unter diesem Stresstest gut. Aber embedded-Undertow + HikariCP gibt ähnliche Ausnahmen.

Es passiert also etwas anderes, wenn ich Undertow ins Bild bringe. Aber ich kann es nicht verstehen. Bitte beachten Sie, dass diese Ausnahmen zeitweise auftreten, aber bei jedem Durchlauf meines Stresstests, wenn Undertow verwendet wird.

Ich suchte im Allgemeinen nach solchen Problemen. Im Allgemeinen finde ich solche allgemeine Krippe für Undertow nicht.

Jede Hilfe zur Analyse der Situation wird viel Zeit sparen.

Answer 1

Zunächst von Ihnen möglicherweise besser dran Dinge einzeln zu ändern, um potenzielle Probleme zu reduzieren.

Undertow - 100 IO-Threads ist viel zu viel. Sie sollten wahrscheinlich mit dem Standard hier bleiben, was ich glaube 1 IO-Thread pro Kern. IO-Threads-Only-Job ist es, die offenen Verbindungen zu verwalten und alle nicht blockierenden Arbeiten zu bearbeiten. JDBC SQL-Abfragen blockieren, sodass Sie sicherstellen müssen, dass alle Endpunkte, die die Anforderungen blockieren, die Anforderung an die Arbeitsthreads senden. Sie können dafür den BlockingHandler verwenden, ich weiß nicht, wie ich das mit Spring machen soll. Wieder sind 100 Worker-Threads etwas übertrieben, der Standardwert ist viel niedriger. Ich glaube 20-30 Range. Stellen Sie sicher, dass dies mit Ihrem vorhandenen Verbindungspool korrekt funktioniert, BEVOR Sie zu HikariCP wechseln. Ich würde vorschlagen, die Thread-Pools einfach auf ihren Standardwerten zu belassen und sicherzustellen, dass sie an die Worker-Threads gesendet werden.

HikariCP - 100 Verbindungen ist auch eine Menge für HikariCP, es sei denn, Sie haben Tonnen von sehr sehr lange laufenden Abfragen. Weitere Informationen about connection pool sizing.

Versuchen Sie nicht, beide gleichzeitig zu ändern.Es wird schwieriger sein herauszufinden, was in diesem Szenario vor sich geht.