Comet 부하테스트

NIO로 처리되는 톰캣 Comet은 일반 서블릿과 어떤 차이가 있을까?

과연 처리당 스레드 생성하는 과거 모델에 비해 성능상 이점이 있는 것인가?

 

부하용 프로그램을 만들어서 접속을 증가해보았다.

하지만 접속수가 2817에 이르러서는 JVM이 뻗어버렸다.

2011. 10. 28 오전 11:11:07 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run
심각:
java.lang.OutOfMemoryError: Java heap space
 at java.lang.Throwable.getStackTraceElement(Native Method)
 at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
 at java.lang.Throwable.getStackTrace(Throwable.java:582)
 at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:155)
 at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
 at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:779)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2271)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)

생전 처음 보는 메시지

2011. 10. 28 오전 11:13:33 org.apache.tomcat.util.net.NioEndpoint setSocketOptions
심각:
java.lang.OutOfMemoryError: Java heap space
SEVERE:Memory usage is low, parachute is non existent, your system may start failing.
SEVERE:Memory usage is low, parachute is non existent, your system may start failing.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d9a76f2, pid=4360, tid=4524
#
# JRE version: 6.0_22-b04
# Java VM: Java HotSpot(TM) Client VM (17.1-b03 mixed mode, sharing windows-x86 )
# Problematic frame:
# V  [jvm.dll+0x1076f2]
#
# An error report file with more information is saved as:
# D:\eclipse\hs_err_pid4360.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

 

리소스 그래프는 아래와 같다.

듀얼코어 CPU라서 CPU 사용량은 50%정도(1코어만 사용한다는 증거)로 증가했음을 알 수 있다.

 

그렇다면 일반 서블릿에서는?

자연과학 실험에서 실험군과 대조군을 나누어서 한다고 배웠다.

일반 서블릿에서는 어떻게 나타날 것인가?

 

예상과는 달리 일반 서블릿에서는 접속 한계 수치가 3956으로 나타났다.

JVM이 멈추지도 그래프도 무난히 나타났다. CPU 수치가 더 낮다.

 

 

그런데 로그에 기록된 접속 수는?

그런데 로그에 찍힌 접속 수를 보니 좀 이상했다.

서블릿에서는 load3라는 path를 사용했고, comet에서는 load2라는 path를 key로 구분했었는데

load3 (servlet)는 200개의 접속이 기록되었었다. 200개의 연결이 한계인가?

load2 (comet)는 2733개의 접속이 기록이 되었다.

 

아마도 톰캣의 스레드풀의 개수 때문으로 보여진다.

The Executor (thread pool)
   maxThreads :  (int) The max number of active threads in this pool, default is 200

Executor name="tomcatThreadPool" 에 보면 기본값이 200이다. (지정을 하지 않았기에 디폴트를 따르게 된다.)

 

결론: 일반 서블릿 vs Comet 은?

결론부터 이야기하면 Thread 모델로 동작하는 일반 서블릿은 스레드 풀의 크기 제한으로 부터 자유로울 수 없다.

이에 비해 NIO로 동작하는 Comet의 경우는 10배 정도의 접속(약 2000개)까지 처리가 가능할 것으로 보인다.