許多同時連接和縮減的Tomcat性能問題

我正在Ubuntu 14.04LTS服務器上運行帶有Spring REST服務的Tomcat 7.0.55實例。我正在使用Gatling進行性能測試。我使用訪問REST後端的前端應用程序創建了一個模擬。許多同時連接和縮減的Tomcat性能問題

我的配置是：

Total RAM: 512MB, 1 CPU, JVM options: -Xms128m -Xmx312m -XX:PermSize=64m -XX:MaxPermSize=128m

似乎環境可能不會是非常有效的，但如果我不越過〜700個用戶數限制（我處理7分鐘90K請求）我得到的所有請求成功處理並且非常快速。

我開始有問題，當有太多的連接在同一時間。失敗的情況是7分鐘內有大約12萬個請求。當有大約800個併發用戶參與時，問題就開始了。直到用戶數爲600-700，一切都很好，但這個極限後，我開始越來越異常：

java.util.concurrent.TimeoutException: Request timed out to /xxx.xxx.xxx.xxx:8080 of 60000 ms 
     at com.ning.http.client.providers.netty.timeout.TimeoutTimerTask.expire(TimeoutTimerTask.java:43) [async-http-client-1.8.12.jar:na] 
     at com.ning.http.client.providers.netty.timeout.RequestTimeoutTimerTask.run(RequestTimeoutTimerTask.java:43) [async-http-client-1.8.12.jar:na] 
     at org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:556) [netty-3.9.2.Final.jar:na] 
     at org.jboss.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:632) [netty-3.9.2.Final.jar:na] 
     at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:369) [netty-3.9.2.Final.jar:na] 
     at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.9.2.Final.jar:na] 
     at java.lang.Thread.run(Unknown Source) [na:1.7.0_55] 
12:00:50.809 [WARN ] c.e.e.g.h.a.GatlingAsyncHandlerActor - Request 'request_47' 
failed : GatlingAsyncHandlerActor timed out

我認爲這可能與小JVM。但是，當我將環境升級到：

Total RAM: 2GB, 2CPUs, JVM options: -Xms1024m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m

我仍然得到非常相似的結果。失敗請求的差異是微不足道的。

我一直在玩設置Tomcat連接器沒有效果。目前tomcat的設置是：

<Connector enableLookups="false" maxThreads="400" maxSpareThreads="200" minSpareThreads="60" maxConnections="8092" port="8080" protocol="org.apache.coyote.http11.Http11Protocol" connectionTimeout="20000" keepAliveTimeout="10000" redirectPort="8443" />

操縱的線程，連接的數量，KeepAliveTimeout的沒有在所有幫助，以獲得800個併發用戶，沒有超時工作。我計劃擴展應用程序以處理至少2k個併發用戶，但到目前爲止，我可以看到垂直擴展和升級env並沒有給出結果。我也沒有通過jvisualvm發現任何內存問題。操作系統不應該是一個限制，ulimits被設置爲無限制或高值。數據庫不是一個瓶頸，因爲所有REST都使用內部緩存。

看來tomcat在我的情況下無法處理超過800個連接用戶。你對這些問題如何得到解決有什麼想法嗎？我希望能夠擴展到至少2k用戶，並儘可能降低失敗率。我將不勝感激任何想法和技巧，我如何才能解決問題。如果你需要更多的細節，請留下評論。

乾杯亞當

來源

2014-09-10 Adam Soliński

你增加打開文件number.Every連接消耗打開的文件的項目。

來源

2014-09-10 11:02:08 ben

是的，我做到了。我已經把它設置爲4000，沒有改進。 – 2014-09-10 12:23:18

你確定tomcat進程正在拾取ulimit嗎？你可能想嘗試在Tomcat的startup.sh中設置它。 – AngerClown 2014-09-10 22:53:43

考慮到您在如此短的時間內創建瞭如此之多，您可能正在達到TCP連接的限制。默認情況下，Linux會在清理連接之前等待一段時間。測試失敗後，運行netstat -ant | grep WAIT | wc -l並查看您是否接近60,000。如果是這樣，那表明您可以對TCP堆棧進行一些調整。嘗試改變下列sysctl設置：

net.ipv4.tcp_keepalive_intvl = 15 
net.ipv4.tcp_keepalive_probes = 5 
net.ipv4.tcp_fin_timeout = 5

您也可以嘗試在this ServerFault question提到的一些其他設置。

來源

2014-09-10 13:53:06 AngerClown

netstat grep WAIT返回了40個結果，而不是60k。但是，我對tomcat連接器進行了更改，並將其更改爲Non blocking NIO。到目前爲止，這使我的表現提高了50％。當我設法改進它時，我會在我的問題中提出相關說明。 – 2014-09-10 14:28:02

因此，使用NIO連接器類型完成了50％的改進。這似乎影響了整體性能，但是，仍然當併發用戶數達到800時，我仍然收到超時異常。因此這仍然沒有解決。 – 2014-09-10 15:38:55

許多同時連接和縮減的Tomcat性能問題

回答

相關問題