용량 계획을 위해서는 임계 성능 시험이 필요
이후 섹션에서는 시스템에 대한 실제 분석을 수행하는 데 사용되는 반복 프로세스를 설명한다. "프로세스" 이전의 섹션까지는 프로세스를 실행하는 데 필요한 중요 개념을 정의한다.
사용자 시나리오
많은 수의 사용자를 처리할 수 있도록 WebSphere Portal 시스템을 조정하고 적정 수준의 사용자 수를 처리할 수 있는 시스템의 성능을 정확히 예측하려면 시스템의 사용자에 대한 가장 개연성 높은 시나리오를 결정하는 것이 중요하다. 그런 다음 테스트에서 부하 생성기를 사용하여 사용자 시나리오를 정확히 시뮬레이션해야 한다. 이 단계를 효과적으로 수행하는 방법 중 하나는 개연성이 높은 사용 사례를 나열한 후 각 사용 사례에 대한 스크립트를 최대한 실질적으로 작성하는 것이다. 이제 전체 사용자 중에서 해당 시나리오를 실행할 사용자의 비율을 나타내는 확률을 할당한다. 그런 다음 테스트를 실행할 때 일반적으로 예상되는 사용자 수와 동일한 비율로 사용 사례를 Vuser에 할당한다. Vuser의 수가 포화 상태가 되면 이 비율을 유지한다.
참고: "Vuser"는 LoadRunner 용어로 요청이 발생하고 리턴되는 하나의 활성 채널을 의미한다.
대기 시간
대기 시간은 일반 사용자가 WebSphere Portal을 사용하는 중에 마우스를 한 번 클릭하거나 키를 한 번 누를 때 대기하게 되는 평균 시간이다. 부하 생성 도구에서 이 시간은 일반적으로 미리 정의된 범위 내의 임의 시간이 되도록 프로그래밍할 수 있다.
대기 시간이 줄어들면 초당 요청 수가 늘어나면서 시스템에 대한 부하도 높아진다. 대기 시간을 줄이면 일반적으로 WebSphere Portal 로그인 및 페이지 간 탐색의 평균 응답 시간이 늘어난다. 따라서 프로덕션 시스템을 정확히 모델링하려면 특히, 올바른 용량 계획을 마련하려면 실제 사용자의 대기 시간을 정확히 추정해야 한다.
대부분의 사용 사례에서는 숙련된 사용자가 사용하는 포털의 경우 10초를 기준으로 50%의 편차가 있는 대기 시간이 적당하다. 숙련되지 않은 사용자가 사용하는 포털의 경우에는 대기 시간이 30초에 가까울수록 좋다.
쿠키 및 세션
실제 사용자 중에서 포털에 로그인하여 필요한 작업을 수행한 후 로그아웃 단추를 사용하여 로그아웃하는 사용자는 거의 없다. 대신 해당 세션의 제한 시간에 도달할 때까지 브라우저를 유휴 상태로 두는 경우가 대부분이다. 메모리에 있는 많은 세션은 대개 제거되지 않은 채로 WebSphere Application Server 세션의 제한 시간에 도달할 때까지 유지된다. 이러한 작동 방식으로 인해 JVM(Java™ Virtual Machine) 힙 작업 세트가 늘어나며, 결과적으로 JVM의 힙이 소진될 수 있는 가능성이 높아진다. 힙 소진은 성능 병목 현상뿐 아니라 JVM 오류의 원인이 될 수 있다.
효과적인 시뮬레이션은 명시적으로 로그아웃하지 않는 사용자의 이러한 동작을 모델링해야 한다. 특정 사용 사례를 실행하는 개별 시뮬레이션에서는 로그아웃하지 않고 유휴 상태로 유지되는 사용 사례를 종료해야 한다. 스크립트 주기가 이 특정 Vuser의 새 사용자를 로그인하는 단계로 돌아오게 되면 해당 스크립트를 사용하여 다음 사용자를 로그인하기 전에 기존 세션(일반적으로 JSESSIONID) 및 LTPA(Lightweight Third-Party Authentication)에 대한 쿠키와 애플리케이션 관련 쿠키를 삭제해야 한다. 또한 이 모델에서는 테스트 ID가 WebSphere Application Server 세션의 제한 시간 동안 이전 세션의 제한 시간에 도달할 때까지 재사용되지 않고 유휴 상태로 유지될 수 있도록 충분한 개수의 테스트 ID가 있다고 가정한다.
측정 기준
측정 작업에 사용할 스크립트를 작성해야 한다. 가장 중요한 측정 기준은 초당 페이지 보기 수이다. 요청 응답 시간도 중요하다. WebSphere Portal에서는 로그인에 많은 리소스가 소요되므로 로그인 응답 시간과 페이지 간 응답 시간도 측정해야 한다. 대부분의 부하 생성기에는 종합적인 초당 페이지 보기 수(PV/s) 측정 결과를 제공하는 기능이 있다.
각 테스트가 완료된 후에는 분석 작업을 수행하기 위해 세 가지 측정 기준에 대한 Vuser의 증가율을 보여 주는 그래프가 필요하다.
부하 생성 도구에서 수집된 측정 결과와 함께 ITCAM(IBM Tivoli Composite Application Manager) for WebSphere 또는 Computer Associates Wily IntroScope 제품과 같은 시스템 모니터링 도구도 필요하다. 이러한 도구는 WebSphere Portal 인스턴스에서 실행되면서 JVM을 직접 측정한다. 이러한 도구는 시스템 병목 현상의 감지 및 해결에 모두 유용하다.
대기 시간과 대조되는 vUser
대기 시간이 짧은 요청을 생성하는 소수의 사용자만으로도 일정한 속도로 요청을 생성하는 많은 수의 사용자를 정확히 시뮬레이션할 수 있다고 오해하는 사람들이 많이 있다.
하지만 대기 시간이 짧은 상태에서 소수의 사용자만으로 실행하게 되면 캐시 적중 비율이 비현실적으로 높게 나온다는 것을 알아야 한다. 이는 생성되는 세션 또한 소수에 불과하다는 것을 의미한다. 세션 크기가 많은 포틀릿 애플리케이션에서 심각한 문제이기도 하므로 이러한 방식으로 테스트를 수행하게 되면 시스템 성능이 비현실적으로 아주 좋게 나오기 마련이지만 프로덕션 환경에서는 황당한 결과가 발생하게 된다는 점을 염두에 두어야 한다.
대기 시간 없이 소수의 vUser 세트를 실행하는 경우도 현실을 고려하지 않은 방법 중 하나이다.
반복 가능성 원칙
사용자 수가 많은 경우 사용자가 포털을 탐색할 때 대부분의 사용자 동작이 특별한 규칙 없이 무작위로 나타날 것이라고 가정하기 쉽다. 하지만 경험이 많은 사용자는 대개 동일한 패턴을 사용하는 경향이 있다. 또한 테스트 엔지니어링 관점에서 보면 사용자 시나리오가 어느 정도 고정되어 있어야만 각 실행 사이의 시스템 변경 사항을 효과적으로 측정할 수 있다.
따라서 반복 가능성 원칙은 실행이 충분히 긴 경우 특정 시나리오의 모든 실행에서 산출된 측정 결과(평균 응답 시간, PV/s, 포화점 등)가 동일한 결과로 수렴되는 것이라고 정의할 수 있다. 테스트 스크립트에 추가 변형(즉, 고유 시나리오)이 있는 경우에는 횟수가 늘어날수록 평균에 수렴하게 된다.
성능 테스트를 위해 작성된 시뮬레이션 스크립트는 반복 가능성 원칙을 따라야 한다.
포화점은 Vuser를 추가하더라도 PV/s 값이 증가하지 않는 상태에 도달한 시점에 존재하는 활성 Vuser의 수로 정의된다. 이 포화점은 지정된 시뮬레이션에만 적용되며 각 시뮬레이션에는 각기 다른 포화점이 적용된다. 포화점은 사용 패턴에 따라 달라진다.
시스템을 효과적으로 포화 상태에 도달하게 만들려면 한 번에 소수의 Vuser를 추가한 후 시스템이 안정화될 때까지 기다리면서 PV/s가 증가하는지 확인한 후 Vuser를 다시 추가하는 것이 좋다. (여기에서 "안정화"는 응답 시간이 수 분 동안 일정한 수준으로 유지되는 것을 의미한다.) LoadRunner의 경우 Vuser를 처리 속도(PV/s)에 대해 구성하면 PV/s는 처음에 Vuser의 수에 따라 선형으로 높아지다가 최대값에 도달하게 되면 그때부터 조금씩 낮아진다. 포화점은 PV/s가 최대값에 도달했을 때의 Vuser의 수이다.
