고려대상
스레드풀 설정할때 고려할만한 대상은
CPU 코어개수
컨텍스트 스위칭 비용
DB 커넥션풀 개수
우리 서비스는 I/O 작업이 대부분 → 앵간한 로직수행에 전부 DB 커넥션이 필요하다. I/O block이 걸렸을때 다른 일을 수행할 수 있도록 커넥션보다 스레드 갯수가 많긴 해야한다. 근데 block시간이 짧으면 어차피 스레드 갯수가 많아도 그 스레드가 일할 시간이 딱히 없으니까 스레드가 많은게 의미가 없어보이기도 하고..
공식을 활용해볼까?
스레드풀을 설정하는데에 공식이 존재함
적정 스레드 개수 = cpu 수 (1+ 대기, 유휴 시간/서비스 시간)
적정 스레드 풀 개수 = CPU 수 (CPU 목표 사용량) * (1+대기 시간/서비스 시간)
ex) Worker 스레드는 요청에 대한 응답을 JSON으로 변환하고 몇 가지 규칙을 실행하는 microservice를 호출한다 가정. 응답 시간은 50ms, 서비스 시간은 5ms이며 worker 스레드를 실행시키는 프로그램은 듀얼코어 cpu라 가정한다면 적절 스레드 풀 사이즈는 2*(1+50/5)=22 가된다.근데 애매한 부분이.. 대기시간인데
메서드마다 처리시간이 달라서 스레드 대기시간이 다르다 이걸 평균 대기시간으로 해야할지 아니면 최대 대기시간으로 해야할지 고민.. 네트워크 상태에 따라서 응답시간도 다르던데..(근데 찾아보니까 자원 블로킹에 있어서 3순위 고려사항이라 계산에서 보통 제외시킨다고 한다.)
결국? 귀납법으로 가자.. 부하테스트
자바 최적화 도서를 살펴보면 CPU 코어 개수보다 스레드 개수가 많아지면 컨텍스트 스위칭이 발생하게 되는데 이 컨텍스트 스위칭 비용이 스레드 하나가 처리하는 비용보다 커지는 순간(병렬처리보다 하나로 처리할때가 더 효율적인 순간)의 스레드 개수가 적절하다고 한다.
그럼 스프린트 초반에 예상대로 부하테스트를 진행해야할 것 같은데 보통 CPU 2 부터 시작해서 돌려보면서 성능 그래프 추세를 보고 스레드 갯수 산정한다고 한다. 왜 CPU 2부터 시작하나 했더니 스레드들이 풀로부터 커넥션을 받기 위해 블록이 되어야 스레드 여러개인걸 잘 써먹을 수 있고 이렇게 블록이 걸리는 스레드의 적정개수는 데이터베이스가 동시에 처리할 수 있는 쿼리의 개수와 관련있다고 한다. 그리고 이건 CPU 코어 * 2 와 비슷한 숫자라고..
테스트 툴은?
JMeter나 ngrinder 사이에서 고민을 많이 했는데 결론은 Jmemter이다. 처음엔 부하테스트만을 위한 툴은 아니라서 기능이 많아 러닝커브가 있다고 해서 조금 쫄았다. 근데 사람들이 보편적으로 많이 사용하고 설치 및 사용이 직관적이라 해당 툴을 선택했다. 아무래도 레퍼런스가 많은게 처음 하는 입장에서 더 빠를 것 같아서.. 보니까 결과물을 GUI로 제공하는 플러그인이 있던데 TPS와 ResponseTime을 기준으로 성능이 꺾이는 지점을 찾아서 설정하는 방식으로 진행했다.
테스트 환경은?
우리 서비스는 예약이긴 하지만 우테코 내에서 제법 느긋하게 진행되는 면담예약 서비스라 사실 동접자가 많을 일이 그닥 없다. 그래서 한 기수인 120명과 여유분 30명을 더해서 총 150명이 1초에 10명씩 서서히 들어오게 설정했다. 테스트를 진행한 API는 데이터를 GET해오는 API인데 유의미한 성능차이를 보기 위해서 300개의 더미데이터를 넣어 실험했다.
https://kamang-it.tistory.com/399https://effortguy.tistory.com/164
https://kamang-it.tistory.com/607
