잘 쓰고 있습니다. 감사합니다.+ramp-up힌트

[sunghyun lim]

안녕하세요.
지난번에 연락드렸던 스펙트라의 임성현 입니다.
nGrinder를 통해서 잘 쓰고 있습니다. 진심으로 감사드립니다.
특히, jenkins/maven 연계를 통해서 성능테스트를 하려다보니
The grinder를 사용하는데, 정말 nGrinder가 많은 부분을 편하게 해 주셨더군요.

저희는 release 테스트, 차세대 엔진 개발때에 잘 쓰고 있습니다.
조만간 활용한 내용을 다른분들과 공유할까 합니다.

ramp-up에 대해서도 예제를 올려주셨는데,
(http://junoyoon.tistory.com/entry/nGrider-Thread-Sleep%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-TPS%EB%A5%BC-%EC%A0%90%EC%B0%A8%EC%A0%81%EC%9C%BC%EB%A1%9C-%EC%A6%9D%EA%B0%80%EC%8B%9C%ED%82%A4%EB%8A%94-%EB%B0%A9%EB%B2%95)
구동시 에이전트별 가상사용자수를 최대치로 주고 진행하시면 됩니다.
차근차근 보면 이해가 되는데, 가상사용자수를 1~2로 놓으면 알아서 증가할까 했었는데,
sleep를 주고 단계적으로 늦게 구동되는 방식이네요.

하나 더 요청드리면, 성능저하 구간이 몇 개의 thread가 구동할 때인지 그 정보가 있으면 더 좋을 것 같네요.

고맙습니다.

[junoyoon]

좋은 피드백 감사드립니다. ^^

말씀 하신데로 해당 램프업은 sleep 을 주고 단계적으로 늦게 구동되는 방식인데요.
프로세스 램프업와 혼용해서 쓰시면 몇개의 쓰레드가 활성화 될때부터 성능 저하가 일어나는지 확인하실 수 있습니다.
(그래프로는 나오지 않지만, 실시간 동작 화면상에는 "쓰레드 개수"로 출력되요.)

그러나 사실 Vuser 개수는 크게 중요하다고 생각되지는 않습니다.
저희가 NHN을 대상으로 가이드할 때는 되도록 스크립트에 sleep 을 주지않고
최대한 공격적으로 Load 를 주도록 가이드 하고 있습니다.
그런 다음에 계산된 TPS 최대치로 어느 정도의 동시 유저가 사용 가능한 시스템인지 알아내도록 합니다.
어짜피 Response 가 돌아오기 전에는 해당 쓰레드는 멈춰져 있기 때문이죠.

다른 도구가 가상 유저 기준으로 성능을 측정하는 반면, 저희는 시스템이 뱉을 수 있는 최대 TPS로 가능한 유저를 계산하도록 가이드 합니다.

NHN 은 성능 테스트를 현재 시스템 성능 보고 용도가 아닌 실제 성능 개선 용도로 수행하기 때문에
이런 접근 방법이 가능한것일 수도 있겠네요.