4.1) 최악의 경우 서비스 가능한 양을 측정하는 것이 좋다. 그러기 위해서는 가장 많이 서비스 되면서 가장 무거운 기능을 타겟으로 삼는 것이 좋다. 단순히 홈페이지 접속만으로 테스트할 경우, index.html 같은 static file 만 테스트가 되므로 실제 상황에서는 대처가 안된다.
4.2) "타겟한 기능" 이 단일 프로세스에서 CPU 부하가 몇 % 인지 측정하기 위해,
ab -n 100 -c 1 으로 부하를 준다음, 서버에서 sar 로 cpu 부하를 측정한다.
참고 : 3.2 에서는, 가능하다면 1개의 Core 만으로 테스트 가능하면 좋다.
이유는하나의 트랜잭션이 0.03 초 같은 식으로 매우 짧을 경우인데,
CPU 가 여러개일 경우 각각 다른 CPU 에서 트랜잭션이 수행되면 CPU 부하를 측정하기 힘들기 때문이다.
4.3) 서버로 두개의 터미널을 띄운뒤,
한대에는 vmstat -t 1을 실행 ( 1 Core 일 경우 의미가 있음 )
한대에는 top 후 1 을 눌러서 Core 별 CPU 보이도록한다. ( MP 일 경우 의미가 있음 )
중요한 점은 ab 가 -c 1 이므로 1개의 Core 에만 몇 % 부하가 가는 지="단일프로세스Load측정치"를 확인한다.
만약, 서버 CPU 를 측정할 수 없다면, ab -g 옵션에서 wait 초="단일프로세스Load측정치"를 측정한다.
CPU 나 wait 가 많이 튈 경우 상하위 20% 씩 제거하고 나머지 60% 평균을 단일코어 1회 프로세스 타임으로 규정
4.4) 3.2 와는 동일하나 zip 모드에서 얼마나 걸리는가 추정 측정. zip 으로 인한 부하가 커서 오히려 느려질 수 있으니 3.1 과 3.2 의 평균중 에서 낮은 방식으로 이후 테스트 진행
ab -n 100 -c 1-H "Accept-Encoding: gzip, defalt" 으로도, CPU 혹은 wait"단일프로세스Load측정치"를 측정해 본다.
4.5) 이후 100% / CPU"단일프로세스Load측정치" 나1초 / wait단일프로세스Load측정치으로 나눈 수 X Core 수 = CPU 능력치 를 ab -c 에 대입한다.
ab -n 10000 -c CPU 능력치 -H "할지말지 선택" 으로 우선 테스트를 진행한다.
결과는 gnuplot.CPU능력치.result 로 저장.
이 경우 top 이나 vmstat 를 확인하여 CPU 가 Full Load 인지 확인한다.
4.6) 하이퍼 쓰레드가 반영이 되는 경우도 있으므로,
ab -n 10000 -c CPU 능력치 X 2 -H "할지말지 선택" 으로 우선 테스트를 진행해본다.
결과는 gnuplot.CPU능력치X2.result 로 저장.
이 경우 top 이나 vmstat 를 확인하여 CPU 가 Full Load 인지 확인한다.
