Zuul , could not acquire a semaphore..

어떤 이벤트로 인해 순간 트래픽이 치솟음. 

원인은 여러가지가 있는데 아래 해결책(의견)에 대해 비교해보고 싶어 작성함. 

 

max Semaphore를 늘려?

 

semaphore 디폴트 max는 100임

maxmax-concurrent-requests는 10임  

 

 

https://github.com/Netflix/Hystrix/wiki/Configuration

For example, 5000rps on a single instance for in-memory lookups with metrics being gathered has been seen to work with a semaphore of only 2.

예를 들어, 메트릭이 수집되는 메모리 내 검색을위한 단일 인스턴스에서 5000rps는 2의 세마포어로만 작동하는 것으로 나타남

(AIR는 중앙 DB를 사용중이므로 각 히스트릭스 semaphore 개수는 의미없고 총개수가 중요함)
(대부분 DB를 사용하므로 rps = tps라고 생각하면 될 듯)
싱글 인스턴스에서 100tps 의 성능이라고 한다면 semaphore 개수는 100개가 필요하다.

 

The logic that you use when you size a semaphore is basically the same as when you choose how many threads to add to a thread-pool, but the overhead for a semaphore is far smaller and typically the executions are far faster (sub-millisecond), otherwise you would be using threads.

세마포어의 크기를 조정할 때 사용하는 논리는 기본적으로 스레드 풀에 추가 할 스레드 수를 선택할 때와 동일하지만 세마포어의 오버 헤드가 훨씬 작고 일반적으로 실행 속도가 훨씬 빠르다.

즉, 스레드 풀 사이즈를 측정할 때를 참고하되 세마포어가 일반적으로 나은 성능을 보임. 

 

 

 

 

스레드풀 성능 측정?

https://yaaam.tistory.com/entry/%EC%8A%A4%EB%A0%88%EB%93%9C-%ED%92%80Thread-Pool-%EC%8A%A4%EB%A0%88%EB%93%9C-%ED%92%80%EC%9D%98-%EC%A0%81%EC%A0%95-%ED%81%AC%EA%B8%B0%EB%8A%94-%EC%8A%A4%EB%A0%88%EB%93%9C-%ED%92%80%EC%9D%98-%EC%A0%81%EC%A0%88%ED%95%9C-%EC%82%AC%EC%9D%B4%EC%A6%88%EB%8A%94

 

목표 사용량, 대기시간, 서비스 시간 등을 계산해봐야 함
2코어 * (1 + 50(대기시간)/5(서비스시간)) = 22

평균 응답 시간이 55ms 이고 스레드 풀 크기가 22이라면
22 / 0.055 = 400tps이다.

 

 

소견:

100tps 의 성능 기준으로 100개의 maxSemaphores 는 충분할 것으로 보임. (프로젝트 마다 다르지만)

로직의 성능을 개선하는게 우선임. 

 

 

 

 

 

좋은 블로그 글.

https://woowabros.github.io/experience/2017/08/21/hystrix-tunning.html

(작성 시기가 좀 오래돼서 변경된게 있음. semaphore가 default가 됨)