성능 테스트 팁

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

주제:

작성 대상:

경험
관리자
개발자

위의 모든 변경 사항의 효과를 평가하려면 라이브 전 및 향후 프로덕션 환경에 대한 주요 배포 전에 철저한 성능 테스트를 실행해야 합니다. 로드 테스트를 계획할 때는 가능한 한 실제 소비자 트래픽을 시뮬레이션하는 것이 중요합니다.

AEM/CIF/Adobe Commerce 사이트에서 가장 리소스를 많이 사용하는 영역은 체크아웃 프로세스 및 사이트 검색과 같이 캐시할 수 없는 영역입니다. PDP(Produce Detail Page) 및 PLP(Product Listing Page)와 같은 정적 페이지 찾아보기는 일반적으로 전자 상거래 사이트에 대한 트래픽의 대부분을 차지하므로 테스트의 스크립트 및 시나리오는 플랫폼의 제한을 측정하기 위해 이를 반영해야 합니다.

로드 테스트를 위해 단일 스크립트를 실행하며 단계 간 대기 시간 없이 사이트를 탐색하고 항상 체크아웃 프로세스를 완료해야 플랫폼 제한을 신뢰할 수 있게 나타낼 수 없습니다. 이는 실제 시나리오와 다르기 때문입니다.

KPI 정의는 성과 테스트 계획의 첫 번째 단계여야 합니다. 초기 테스트 동안 테스트할 수 있는 지표를 정의해야 하지만, 이후 및 사이트 라이브 후 반복해서 다시 측정할 수 있습니다. 이렇게 하면 론치 전과 론치 후 시간에 따른 사이트 성능의 성능을 추적할 수 있습니다. 정의할 KPI의 예는 다음과 같습니다.

평균 응답 시간 - 첫 번째 바이트 또는 마지막 바이트까지의 시간
지연
바이트/초(처리량)
오류율
시간당 주문 수
시간당 페이지 보기 수
시간당 고유 사용자(동시 구매자)

Jmeter 지침

AEM/CIF/Adobe Commerce 로드 테스트를 개발할 때 다음 Jmeter 높은 수준 지침을 고려해야 합니다.

스크립트를 다음과 같이 구성할 수 있는 시나리오로 분할합니다.
- 홈 페이지 열기
- PLP(Open Category Page)
- PDP(Simple Products) 보기 - 각 반복 내에서 2개의 루프
- 구성 가능한 제품 보기 - 각 반복 내 루프 2개
  - 예를 들어 위의 단계를 트래픽의 60%로 설정합니다
- 제품 검색
  - 예를 들어 카탈로그 검색을 트래픽의 37%로 설정합니다
- 장바구니 및 체크아웃
  - 예를 들어, 스크립트의 장바구니 및 체크아웃 부분을 완료하는 사용자는 기본적으로 업계 표준 전자 상거래 사이트 전환율이 약 3%여야 합니다
  - 체크아웃 흐름은 캐시되지 않고 일반적으로 리소스를 많이 사용하는 작업이므로, 주문을 완료하는 사람 수와 사이트 브라우저 수에 대해 비현실적으로 높은 수치를 설정하면 사이트에서 처리할 수 있는 트래픽 양에 대해 신뢰할 수 없는 결과가 발생합니다.
각 테스트 실행 전에 모든 캐시 정리:
- AEM Dispatcher 캐시를 완전히 정리해야 합니다.
- Adobe Commerce의 Fastly 및 내부 캐시를 완전히 플러시하고 정리해야 합니다. 이 작업은 Adobe Commerce 관리자의 캐시 제어를 통해 수행할 수 있습니다.
Jmeter 테스트에 램프 기간 포함: 램프 기간이 설정되어 있지 않으면 점차적으로 트래픽이 증가하지 않고 사이트에서 일반적으로 방문하는 페이지와 페이지의 구성 요소를 캐시할 기회가 없음을 의미합니다. 실제로 모든 피크 트래픽이 캐시되지 않은 사이트에 정확히 동시에 도착하는 것은 이례적입니다. 따라서 실제 전자 상거래 사이트에서 발생하는 것처럼 캐시를 빌드할 수 있도록 Jmeter 테스트 스크립트에 램프 기간이 포함되어야 합니다.
반복 내의 각 단계 간 "대기 시간"을 사용해야 합니다. 실제로는 사용자가 사용하지 않습니다
여정 중에 사이트의 다음 페이지로 즉시 이동 - 사용자가 페이지를 읽고 다음 작업을 결정하는 동안 대기 시간이 있습니다.
스레드 그룹을 무한 반복하도록 설정하되, x의 설정 시간(예: 60분) 동안 은 이전 테스트 실행과 비교할 수 있는 중간 응답 시간과 함께 반복 가능한 테스트를 제공합니다. 즉, 설정된 램프 설정 기간 후에 동시에 실행되는 가상 사용자의 목표 수가 있으며 이 수는 설정된 루프 시간 동안 계속됩니다.
평균 시간은 평균이 아닌 평균 응답 시간에 개선/감소를 제공하는 데 사용해야 합니다. If
다른 결과보다 훨씬 오래 걸리는 몇 가지 경계 결과가 있으므로 이 평균 결과가 왜곡될 수 있지만, 중간 측정값에 더 적합한 대다수 사용자의 최종 사용자 응답 시간에 관심이 있습니다.
포함된 리소스는 기본적으로 jmeter에서 수집되지 않습니다(예: JS, CSS 및 실제 사용자가 페이지를 방문할 때 다운로드된 기타 리소스). 이 기능을 활성화할 수 있지만, 테스트하는 도메인에 대해서만 외부 리소스 호출은 계속 제외해야 합니다(예: 외부 호스팅 서비스의 응답 시간은 포함하지 않음). google analytics 코드가 있습니다(제어할 수 없음).
HTTP 캐시 관리자를 활성화해야 합니다. 이렇게 하면 Jmeter가 여정 중에 페이지 요소를
실제 사용자의 여정은 자신의 브라우저에서 웹 사이트를 탐색하는 동안 발생합니다. 사이트를 통한 여정 중에 사용자의 브라우저가 관련된 임베디드 리소스를 한 번만 다운로드한 다음 사용자의 브라우저에 의해 캐시됩니다. 또한 동일한 사용자가 원래 방문 후 잠시 사이트를 재방문하는 경우에도 해당 에셋이 캐시되는 캐시가 될 수 있습니다.
리스너는 실제 로드 테스트 실행(예: "결과 트리 보기" 및 "집계 보고서") 내에 유지되어야 합니다. 비GUI 실제 로드 테스트 실행에 이러한 작업을 포함하면 실제 테스트 실행 중에 리소스를 사용하여 보고서를 생성하므로 Jmeter에서 보고하는 성능 결과에 영향을 줄 수 있습니다. 이러한 리스너는 테스트 스크립트에서 제거되어 JTL 결과 파일로 교체된 다음 Jmeter의 보고서 대시보드 기능을 사용하여 처리할 수 있습니다.
대시보드 보고서의 "Apdex 점수"를 테스트 실행 간 성능에 대한 변경 사항의 영향을 측정하는 빠른 방법으로 사용할 수 있도록 평가된 대상 응답 시간입니다. Apdex 점수는 견딜 수 있는 시간 내에 사이트에 액세스할 수 있는 특정 사용자의 수를 기반으로 합니다. 응답 시간이 어느 정도 '답답한' 양을 넘으면 점수가 낮아진다. 시간은 "apdex_consent_ threshold" 및 "apdex_tolerated_threshold" 매개 변수를 사용하여 설정할 수 있습니다.
가상 사용자 수가 아닌 비즈니스 사용자에게 표시할 대상 "시간당 주문 수" 지표를 설정하십시오. '가상 사용자'는 테스트가 실생활에서 측정하는 내용을 이해하기 위한 복잡한 주제가 될 수 있습니다. 사이트 전환율, 시간당 주문 수, 사용자가 사이트에서 소비하는 평균 시간 및 각 페이지 로드 사이의 시간 고려 사항을 계산하면 업계 표준 계산을 사용하여 달성 시간당 주문에 따라 다른 로드 테스트 시나리오를 표시할 수 있습니다.
마지막으로, Jmeter 테스트 서버는 대부분의 사용자 트래픽이 발생하는 위치와 클라우드 인프라가 호스팅되는 위치와 지리적으로 가까운 서버에서 실행되어야 합니다. 이러한 작업이 동일하기를 바랍니다.

recommendation-more-help

c45867ce-bc8d-4d1a-a7ec-97cb11ff17c6