<aside> 💡 진입장벽이 높던 성능 테스트가 쉽다 못해 하고 싶어지게 된다면 얼마나 좋을까?

</aside>

성능 테스트 상식

1. 스트레스 테스트

   • 로드 상황에서 크래시 등의 문제점 확인
   • 예시

2. 로드 테스트

   • 로드 상황에서 어떤 성능 특성(수치 등)을 보여주는지 파악
   • 예를 들면, 해당 시스템이 얼마만큼의 트랜잭션을 처리할 수 있는지…
   • 예시

3. TPS (Transaction Per Second / 초당처리량)

   • 해당 서버가 초당 얼마만큼의 트랜잭션을 처리할 수 있는지
   • Transaction은 성능 테스트 수행자가 정의하기 나름이다. ⭐
     • http 콜 한 번을 의미하는지, 사용자 시나리오 한 번을 의미하는지 등
     • 어떤 연속된 요청 자체를 하나의 트랜잭션으로 정의할 수도 있고, 콜 한 번을 트랜잭션으로 정의할 수도 있다.
     • 그래서 내가 정의하는 트랜잭션은 무엇인가? 팀과 함께 공유해야한다. ⭐

4. 로드를 주는 방법

   1. ApacheBench? LoadRunner?
   2. NHN과 같은 대규모 서버군에는 부적절…

5. 분산 테스트 환경

   

   • 사용자는 컨트롤러를 통해서 로드를 발생
   • 로드를 발생시킬 스크립트를 로드 생성기로 전달
   • 로드 생성기는 테스트 대상 서버에 부하를 준다

6. 성능 테스트 도구는 실수까지 기록하여야 한다 ⭐

   1. 실수는 성능 테스트를 실행하는 자의 실수를 말한다…

   2. 성능 테스트 결과는 계속 덮어쓰여지기 때문에 따로 기록해두어야 파악이 용이하다

      → nGrinder를 개발할 때 이 부분을 신경 썼다는 듯?

7. 서버에 부하를 주는 것이니 신중할 것

nGrinder 살펴보기

동작 방식

• 컨트롤러(=웹을 담당) - 스크립트 작성

  → 스크립트가 에이전트로 배포

  → 에이전트가 테스트를 위한 서버에 버닝 🔥 (= 공격)

위의 내용을 에이전트 입장에서 보면…