성능 테스트를 추적하는 방법

Question

현재 다양한 변경 사항의 영향을 조사하는 복잡한 다계층 시스템의 성능 및 로드 테스트를 수행하고 있지만 모든 것을 추적하는 데 문제가 있습니다.

• 다양한 어셈블리의 복사본이 많이 있습니다.
  • 원래 릴리스된 어셈블리
  • 공식적으로 출시된 핫픽스
  • 추가 수정 사항을 포함하여 내가 만든 어셈블리
  • 추가 진단 로깅 또는 추적을 포함하여 빌드한 어셈블리
• 많은 데이터베이스 패치가 있습니다, 위 어셈블리 중 일부는 적용되는 특정 데이터베이스 패치에 따라 달라집니다.
• 다양한 로깅 수준이 존재합니다., 다양한 계층(애플리케이션 로깅, 애플리케이션 성능 통계, SQL 서버 프로파일링)
• 다양한 시나리오가 있습니다, 때로는 하나의 시나리오만 테스트하는 것이 유용할 때도 있고, 다른 시나리오의 조합을 테스트해야 할 때도 있습니다.
• 로드는 여러 시스템에 걸쳐 분할될 수 있습니다. 아니면 단일 기계만
• 데이터베이스에 있는 데이터는 변경될 수 있습니다., 예를 들어 일부 테스트는 생성된 데이터로 수행된 다음 나중에 실제 시스템에서 가져온 데이터로 수행될 수 있습니다.
• 각 테스트 후에 수집할 잠재적인 성능 데이터가 엄청나게 많습니다., 예를 들어:
  • 다양한 유형의 애플리케이션별 로깅
  • SQL 프로파일러 추적
  • 이벤트 로그
  • DMV
  • 성능 카운터
• 데이터베이스의 크기는 수 Gb입니다. 따라서 이전 상태로 되돌리기 위해 백업을 사용했다면 마지막 테스트 이후에 존재하는 데이터베이스에 변경 사항을 적용하는 경향이 있어서 빠르게 내용을 파악하지 못하게 됩니다.

나는 수행하는 각 테스트에 대해 최대한 많은 정보(테스트한 시나리오, 어떤 패치가 적용되는지, 데이터베이스에 있는 데이터)에 대해 최대한 많은 정보를 수집하지만, 일관성 없는 결과로 인해 여전히 테스트를 반복해야 합니다.예를 들어, 저는 몇 달 전에 실행한 테스트와 완전히 똑같은 테스트를 수행했지만 데이터베이스에는 업데이트된 데이터가 있었습니다.새 데이터로 인해 성능 저하가 발생한다는 사실을 알고 있지만 결과는 그 반대입니다.

동시에 나는 이러한 모든 세부 사항을 기록하는 데 너무 많은 시간을 소비하고 있음을 깨달았습니다.

제가 고려한 것 중 하나는 성능 데이터 등의 수집을 자동화하기 위해 스크립팅을 사용하는 것이었지만 이것이 그렇게 좋은 생각인지 확신할 수 없었습니다. 테스트하는 대신 스크립트를 개발하는 데 시간을 소비했을 뿐만 아니라 스크립트의 버그로 인해 문제가 발생할 수 있었습니다. 사물의 추적을 더 빨리 풀기 위해.

테스트 환경을 더 잘 관리하는 방법, 특히 수집 간의 균형을 유지하는 방법에 대한 조언/힌트를 찾고 있습니다. 모든 것 실제로 중요한 것을 놓칠 위험을 무릅쓰고 몇 가지 테스트를 수행하고 있습니까?

Answer 1

스크립트 테스트 매개 변수 + 환경 모음을 스크립팅하는 것은 확인하는 것이 좋습니다. 며칠 동안 테스트하고 스크립팅에 하루가 걸리면 시간이 잘 소요됩니다. 하루가 지나면 곧 끝나지 않을 경우 재평가 하고이 방향을 추구하지 않을 수 있습니다.

그러나 당신은 그것을 시도하기 위해 스스로에게 빚을지고 있습니다.

Answer 2

@orip에 동의하는 경향이 있으며, 작업량의 적어도 일부를 스크립팅하면 시간을 절약 할 수 있습니다. 노동 측면에서 가장 많은 시간이 소요되는 작업과 자동화에 얼마나 적합한 지 물어 보는 데 잠시 시간을내는 것을 고려할 수 있습니까? 스크립트는 특히 데이터를 수집하고 요약하는 데 능숙합니다. 일반적으로 사람들보다 훨씬 좋습니다. 성능 데이터에 많은 해석이 필요한 경우 문제가있을 수 있습니다.

이러한 작업 중 일부를 스크립팅하는 장점은 소스 / 패치 / 분기를 따라 확인할 수 있으며 시스템 복잡성의 조직 구조로부터 지금처럼 쫓아 내기 위해 고군분투하지 않고 혜택을 볼 수 있다는 것입니다.

Answer 3

관리자를 단순하게 유지하는 몇 가지 설정된 구성에 대해서만 테스트하면 됩니다.또한 깨끗한 기준을 제공하기 위해 신속하게 재배포할 수 있는 여러 가상 머신 각각에 하나씩 배치하는 것이 더 쉬워질 수도 있습니다.

설명하는 복잡성이 정말로 필요한 경우 다변량 결과를 쿼리할 수 있도록 간단한 데이터베이스를 구축하는 것이 좋습니다.각각의 중요한 요소에 대한 열이 있으면 "대기 시간이 가장 낮은 테스트 구성이 가장 낮은 테스트 구성은 무엇입니까?"와 같은 질문을 쿼리 할 수 ​​있습니다. 그리고 "어떤 테스트 데이터베이스가 대부분의 버그를 올릴 수 있었습니까?"이런 종류의 경량 컬렉션에는 sqlite3(아마도 Python 래퍼 또는 Firefox 플러그인을 통해)를 사용합니다. 왜냐하면 유지 관리 오버헤드를 상대적으로 낮게 유지하고 다음에서 실행해야 하는 경우에도 테스트 중인 시스템을 너무 멀리 교란시키는 것을 방지할 수 있기 때문입니다. 같은 상자.

테스트를 스크립팅하면 테스트 실행 속도가 더 빨라지고 이미 주문한 방식으로 결과를 수집할 수 있지만 시스템이 너무 복잡해서 이를 쉽게 수행할 수 없는 것 같습니다.