 | |
|
웹 애플리케이션 성능 측정하기
웹에 공개하기 전에, 대부분의 애플리케이션은 개인 컴퓨터의 "로컬(local)"에서 수행된다. 이러한 애플리케이션의 벤치마킹(benchmarking)이나 성능 측정은 상당히 간단하다. 프로세서 속도나 메모리의 양을 일정하게 측정할 수 있다면, 코드 변경과 다양한 컴파일러의 영향을 쉽게 측정할 수 있다. 유닉스 기반 시스템에서는 명령행, 셸 스크립트와 반복적으로 수행되는 테스트와 그 결과를 기록하는 리치 프레임워크(rich framework)가 제공되는 유틸리티가 있으면 훨씬 좋다.
웹 애플리케이션인 경우 대부분 많은 컴포넌트가 웹, 좀 더 정확히 말하자면, HTTP 오퍼레이션의 수행에 관련되어 있기 때문에 위의 상황과는 매우 다르다. 구성요소에는 로컬 웹 브라우저, 네트워크, 웹 서버, 원격 호스트, 웹 애플리케이션, 그리고 데이터베이스 같은 "변경 요소(moving part)"가 포함된다. 웹 애플리케이션 성능 측정시에는 영향을 받을 수 있는 많은 요소, 예를 들어, LAN에서 테스트를 수행하면 쉽게 얻을 수 있는 것을 최소화할 필요가 있다. 그렇지만, 어떻게 테스트를 반복할 것인지가 여전히 논쟁거리이다.
이클립스 TPTP URL 도구는 웹 애플리케이션의 상호작용을 자동화하고 벤치마크하도록 고안되었다. URL 도구는 프록시를 통해 각각의 "클릭"을 기록할 수 있고, 요청과 응답 사이의 지연 시간을 측정할 수 있다.
URL 도구 사용하기
Listing 2는 웹 서버와 연동되어 돌아가는 반복 테스트가 가능한 간단한 PHP 애플리케이션을 보여준다. 이 애플리케이션에서는 1/4초, 1/2초, 1초 재우기(sleep)를 선택할 수 있다. 이 코드를 DocRoot에 위치시키자.
Listing 2. 간단한 PHP 애플리케이션
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Consume Cycles Example</title>
</head>
<body>
<?php
$time = 0;
switch($_GET['mode'])
{
case 'short':
$time=250;
break;
case 'medium':
$time=500;
break;
case 'long':
$time = 1000;
break;
}
$time *= 1000;
if ($time > 0) {
usleep($time);
print "<p>I snoozed for $time microseconds</p>";
}
?>
<h3>Choose how long you want the application to sleep:</h3>
<ul>
<li><a href="index.php?mode=short">A short time</a></li>
<li><a href="index.php?mode=medium">A little while</a></li>
<li><a href="index.php?mode=long">A long time</a></li>
</ul>
</body>
</html>
|
로컬 머신의 $DOCROOT/burn/index.php에 이 PHP 코드를 배치하고, 웹 브라우저 주소 창에 http://localhost/burn/index.php를 입력하자(그림 2). 링크를 클릭하고, Back을 클릭하면 다시 index 페이지로 돌아온다.
그림 2. 벤치마크를 위한 PHP 애플리케이션
URL 테스트 빌드하기
Listing 2처럼 PHP 애플리케이션 측정을 위한 테스트 작성부터 시작해보자. 이클립스를 실행하고, PHP라는 이름의 새 general project를 만들자.
브라우저 세션 기록하기
먼저 이클립스의 Preferences에 브라우저와 프록시 포트를 설정하자. 이클립스는 프록시를 시작하고, 프록시를 통해 모든 트래픽을 돌리기 위해 브라우저를 자동으로 설정하고, 실행하는 데 이 설정 값을 사용한다. 프록시가 HTTP 기록에 매우 유용하다는 것을 앞으로 알게 될 것이다. Preferences를 설정해보자.
-
Window > Preferences를 클릭하고, Test를 확장하자. 그 다음 HTTP Recording을 클릭한다.
- 그림 3처럼 가장 오른쪽에 있는 설정을 변경하자.
그림 3. 브라우저와 프록시 설정
그림 3에 있는 설정을 사용해 HTTP Recorder가 모질라를 띄우고, (SOCKS 4) 프록시에 접속하기 위해 1080 포트를 사용한다.
-
OK를 클릭하자.
-
New > Other를 클릭하고, Test를 확장하자. 그 다음 Recording을 확장하고, HTTP Recording을 선택하자. 이제 화면은 그림 4와 같을 것이다.
그림 4. 새로운 HTTP Recoding 만들기
-
Next를 클릭하자.
- Recoding 파일은 이름은
Simple로 하고, Finish를 클릭하자.
바로 이클립스 화면에 Recorder Control 패널(그림 5)과 빈 모질라 창이 나타날 것이다(이미 모질라의 Preferences가 열려 있다면, 사용하기 위해 설정된 프록시를 발견할 수 있다).
그림 5. HTTP Recording 제어를 위한 Recorder Control 패널
- 모질라 창으로 포커스를 변경한 다음, 예제 PHP 애플리케이션의 URL, 예를 들어
http://localhost/burn/index.php를 입력하자.
애플리케이션이 브라우저에서 바로 실행되는 것을 볼 수 있다.
-
A short time 링크를 클릭한 다음, Back을 다시 클릭하자.
-
A little while을 클릭하고, Back을 클릭하자.
-
A long time을 클릭하자.
- 다시 이클립스로 돌아와서 Stop recording을 클릭하자(그림 5의 제일 오른쪽에 있는 빨간 정사각형).
이클립스는 기록을 멈추고, Simple.testsuite라는 새로운 테스트 케이스를 생성한다. 또한 기록을 저장한다. 이제 이클립스 창은 그림 6과 같을 것이다.
그림 6. HTTP 성능 측정 테스트 스위트
획득한 HTTP 테스트 다시 검토하기
HTTP Requests 탭(가장 위 패널의 아래쪽)을 클릭하고, 획득한 네 개의 HTTP 요청 중 하나를 선택하자. 이클립스 창을 확장하면 그림 7처럼 해당 요청에 대한 매우 자세한 정보를 볼 수 있다. 헤더 정보를 추가하거나 GET 매개변수를 변경하는 등 요청 정보를 변경하기 위해 HTTP Requests 뷰를 사용할 수도 있다. 이번 페이지의 요청은 테스트 스위트의 동작을 정의하는 다음 단계에서도 사용될 것이다(처음으로 획득한 HTTP request를 액션으로 생각해보면, 커스터마이징이 필요할 수도 있다. 테스트 스위트는 웹 애플리케이션을 구동하기 위해 액션을 사용한다).
그림 7. 일련의 HTTP 요청 수정하기
이제 Behavior 탭을 클릭하고, 모든 화살표를 눌러 확장하자. 루프 제어(loop controls)는 recycle 아이콘으로 체크할 수 있다. 여기서 (바로 전에 수정한) HTTP 요청은 액션이다. 이제 추가적인 단계(step)를 추가(add), 삭제(remove), 재정렬(reorder), 삽입(insert)할 수 있다(Add는 새로운 자식, 즉 하위 수준의 단계를 만드는 것이고, Insert는 새로운 형제(sibling), 즉 동일한 수준의 단계를 만드는 작업이다). loop를 클릭한 다음, request를 클릭하자. 그림 8처럼 각각의 속성 패널을 볼 수 있다.
그림 8. loop와 request 수정하기
이 두 개의 패널 수정은 화면 자체로 대부분 설명된다. 이 패널에서 루프의 반복(iteration)을 조정하고, 요청의 자세한 정보를 수정할 수 있다. 또한 기타 테스트 스위트에 있는 다른 테스트를 포함시킬 수도 있다. 이렇게 하기 위해서는 가장 왼쪽의 맨 위에 있는 Loop 1을 클릭하고, Number of iterations를 10으로 변경하자. 수행한 작업을 저장하기 위해 Ctrl+S를 사용하자.
테스트 스위트 컴파일
테스트 스위트를 실행하기 위해, 반드시 테스트 케이스를 자바 코드(실제로는 JUnit 테스트)로 변환해주는 작업인 컴파일을 해야 한다. 스위트를 실행하기 위해, 현재 워크스페이스에 자바 프로젝트를 생성하고, 이름은 Testing으로 한다. 테스트 스위트에서 자바 코드를 생성하려면 다음 과정을 거쳐야 한다.
-
Windows > Open perspective를 클릭해 Test perspective로 변경하고, 메뉴를 이동해 Test를 선택한다.
그림 9처럼 이클립스 창에서 Test Navigator를 제공해 Test를 변경할 수 있다.
그림 9. Test Navigator
-
Simple에서 마우스 오른쪽 버튼을 클릭하고, Generate를 클릭하자. 그러면 그림 10과 비슷한 창이 나타날 것이다.
그림 10. HTTP recording에서 JUnit 테스트 생성하기
-
Browse 버튼을 클릭하고, Testing Java project를 선택하자.
-
Finish를 클릭하자. Testing 프로젝트에 폴더 두 개가 보인다.
- 다음 작업을 계속하기 전에, perspective를 다시 Java perspective로 변경한다.
URL 테스트 실행하기
이제 웹 애플리케이션 성능 측정 테스트를 실행할 준비가 되었다. 이클립스 TPTP 도구는 URL 테스트를 자바 코드로 변환해 준다. 그러기 위해서는 반드시 다음 코드를 실행해야만 한다.
- Testing 프로젝트에서 화살표를 눌러 확장하고, Simple.java라는 이름의 자바 클래스가 들어 있는, test라는 폴더 옆에 있는 화살표를 클릭해 확장하자.
만약 Simple.java를 확장했다면, 전통적인 JUnit 테스트와 매우 비슷한 코드를 볼 수 있을 것이다.
- Simple.java에서 마우스 오른쪽 버튼을 클릭하고, Run As > JUnit test를 클릭하자.
결과는 그림 11과 같다. 테스트 결과 막대는 초록색이고, 총 40개 테스트가 성공적으로 수행되었다.
그림 11. HTTP 성능 측정 테스트 스위트의 실행 결과
JUnit으로 테스트를 실행하면 작업을 테스트한 것을 증명할 수는 있지만, 가치 있는 측정 기준을 얻으려면 이클립스 TPTP 테스트로서 테스트를 실행해야만 한다. 이렇게 하기 위해서는 다시 Test perspective로 변경하고, test 폴더에서 마우스 오른쪽 버튼을 클릭한 후, Run As > Run을 클릭하자. 다음 창에서 Test를 확장하고, Simple을 선택하자. 이 시점에서 가장 오른쪽의 패널은 그림 12와 같을 것이다. Run을 클릭한다. 테스트가 완료될 때까지 그림 13에서 볼 수 있는 진행률 표시 막대(progress meter)가 화면에 남아 있을 것이다.
그림 12. HTTP 성능 측정 테스트 스위트 실행
그림 13. 진행률 표시 막대
결과 분석
지금까지 웹 세션을 획득해, 테스트 스크립트를 만들고, 이 스크립트에서 테스트 케이스를 생성하고, 실행해 봤다. 다음 단계는 실행 결과를 분석하는 단계다.
Test perspective는 이제 Simple이라는 이름의 테스트 로그라는 새로운 자원(resource)을 받게 된다. 로그를 열기 위해 더블 클릭을 하자. 이클립스 워크벤치는 그림 14처럼 보일 것이다.
그림 14. 테스트 스위트 실행에 대한 로그
Events 탭을 클릭하고, loops를 확장하고, 그림 15처럼 보이는 페이지를 찾아 보자.
그림 15. 테스트 스위트 실행에 대한 이벤트
각각의 항목에는 매우 유용한 정보가 들어 있지만, 각각이 반응 시간(1/1000초)을 보고하기 때문에 메시지 엘리먼트에 있는 내용이 가장 흥미로울 것이다. 각 요청이 얼마나 걸렸는지 보기 위해 몇 개의 invocation 엘리먼트를 열어보자. 테스트 대상이 된 단순한 예제에서는 매우 빠른 반응 시간(index 페이지를 열어보면 알 수 있다)을 보여줬고, 오랜 시간 동안 재우는 테스트를 선택했을 때는 매우 긴 반응 시간을 보여줬다.
리포트 생성
이클립스 TPTP HTTP 성능 측정 도구는 테스트를 더 풍부하게 해주는(trick up its sleeve) 더 좋은 방법을 가지고 있는데, 그 방법은 바로 리포트다. 새로운 테스트 스위트를 실행하려면 세 배에서 네 배의 시간이 필요하다. 각각의 실행은 자신만의 로그를 갖는다. 리포트를 요약하려면 다음 단계를 거쳐야 한다.
- Test Naviator에 있는 Simple에서 마우스 오른쪽 버튼을 클릭하고, Options를 클릭하자.
-
Report를 선택하자.
- 다음 창에서 아래 그림처럼 HTTP Page Response Time을 클릭하자.
그림 16. 선택된 리포트의 리스트
만약 웹 애플리케이션의 반응을 측정하기 위해 엄청난 노력을 한다면, HTTP Recorder가 가장 알맞은 대안이 될 수 있다. HTTP Recorder 외에도 link validator(즉 링크가 제대로 작동하는지 여부를 결정함), 사이트 "heartbeat"(즉 모니터링 기능), 그 외에 사용하기에 적당한 것들을 찾을 수 있다.
| |
