2. 실험 목표
proactor / reactor 서버 접속 개수 변경에 따라 서버 처리 속도 변화 확인
실험 방법
• 두 가지 방식에 대해 동일한 실험 진행
(512byte, 3Kb, 200Kb, 2Mb, 20Mb 스트림 저장)
• 접속 요청 개수 조절을 통한 서버 반응 확인
(1, 3, 5, 20, 50, 100 개로 확인)
기타 세부 조정
• 기본적으로 1접속 당 100번씩 요청하는 것으로 함
(동시 접속 3개 * 100 = 300회)
• 2Mb, 20Mb 경우에는 간략한 실험으로 진행
(접속 1개 당 10회 요청으로 축소)
69. 접속 : 3개
latency : 1093 ms
Throughput : 2.7/sec
20Mbyte(0x9005) 요청시 처리 결과
70. 접속 : 5개
latency : 1791 ms
Throughput : 2.5/sec
20Mbyte(0x9005) 요청시 처리 결과
71. 접속 : 20개
latency : 9403 ms
Throughput : 2.1/sec
20Mbyte(0x9005) 요청시 처리 결과
72. 접속 : 50개
latency : 19888 ms
Throughput : 2.5/sec
20Mbyte(0x9005) 요청시 처리 결과
73. 접속 : 100개
latency : 35306 ms
Throughput : 2.6/sec
20Mbyte(0x9005) 요청시 처리 결과
74. 20Mbyte 정리
20개부터 latency가 높아지고 있으며,
50개부터 급격히 높아지고 있음
동일 조건 Proactor 보다 latency가 3000ms 높음
하지만 실제 실험 시간이 훨씬 오래 걸림
(데이터 상으로 표시는 안 됨)
75. 정리하기
20개까지는 괜찮은데, 50개 부터는 어떠한 문제가 발생하는가?
• 평균적으로 50개 부터 latency가 급격히 증가하는 상황이 발생
• latency가 증가하며 동시간 처리량이 떨어지기 시작
• 용량 처리가 커지면 커질 수록 20개까지도 그 영향이 미침(뒤쪽 프로토콜)
그 원인은 무엇인가?
• Proactor의 경우에는 Thread가 직접 처리하지 않지만, NIO(커널에서 처리하는)에서 처리하는 한계에 도달하는 지점이 20~50개 이기 때문이라 생각한다
• Reactor는 동기식으로 Thread가 일일이 처리하기 때문에 대기 시간이 발생하기 때문이라 생각한다.
그 외에도...
• Reactor 고용량 실험이 Proactor보다 더 오래 걸리는 이유?
Thread가 일일이 받아 처리하기 때문에 모든 업무가 줄을 서서 대기하는 상태가 됨
게다가 파일을 쓰는 것은 커널을 거쳐서 진행하는 것이기 때문에 IO가 일어나게 하는 동안 중간 동작이 개입 될 수 있다 생각
반면 Proactor는 실제 처리는 커널이 하고 요청을 받고 결과를 돌려주는 것만 Thread가 하기 때문에 대기 상태가 최소가 됨
또한 커널에서 처리하는 상태에서 바로 디스크 IO로 전이 되는 과정에서 중간 동작이 없음
76. 한계점
Jmeter 사용과 본 PPT에서의 수치에 대한 이야기
사실 모든 데이터를 Jmeter에서 보내야 정확한 Throughput이 나온다
(보낸 데이터량 / latency)
하지만 본 실험에서 사용한 코드는 서버내 버퍼에서 각 용량을 생성해
파일에 입력하는 형태로 실제 Throughput이라 할 수 없다.
(단, 계획된 값으로 계산은 가능하다)