17. 도와주세요! 내 상사는 내가 우리 응용 프로그램을 로드 테스트하기를 원합니다! ¶
이것은 상당히 개방적인 제안입니다. 먼저 질문해야 할 질문이 많고 추가적으로 필요한 리소스도 많습니다. 벤치마크/부하 테스트를 실행하려면 일부 하드웨어가 필요합니다. 많은 도구가 유용할 것입니다. 고려해야 할 제품이 많이 있습니다. 마지막으로 Java가 부하 테스트/벤치마킹 제품을 구현하는 데 좋은 선택인 이유입니다.
17.1 물어볼 질문 ¶
예상 평균 사용자 수(정상 부하)는 얼마입니까?
예상 최대 사용자 수는 얼마입니까?
하나 이상의 서버가 충돌할 수 있다는 점을 염두에 두고 언제(예: 근무 외 시간 또는 주말) 애플리케이션을 로드 테스트하는 것이 좋은가요?
애플리케이션에 상태가 있습니까? 그렇다면 애플리케이션은 이를 어떻게 관리합니까(쿠키, 세션 재작성 또는 기타 방법)?
테스트의 목적은 무엇입니까?
17.2 리소스 ¶
다음 리소스는 매우 도움이 될 것입니다. 이러한 리소스 를 찾을 수 없는 경우 이러한 리소스가 됩니다. 이미 작업을 잘라 놓았으므로 다음 사람들이 누구인지 알고 필요한 경우 도움을 요청할 수 있도록 하는 것이 좋습니다.
17.2.1 네트워크 ¶
누가 우리의 네트워크 토폴로지를 알고 있습니까? 방화벽이나 프록시 문제가 발생하면 이는 매우 중요해집니다. 또한 개인 테스트 네트워크(따라서 네트워크 대기 시간이 매우 낮음)는 매우 좋은 것입니다. 누가 당신을 위해 설정할 수 있는지 아는 것은(당신이 이것이 필요하다고 생각한다면) 매우 유용할 것입니다. 애플리케이션이 예상대로 확장되지 않으면 누가 하드웨어를 추가할 수 있습니까?
17.2.2 적용 ¶
우리 응용 프로그램이 어떻게 작동하는지 누가 압니까? 정상적인 순서는
- 테스트(소량 - 애플리케이션을 벤치마킹할 수 있습니까?)
- 벤치마크(평균 사용자 수)
- 부하 테스트(최대 사용자 수)
- 파괴적으로 테스트 (우리의 하드 한계는 무엇입니까?)
17.3 벤치마크/부하 테스트를 실행하려면 어떤 플랫폼을 사용해야 합니까? ¶
이것은 표준(예: 바닐라) 소프트웨어 설치와 함께 널리 사용되는 하드웨어여야 합니다. 결과를 게시하면 고객이 가장 먼저 하는 일은 대학원생을 고용하여 결과를 확인하는 것임을 기억하십시오. 가능한 한 이 사람을 위해 쉽게 만들 수도 있습니다.
Windows의 경우 Windows XP Professional은 최소한이어야 합니다(다른 장치는 50-60개 연결을 다중 스레드하지 않으며 아마도 그보다 더 많은 사용자가 있을 것으로 예상합니다).
좋은 무료 플랫폼에는 linux, BSD 및 Solaris Intel이 포함됩니다. 돈이 조금 더 있다면 상용 리눅스가 있습니다. 지원이 필요한 경우 가치가 있을 수 있습니다.
Windows가 아닌 플랫폼 의 경우 사용자 계정 시작 스크립트( 테스트 계정의 경우 .bashrc 또는 .cshrc 스크립트)에 포함시키기 위해 " ulimit -n unlimited "를 조사하십시오.
또한 일부 Linux/Unix 에디션은 서버용입니다. 일반적으로 GUI 지원이 거의 없거나 전혀 없습니다. 이러한 OS는 CLI 모드에서 JMeter를 실행하는 데 적합해야 하지만 최소 GUI 환경을 설치하지 않으면 JMeter GUI 모드가 작동하지 않을 수 있습니다.
더 큰 규모의 벤치마크/부하 테스트로 진행함에 따라 이 플랫폼이 제한 요소가 될 것입니다. 따라서 사용 가능한 최고의 하드웨어와 소프트웨어를 사용할 가치가 있습니다. 게시된 벤치마크에 하드웨어/소프트웨어 구성을 포함하는 것을 잊지 마십시오.
많은 기계가 필요하거나 네트워크 대기 시간을 테스트하려는 경우 Cloud가 도움이 될 수 있습니다. JMeter는 클라우드에서 사용 가능한 거의 모든 아키텍처에서 실행되므로 클라우드 인스턴스에 쉽게 설치할 수 있습니다. JMeter는 직접 관리하지 않으려는 경우 Commercial Cloud PAAS 내에서도 지원됩니다.
JMeter 배치(CLI) 모드를 잊지 마십시오. 이 모드는 여러 가지 이유로 부하 테스트 중에 사용해야 합니다.
- Java를 지원하는 강력한 서버가 있지만 빠른 그래픽 구현이 없거나 원격으로 로그인해야 하는 경우.
- 배치(CLI) 모드는 원격 디스플레이 또는 클라이언트-서버 모드를 사용하는 것에 비해 네트워크 트래픽을 줄일 수 있습니다.
- GUI 모드에 사용되는 Java AWT 스레드는 때때로 차단하여 주입 동작을 변경할 수 있습니다.
17.4 도구 ¶
다음 도구는 모두 유용할 것입니다. 그들과 친해지는 것은 확실히 가치가 있습니다. 여기에는 이를 시도하고 적절한 문서(맨페이지, 정보 파일, 애플리케이션 --help 메시지 및 제공된 문서)를 읽는 것이 포함되어야 합니다.
17.4.1 핑 ¶
이것은 목표 사이트에 도달할 수 있는지 여부를 설정하는 데 사용할 수 있습니다. ' ping '이 ' traceroute ' 와 동일한 유형의 경로 보고를 제공 하도록 옵션을 지정할 수 있습니다 .
17.4.2 nslookup/dig ¶
사용자 는 일반적으로 사람이 읽을 수 있는 인터넷 주소를 사용 하지만 벤치마킹/부하 테스트를 수행할 때 DNS 조회의 오버헤드를 피하고 싶을 수 있습니다 . 이는 대상 사이트의 고유 주소(4점 점선)를 결정하는 데 사용할 수 있습니다.
17.4.3 경로 추적 ¶
대상 사이트를 " ping " 할 수 없으면 문제(방화벽 또는 프록시)를 확인하는 데 사용할 수 있습니다. 또한 전체 네트워크 대기 시간을 추정하는 데 사용할 수도 있습니다(로컬에서 실행하면 가능한 가장 낮은 네트워크 대기 시간을 제공해야 합니다. 사용자가 사용량이 많은 인터넷에서 실행될 것임을 기억하십시오). 일반적으로 홉이 적을수록 좋습니다.
17.5 JMeter를 어떻게 향상시킬 수 있습니까? ¶
JMeter와 함께 사용할 JMeter 플러그인 또는 기타 리소스를 제공하는 많은 오픈 소스 및 상용 제공업체가 있습니다. 이들 중 일부는 JMeter Wiki에 나열되어 있습니다. 다음과 같은 여러 범주에 나열됩니다.
- JMeterPlugins - JMeter 확장 플러그인
- JMeterAddons - 브라우저, Maven 및 Jenkins용 플러그인과 같이 JMeter와 함께 사용하기 위한 애드온입니다.
- JMeterServices - 타사 서비스(예: 클라우드 기반 JMeter)
17.6 왜 자바인가? ¶
Perl이나 C가 아닌 이유는 무엇입니까?
글쎄, Perl은 Benchmark 패키지가 상당히 모호한 결과를 제공하는 것 같다는 점을 제외하고는 매우 좋은 선택일 수 있습니다. 또한 Perl을 사용하여 여러 사용자를 시뮬레이션하는 것은 까다로운 제안입니다(다중 연결은 셸 스크립트에서 많은 프로세스를 분기하여 시뮬레이션할 수 있지만 스레드가 아니라 프로세스가 됩니다). 그러나 Perl 커뮤니티는 매우 큽니다. 누군가가 이미 유용해 보이는 것을 작성했다는 것을 알게 된다면 이것은 매우 좋은 해결책이 될 수 있습니다.
물론 C는 매우 좋은 선택입니다(Apache ab 도구 확인). 그러나 애플리케이션을 벤치마킹하는 데 필요한 모든 사용자 지정 네트워킹, 스레딩 및 상태 관리 코드를 작성할 준비를 하십시오.
Java는 애플리케이션을 벤치마킹하는 데 필요한 사용자 정의 네트워킹, 스레딩 및 상태 관리 코드를 (무료로) 제공합니다. Java는 RMI, IIOP 및 JDBC(쿠키, URL 인코딩 및 URL 재작성은 말할 것도 없음)뿐만 아니라 HTTP, FTP 및 HTTPS를 인식합니다. 또한 Java는 자동 가비지 수집 및 바이트 코드 수준 보안을 제공합니다.