2014-09-10 2 views
0

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 명의 사용자의 한계를 교차하지 않는 경우 (I 7 분 90K 요청을 처리) :

내 설정이다 요청이 성공적으로 처리되었습니다.

동시에 너무 많은 연결이있는 경우 문제가 발생하기 시작합니다. 실패한 시나리오는 7 분 안에 약 120,000 건의 요청이 있다는 것입니다. 문제는 약 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 커넥터를 아무런 효과없이 설정하여 사용 해왔다. 현재 바람둥이 설정은 다음과 같습니다 스레드, 연결의 수를 조작

<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을 통해 메모리 관련 문제가 발생하지 않습니다. OS는 제한이 없으며, ulimits는 무제한 또는 높은 값으로 설정됩니다. 모든 REST가 내부 캐시를 사용하기 때문에 DB에 병목 현상이 없습니다.

바람둥이가 나의 경우에 800 명 이상의 연결된 사용자를 처리 할 수없는 것 같습니다. 이 이슈들이 어떻게 견딜 수 있는지에 대한 아이디어가 있습니까? 나는 적어도 2k 명의 사용자까지 확장하고 실패율을 가능한 한 낮게 유지하고 싶습니다. 나는 그것을 해결할 수있는 어떤 생각과 조언을 주셔서 감사하겠습니다. 자세한 내용이 필요하면 의견을 남겨주세요.

건배 아담

답변

0

는 열린 파일 number.Every 연결이 열려있는 파일 항목을 소비 증가 마십시오.

+0

네, 그랬습니다. 4000으로 설정 했으므로 개선되지 않았습니다. –

+0

Tomcat 프로세스가 ulimit을 선택하고 있습니까? Tomcat의 startup.sh에서 설정하려고 할 수 있습니다. – AngerClown

0

이렇게 짧은 시간에 너무 많은 것을 만들면 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에 언급 된 다른 설정을 시도 할 수 있습니다.

+0

netstat grep WAIT가 60k가 아닌 40 개의 결과를 반환했습니다. 그러나 tomcat 커넥터를 변경하여 Non blocking NIO로 변경했습니다. 지금까지이 덕분에 성능이 50 % 향상되었습니다. 내가 그것을 더 많이 관리 할 때 나는 나의 질문에 관련 노트를 만들 것이다. –

+0

그래서 NIO 커넥터 유형으로 50 % 향상되었습니다. 이것은 전체적인 성능에 영향을 미친 것 같지만 동시 사용자 수가 800 명에 이르면 여전히 타임 아웃 예외가 발생합니다. 따라서 아직 해결되지 않은 채로 남아 있습니다. –