성능 테스트

Visual Studio .NET으로 분산 응용 프로그램 디자인

성능 테스트

특정 성능 요구 사항을 파악한 후에는 응용 프로그램이 이러한 요구 사항을 만족하는지 확인하는 테스트를 시작할 수 있습니다. 성능 테스트는 응용 프로그램이 안정적으로 작동하고 있으며 견고하다는 사실을 전제로 합니다. 이에 따라, 테스트 중에는 가능한 한 변수를 없애는 것이 중요합니다. 예를 들어, 코드의 버그는 성능 문제가 나타나도록 할 수도 있고 감출 수도 있습니다. 서로 다른 성능 테스트에 대한 결과를 비교하기 위해서는 응용 프로그램이 제대로 작동해야 합니다. 특히, 조정 과정을 거치면서 구성 요소의 구현이 수정된 경우에는 해당 응용 프로그램의 성능을 반드시 다시 테스트해야 합니다. 응용 프로그램에 대한 성능 테스트를 수행하기 전에 해당 응용 프로그램의 기능 테스트가 선행되어야 합니다. 응용 프로그램 자체의 변경 사항 외에도 하드웨어, 네트워크 소통량, 소프트웨어 구성, 시스템 서비스 등에서 예상치 못한 변수가 발생할 수 있습니다. 응용 프로그램에 대한 변수를 제어하는 일은 매우 중요합니다.

성능 측정

성능 테스트 정의

기준 성능 결정

스트레스 테스트

성능 문제 해결

성능 측정

성능을 정확하게 조정하려면 각 테스트 결과에 대해 정확하면서도 완전한 기록을 유지해야 합니다. 기록해야 하는 사항은 다음과 같습니다.

• 정확한 시스템 구성, 특히 이전 테스트 환경에서 변경된 사항
  
• 원시 데이터 및 성능 모니터링 도구에서 측정된 결과

이러한 기록 사항은 응용 프로그램이 성능 목표를 만족하는지를 나타낼 뿐만 아니라, 향후 발생할 수 있는 성능 문제를 파악하는 데 도움이 됩니다.

각 테스트 과정 중에 정확히 동일한 성능 테스트 항목을 실행해야 합니다. 그렇지 않을 경우, 서로 다른 결과가 나타난 이유가 테스트 환경의 변경으로 인한 것인지, 응용 프로그램의 변경으로 인한 것인지를 파악할 수가 없습니다. 성능 테스트의 설정을 가능한 한 자동화할 경우 운영자의 차이로 인한 변수를 제거하는 데 도움이 됩니다.

테스트가 시작될 때까지 응용 프로그램이 실행된 시간과 같이 사소한 요소도 성능 테스트의 결과에 영향을 줄 수 있습니다. 차가운 자동차 엔진이 뜨거운 엔진과 다른 성능을 나타내는 것과 같이, 장기 실행 응용 프로그램은 메모리 단편화 등으로 인해 새롭게 실행된 응용 프로그램과는 다른 성능 결과를 보여줄 수 있습니다.

성능 테스트 정의

성능 테스트 중에 성능 목표에 지정된 측정 항목에 대한 값을 측정하고 기록하십시오. 일고 시간, 트랜잭션 혼합 등과 같은 모든 성능 측정 항목을 만족해야 합니다. 이러한 제약 조건 내에서 테스트는 가능한 한 현실적인 상황을 반영해야 합니다. 예를 들어, 많은 클라이언트가 동시에 액세스를 시도할 때 응용 프로그램이 어떤 성능을 나타내는지 테스트합니다. 다중 스레드 테스트 응용 프로그램은 재현할 수 있는 방식으로 여러 클라이언트를 시뮬레이션할 수 있습니다. 여기에서 각 스레드는 하나의 클라이언트를 나타냅니다. 응용 프로그램이 데이터베이스에 액세스할 경우, 데이터베이스는 현실성 있는 개수의 레코드를 포함하고 있어야 하고 테스트는 데이터 입력에 대해 임의의(하지만 유효한) 값을 사용해야 합니다. 테스트 데이터베이스가 너무 작을 경우 데이터베이스 서버의 캐싱 효과에 대한 테스트 결과는 현실성이 없게 됩니다. 데이터가 비현실적인 방식으로 입력 또는 액세스될 경우에도 결과는 현실성이 없을 것입니다. 예를 들어, 새로운 데이터가 기본 키에 대해 알파벳 순서대로 생성될 가능성은 없습니다.

일반적으로, 테스트 환경에서는 트랜잭션 혼합, 일고 시간, 클라이언트 수 등과 같이 사용자별로 다를 수 있는 입력 매개 변수를 고려해야 합니다. 하지만, 테스트 환경 자체에서는 현실적인 데이터를 만드는 규칙을 지정할 수 있습니다.

응용 프로그램을 실행하기 위한 테스트 환경을 만든 후, 테스트 실행 시 동일하게 적용해야 할 모든 조건을 문서로 작성해 두어야 합니다. 이러한 조건은 최소한이라도 테스트 환경 실행에 필요한 입력 매개 변수를 포함해야 합니다. 또한, 테스트 실행에 대한 데이터베이스 설정 방법도 문서로 작성해야 합니다. 데이터베이스가 이전 테스트로 인해 변경된 사항을 포함하지 않도록 지침을 지정해야 합니다. 테스트에 사용된 컴퓨터 구성도 지정합니다. 이 설정은 프로덕션 환경과 더욱 가까우므로 응용 프로그램과 다른 별도의 컴퓨터에서 테스트 환경을 실행하십시오.

기준 성능 결정

성능 목표를 정의하고 성능 테스트를 개발한 후에는 테스트를 한 번 실행하여 기준을 설정합니다. 테스트 환경이 실제 프로덕션 환경과 가까울수록 배포 후 응용 프로그램이 안정적으로 작동할 확률이 높아집니다. 따라서, 처음부터 현실적인 테스트 환경을 만드는 것이 중요합니다.

운이 좋으면 기준 성능이 성능 목표를 만족할 수도 있으며 이 경우 응용 프로그램을 조정하지 않아도 됩니다. 이에 반해, 대부분의 경우 기준 성능은 만족스럽지 못합니다. 하지만, 초기 테스트 환경 및 기준 결과를 문서화할 경우 이에 따라 조정 작업을 쉽게 수행할 수 있습니다.

스트레스 테스트

특별한 형태의 성능 테스트인 스트레스 테스트는 다른 엔지니어링 분야의 파괴 테스트와 유사합니다. 스트레스 테스트의 목표는 응용 프로그램의 성능 저하를 넘어 리소스의 포화 사용 또는 오류 발생으로 인해 응용 프로그램을 더 이상 사용할 수 없을 때까지 프로세스 로드를 늘리는 것입니다. 스트레스 테스트는 응용 프로그램이 배포될 때까지는 쉽게 발견할 수 없는 사소한 버그들을 찾아내는 데 도움이 됩니다. 이러한 버그는 대개 잘못된 디자인으로 인해 생긴 것이므로 스트레스 테스트는 각 응용 프로그램 영역의 초기 개발 단계에서 시작해야 합니다. 이러한 미묘한 버그를 수정할 때에는 이러한 버그를 무시했을 때 응용 프로그램의 다른 곳에서 발생할 수 있는 관련 버그를 수정하는 것보다는 소스 자체를 수정하는 것이 좋습니다.

성능 문제 해결

성능 문제의 원인에는 하나 이상의 요인이 있을 수 있습니다. 따라서, 좋지 않은 성능에 대한 해결책을 찾는 것은 과학 실험을 하는 것과 매우 유사합니다. 과학 실험에서는 일반적으로 관찰, 가설, 예측, 테스트, 제어 및 이론으로 이루어지는 6단계의 과정을 따릅니다. 이론은 실험 과정에 의해 축적된 최적의 증명 정보로 뒷받침되는 가설로 구성됩니다. 이와 동일한 프로세스를 수행하여 성능 문제를 해결할 수 있습니다.

ASP 응용 프로그램에서 기대 이하의 성능이 나타난 경우 ASPProcessorThreadMax 메타베이스 속성이 너무 낮게 설정되었다고 가정합니다. 이것은 ASP Requests Queued 성능 카운터가 위, 아래로 이동하고 프로세서가 50% 이하에서 실행되고 있는 경우일 수 있습니다. 따라서, ASPProcessorThreadMax 메타베이스 속성의 값을 늘리면 성능이 향상될 것으로 예측할 수 있습니다.

이제 활성 스레드 설정을 제어할 수 있게 되었습니다. 눈에 띄는 성능 변화가 있을 때까지 한 번에 하나의 설정만 변경합니다. ASPProcessorThreadMax 메타베이스 속성을 조정한 후 기대 이상의 만족할 만한 성능이 나타난 경우, 현재의 모든 변수(예: 필요한 총 메모리 양, 실행되고 있는 응용 프로그램 수, 업그레이드된 소프트웨어) 하에서는 특정 속성 설정이 최상의 서버 성능을 제공한다는 이론을 세울 수 있습니다. 그렇다면, 변수의 변경이 이후의 실험 대상이 됩니다.

참고 항목

성능 | 응용 프로그램, 서버 및 보안 이벤트 기록 | 성능 임계값 모니터링 | 빌드, 디버그 및 테스트 | Performance and Scalability Testing | Understanding Performance Testing