Undertow與Spring Boot應用程序一起使用時的問題

Question

我有一個使用默認嵌入式tomcat（帶有tomcat jdbc連接池）運行的spring boot應用程序。 這是生產和運行良好。 我正在使用mysql作為數據庫。

我現在正在測試環境中進行一些壓力測試，並嘗試查看如果從嵌入式Tomcat切換到嵌入式Undertow，是否可以獲得任何明顯的好處。 人們聲稱這樣做是由於underwow請求處理的異步特性，因此可以顯着提高吞吐量。

我知道如何排除tomcat並將undertow添加到啟動應用程序。 之后，我嘗試運行壓力測試腳本，以大致每秒生成500個請求，在此負載下運行5分鍾，並查看其行為。 當我這樣做時，在最初的幾秒鍾后，我開始間歇性地收到如下的jdbc異常。

 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]

這意味着無法獲取jdbc連接。

注意 ：如果我刪除嵌入式underwow，然后再次將嵌入式tomcat添加到我的應用程序，則相同的測試運行良好，沒有任何與jdbc-connection相關的異常。

我的底層Tomcat-jdbc-pool有100個db-connection。 對於undertow，我嘗試使用100個工作線程和100個io線程。

我還嘗試使用HikariCP代替默認的tomcat-jdbc-pooling。 我嘗試了HikariCP，其中maximumPoolSize = 100和connectionTimeOut = 60000。 再次，嵌入式Tomcat + HikariCP在此壓力測試下運行良好。 但是Embedded-Undertow + HikariCP給出了類似的例外。

因此，當我將Undertow帶入圖片中時，會發生一些不同的事情。 但是我聽不懂。 請注意，這些例外情況是間歇性發生的，但是在使用Undertow的每次壓力測試中，都可以肯定地得到這些例外。

我通常會搜索此類問題。 總的來說，我找不到Undertow的普通嬰兒床。

分析情況的任何幫助將節省大量時間。

Answer 1

首先，您最好一次更改一項以減少潛在的問題。

不足-100個IO線程太多了。 您可能應該在這里使用默認值，即每個內核1個IO線程。 IO線程的唯一工作是管理打開的連接並處理任何非阻塞性工作。 JDBC SQL查詢正在阻塞，因此您需要確保任何阻塞的端點都會將請求分派到工作線程。 您可以為此使用BlockingHandler，但我不確定如何使用Spring。 同樣，100個工作線程可能有點多余，默認值要低很多，我相信20-30范圍。 在切換到HikariCP之前，請確保這在您現有的連接池中正常運行。 我建議僅將線程池保留為默認值以啟動，並確保您正在分派到工作線程。

HikariCP-除非您有大量非常長時間運行的查詢，否則HikariCP也會有100個連接。 有關連接池大小的更多信息。

不要嘗試同時更改兩者。 追蹤這種情況下發生的事情將更加困難。