웹 응용 프로그램에서 스트레스 테스트를 수행합니까?

과거에는 웹 응용 프로그램을 스트레스 테스트하기 위해 Microsoft 웹 응용 프로그램 스트레스 도구와 Pylot을 사용했습니다. 간단한 홈페이지, 로그인 스크립트 및 사이트 연습 (전자 상거래 사이트에서 장바구니 및 결제에 몇 가지 항목을 추가)을 작성했습니다.

소수의 개발자로 홈페이지를 강타하면 거의 항상 큰 문제가 발생합니다. 더 많은 확장 성 문제는 두 번째 단계에서, 그리고 출시 이후에는 더 커질 것입니다.

내가 사용한 도구의 URL은 Microsoft Homer (일명 Microsoft Web Application Stress Tool )와 Pylot 입니다.

이 도구들에 의해 생성 된 보고서는 제게 의미가 없었으며, 사이트가 어떤 종류의 동시로드를 지원할 수 있는지 알아 내기 위해 많은 시간을 할애했습니다. 가장 멍청한 버그와 병목 현상이 항상 발생하기 때문에 항상 가치가 있습니다 (예 : 웹 서버 구성 오류).

당신은 무엇을했으며, 어떤 도구를 사용했으며, 접근 방식으로 어떤 성공을 거두었습니까? 나에게 가장 흥미로운 부분은 스트레스 테스트 응용 프로그램에서보고 한 숫자에서 앱이 지원할 수있는 동시 사용자 수를 계산하기위한 일종의 의미있는 공식입니다.

JMeter에 대한 또 다른 투표가 있습니다.

JMeter는 Java로 작성된 오픈 소스로드 테스트 도구입니다. 웹, 웹 서비스, 데이터베이스, 기본적으로 요청을 사용하는 모든 것 등 다양한 서버 유형을 테스트 할 수 있습니다.

그러나 복잡한 테스트를 시작하면 학습 곡선이 가파르지만 그만한 가치가 있습니다. 매우 빨리 시작하고 실행할 수 있으며, 어떤 종류의 스트레스 테스트를 원하느냐에 따라 괜찮을 수 있습니다.

장점 :

• Apache 프로젝트의 오픈 소스 / 무료 도구 (바이 인 지원)
• 핵심 개념을 이해하면 시작하기 쉽고 사용하기 쉽습니다. (즉, 요청 작성 방법, 어설 션 작성 방법, 변수 작업 방법 등).
• 확장 성이 뛰어납니다. 나는 서버에 부하를 생성하는 11 대의 기계로 시간당 거의 백만 명을 기록한 테스트를 수행했습니다. 내가 생각했던 것보다 설정 이 훨씬 쉬웠습니다.
• 활동적인 커뮤니티와 좋은 리소스를 통해 시작하고 운영 할 수 있습니다. 먼저 튜토리얼을 읽고 잠시 동안 재생하십시오.

단점 :

• UI는 Swing으로 작성되었습니다. (웃음)
• JMeter는 서버에서 반환 한 응답 텍스트를 구문 분석하여 작동합니다. 따라서 모든 종류의 자바 스크립트 동작을 확인하려는 경우 운이 좋지 않습니다.
• 비 프로그래머에게는 학습 곡선이 가파 릅니다. 정규식에 익숙하다면 이미 게임보다 앞서 있습니다.
• 지원 포럼에는 바보 같은 질문을하는 많은 ( 삽입 expletive ) 바보가있어서 문서를 한 눈에 볼 수 있다면 쉽게 해결할 수 있습니다. ( 'JMeter를 사용하여 Windows GUI 스트레스 테스트를 수행하는 방법'은 매우 자주 나타납니다).
• '즉석에서'보고하는 것은 특히 큰 테스트의 경우 바람직하지 않습니다. 위에서 언급 한 테스트에서 'xml-logfile'을 'html'로 변환하는 빠른 콘솔 응용 프로그램을 작성해야했습니다. 그러나 몇 년 전 이었으므로 더 이상 필요하지 않을 것입니다.

나는 그라인더를 사용했다 . 오픈 소스이며 사용하기 쉽고 구성이 매우 쉽습니다. Java 기반이며 스크립트에 Jython을 사용합니다. 우리는 그것을 .NET 웹 응용 프로그램에 대해 실행 했으므로 Java 전용 도구라고 생각하지 마십시오 (자연적으로 웹 스트레스 도구는 사용하는 플랫폼에 묶여서는 안됩니다).

우리는 그것으로 몇 가지 깔끔한 작업을 수행했습니다 ... 우리는 웹 기반 통신 응용 프로그램이었습니다. 따라서 멋진 사용법은 웹 응용 프로그램을 통해 전화 번호를 모방 한 다음 자동 응답 도구를 사용하는 것입니다 (기본적으로 자습서였습니다) RTC LCS 서버에 연결하기위한 Microsoft의 앱 (이것은 Microsoft Office Communicator가 로컬 네트워크에서 연결하는 것입니다. 자동으로 전화를 받도록 수정되었습니다) 이를 통해 우리는 The Hammer (또는 이와 유사한 것)라고하는 비싼 전화 도구 대신에 이것을 사용할 수있었습니다.

어쨌든 우리는이 도구를 사용하여 응용 프로그램이 높은 부하에서 어떻게 유지되는지 확인했으며 병목 현상을 찾는 데 매우 효과적이었습니다. 이 도구는보고에 시간이 얼마나 걸리는지를 보여주는보고 기능을 내장하고 있지만 사용하지는 않았습니다. 로그는 모든 응답 및 기타 정보 또는 사용자 정의 로깅을 저장할 수도 있습니다.

가격에 매우 유용한이 도구를 강력히 권장하지만 ...이 도구를 사용하여 일부 사용자 정의 설정을 수행 할 것으로 예상합니다 (스크립트를 기록하기 위해 프록시가 내장되어 있지만 세션과 같은 것을 캡처하려면 사용자 정의가 필요할 수 있습니다 ... 스레드 당 고유 한 세션을 사용하도록 사용자 정의해야했습니다.)

이 파티에 조금 늦었 어 필자는 Pylot 이 최고의 최신 오픈 소스 도구 라는 데 동의합니다 . 사용하기 쉽고 훌륭한 사람 ( Corey Goldberg ) 이 적극적으로 노력하고 있습니다. OpenQA 의 창립자 인 Pylot이 현재 홈페이지에 등록되어 있으며 일부 인프라 (포럼)를 사용하고 있습니다.

그러나 최근에는로드 테스트의 전체 개념에 결함이 있음을 결정했습니다. 애플리케이션이 복잡해지면서 HTTP 트래픽을 에뮬레이트하는 것은 어려운 일입니다. 이것이 상용 도구 인 BrowserMob을 만든 이유입니다. Selenium 을 사용 하여로드를 재생할 때 실제 웹 브라우저를 제어 하는 외부로드 테스트 서비스 입니다 .

접근 방식은 분명히 필요 t 정상 부하 테스트 기술보다 더 많은 하드웨어를하지만 클라우드 컴퓨팅을 사용하는 경우 하드웨어는 꽤 저렴 사실입니다. 그리고 이것의 좋은 부작용은 스크립팅이 일반적인로드 테스트보다 훨씬 쉽다는 것입니다. 쿠키, .NET 세션 상태, Ajax 요청 매개 변수 등을 추출하기 위해 JMeter와 같은 고급 정규식 일치를 수행 할 필요가 없습니다. 실제 브라우저를 사용하기 때문에 수행해야 할 작업 만 수행합니다.

상업용 제품을 뻔뻔스럽게 발표 한 것은 유감이지만,이 개념이 일부 사람들에게는 흥미롭고 적어도 추가 하드웨어에 액세스 할 때로드 테스트를 처리 할 수있는 새로운 방법에 대해 생각하게 할 것입니다!

JMeter 사용했습니다 . 웹 서버를 테스트하는 것 외에도 데이터베이스 백엔드, 메시징 서비스 및 이메일 서버를 테스트 할 수 있습니다.

ab , 공성 , tsung , httperf , Trample , Pylot, 요청 로그 분석기 , perftools

간단한 사용법을 위해, ab (apache 벤치 마크)와 포위 공격을 수행합니다. 나중에 쿠키를 지원하지 않으며 동적 사이트에서 끝없는 세션을 생성하므로 나중에 하나가 필요합니다.

둘 다 시작하는 것이 간단합니다.

ab -c n -t 30 url

siege -b -c n -t 30s url

포위 공격은 더 많은 URL로 실행될 수 있습니다.

마지막 포위 공격 버전은 siegerc에서 장황하게 표시됩니다. 해당 파일을 편집해야만 비활성화 할 수 있습니다 ( /usr/local/etc/siegerc).

웹 기반 서비스의 경우 loader.io를 확인하십시오 .

요약:

loader.io는 수천 개의 동시 연결로 웹앱 / api를 스트레스 테스트 할 수있는 무료로드 테스트 서비스입니다.

또한 API가 있습니다.

이 질문이 아직 열려 있기 때문에 나는 무게를 might 수도 있습니다.

좋은 소식은 지난 5 년 동안 오픈 소스 도구가 실제로 성숙하고 우주에서 이륙했다는 것입니다.

내 생각은 다음과 같습니다.

Jmeter 대 그라인더

Jmeter는 GUI를 통해 구성된 XML 스타일 사양에서 구동됩니다.

Grinder는 뮤티 스레드 Java 프레임 워크 내에서 Jython 스크립팅을 사용하므로 프로그래머에게 더욱 적합합니다.

두 도구 모두 HTTP 및 HTTPS를 처리하며 시작하기위한 프록시 레코더가 있습니다. 두 도구 모두 컨트롤러 모델을 사용하여 여러 테스트 에이전트를 구동하므로 확장 성이 문제가되지 않습니다 (클라우드에 대한 액세스 권한 제공).

어떤게 더 좋아:-

URL 재 작성, 상관 관계, 가상 사용자 당 고유 한 데이터 제공, 처음 시뮬레이트 또는 사용자 반환 (HTTP 헤더 조작)에 대한보다 복잡한 스크립팅 요구 사항을 충족함에 따라 두 도구 모두 학습 곡선이 까다로워졌습니다.

이 도구는 다음과 같이 큰 영향을 미치며 웹 에이 도구를 사용하는 많은 예제와 자습서가 있으므로 Jmeter로 시작할 것이라고 말했습니다. '로드 블록'에 와서 Jmeter로 '쉽게'할 수없는 일이라면 그라인더를 살펴보십시오. 좋은 소식은 이러한 툴이 모두 동일한 Java 요구 사항을 가지고 있으며 '믹스 앤 매치'솔루션이 문제가되지 않는다는 것입니다.

새로운 기능 – Selenium WebDriver의 여러 인스턴스를 실행하는 헤드리스 브라우저.

이는 클라우드에서 프로비저닝 할 수있는 리소스의 가용성에 의존하기 때문에 비교적 새로운 접근 방식입니다. 이 방법을 사용하면 Selenium (WebDriver) 스크립트가 헤드리스 브라우저 (예 : WebDriver = New HtmlUnitDriver ()) 드라이버에서 여러 스레드로 실행됩니다.

약 25 개의 '헤드리스 브라우저'인스턴스를 Amazon M1 Small Instance에서 실행할 수 있습니다.

이것이 의미하는 것은 기능 테스트 스크립트를 용도 변경하여 성능 테스트 스크립트가 될 때 모든 상관 관계, URL 재 작성 문제가 사라진다는 것입니다.

Grinder 또는 Jmeter와 같은 HTTP 드라이버와 비교하여로드를 구동하는 데 더 많은 VM이 필요하므로 확장 성이 저하됩니다. 즉, 시간당 $ 1.20의 비용으로 500 개의 가상 사용자를 구동하려는 경우 20 개의 Amazon Small Instances (시간당 6 센트)로 실제 사용자 환경에 매우 가까운로드를 제공합니다.

또한 greenlet 을 사용 하는 멋진 오픈 소스 순수 파이썬 분산 및 확장 가능한 메뚜기 프레임 워크가 있습니다. 엄청난 양의 동시 사용자를 시뮬레이트하는 데 탁월합니다.

최근로드 테스트에 Gatling을 사용하기 시작했습니다. 로드 테스트를 위해이 도구를 사용해 보는 것이 좋습니다. 우리는 과거에 SOASTA와 JMETER를 사용했습니다. 개틀링을 고려해야하는 주요 이유는 다음과 같습니다.

• 시나리오를 기록하는 레코더
• Jmeter Threading 모델과 비교하여 더 나은 성능을 제공하는 Akka 및 Netty 사용
• Jmeter XML에 비해 유지 관리가 매우 쉬운 DSL 스칼라
• 테스트를 작성하기 쉽고, 스칼라라면 두려워하지 마십시오.
• 보고

개틀링 코드를 사용하여 코드를 작성하는 간단한 예를 드리겠습니다.

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

그러나 가능한 한 복잡하게 만들 수 있습니다. 개틀링에서 눈에 띄는 기능 중 하나는 매우 세부적인보고입니다.

여기에 몇 가지 링크가 있습니다 :
개틀링
개틀링 자습서

나는 최근에 그것에 대해 이야기했다, 당신은 여기에 이야기를 통해 갈 수 있습니다 :
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

이것은 오래된 질문이지만 새로운 솔루션은 언급 할 가치가 있다고 생각합니다. Checkout LoadImpact : http://www.loadimpact.com .

나는 WebLoad를 시도했는데 꽤 깔끔한 도구입니다. 웹 사이트에서 사용자 작업을 기록 할 수있는 테스트 스크립트 IDE와 함께 제공됩니다. 또한 웹 서버에서 스트레스 테스트를 수행 할 때 그래프를 그립니다. 사용해보십시오. 적극 권장합니다.

여기에 언급 된 모든 것을 시도해 보니 컬 로더 가 내 목적에 가장 적합 하다는 것을 알았습니다 . 매우 쉬운 인터페이스, 실시간 모니터링, 유용한 통계를 통해 성능 그래프를 작성할 수 있습니다. libcurl의 모든 기능이 포함되어 있습니다.

Blaze 미터에는 세션을 기록하고 JMeter로 내보내기위한 크롬 확장 기능이 있습니다 (현재 로그인 필요). JMeter 서버 클러스터에서 실행하기 위해 돈을 지불 할 수도 있습니다 (가격은 내가 방금 사용하지 않은 LoadImpact보다 훨씬 낫습니다).

• BlazeMeter 크롬 확장
• 그것에 대한 블로그 항목

나는 유료 버전을 아직 사용하지 않았음에도 불구하고 그들과 아무런 관련이 없습니다.

거의 1 년 전에이 질문을했지만 웹 사이트를 벤치마킹하는 다른 방법을 찾고 있는지 모르겠습니다. 그러나이 질문은 여전히 ​​해결 된 것으로 표시되지 않았 으므로 무료 웹 서비스 LoadImpact (btw. 제휴하지 않음) 를 제안하고 싶습니다 . 트위터를 통해이 링크를 얻었 으며이 찾기를 공유하고 싶습니다. 그것들은 합리적이고 좋은 개요를 만들고 몇 달러를 더 지불하면 "완전 충격 모드"를 얻게됩니다. 이것은 아마도 이상하게 들리지만 서비스를 밀고 제동하는 행운을 빕니다 :)

IBM Page Detailer 도 작업하기에 유용한 도구 라는 것을 알았 습니다.

나는 openSTA를 사용 했다 .

이를 통해 웹 사이트와의 세션을 기록한 다음 비교적 간단한 스크립트 언어를 통해 재생할 수 있습니다.

웹 서비스를 쉽게 테스트하고 고유 한 스크립트를 작성할 수 있습니다.

스크립트를 원하는 방식으로 테스트에 배치하고 반복 횟수, 각 반복의 사용자 수, 각 새로운 사용자를 소개하기위한 램프 업 시간 및 각 반복 사이의 지연 시간을 구성 할 수 있습니다. 테스트는 나중에 예약 할 수도 있습니다.

오픈 소스이며 무료입니다.

스프레드 시트에 저장할 수있는 많은 보고서를 생성합니다. 그런 다음 피벗 테이블을 사용하여 결과를 쉽게 분석하고 그래프로 표시합니다.

언급 된 Microsoft 도구 인 Microsoft 웹 응용 프로그램 스트레스 도구를 사용합니다. 내가 사용한 가장 쉬운 도구입니다. 수동으로 생성 된 테스트에서 포트 80에 도달 할 수있는 등 여러 가지 방법으로 제한됩니다. 그러나 사용의 용이성은 실제로 사용됨을 의미합니다.

OpenSTA 및 링크 체크 스파이더를 포함한 다른 툴로이 툴의로드를 보완합니다.

JMeter는 초기 평가에서 좋아 보이므로 앞으로 지속적으로 통합 할 수 있기를 바랍니다. 그러나 JMeter는 복잡하고 사소한 것이 아닙니다.

MS 스트레스 도구 결과 해석에 관한 또 다른 질문을 제시하는 것이 좋습니다.

Visual Studio Test Edition 2010 (2008 년도 좋음). 이것은 웹 /로드 테스트를 작성하는 정말 쉽고 강력한 도구입니다.

Windows 서버와 함께 사용할 때이 도구의 이점은 보고서의 모든 perfmon 서버 통계에 통합적으로 액세스 할 수 있다는 것입니다. 정말 유용합니다.

또 다른 보너스는 Visual Studio 프로젝트를 사용하면 웹 사이트의 코드 실행을 프로파일 링하는 "성능 세션"을 통합 할 수 있다는 것입니다.

Windows 서버에서 웹 페이지를 제공하는 경우 이것이 가장 좋은 도구입니다.

그러나 여러 대의 컴퓨터를 사용하여 응용 프로그램을로드 테스트하는 데 별도의 고가의 라이센스가 필요합니다.

우리는 부하 및 성능 측정을 일류 관심사로 취급하는 프로세스를 개발했습니다. 말씀했듯이 프로젝트를 끝낼 때 실망하는 경향이 있습니다 ...

따라서 개발 중에는 세션 관리 중단, 동시성 문제 및 리소스 경합 문제와 같은 기본적인 문제를 확인하는 매우 기본적인 다중 사용자 테스트 (셀레늄 사용)가 포함됩니다. 사소한 프로젝트는 지속적인 통합 프로세스에서이를 포함하므로 매우 정기적 인 피드백을받습니다.

극한의 성능 요구 사항이없는 프로젝트의 경우 테스트에 기본 성능 테스트가 포함됩니다. 일반적으로 BadBoy를 사용하여 테스트를 스크립팅하고 JMeter로 가져 와서 로그인 세부 정보 및 기타 스레드 관련 사항을 대체합니다. 그런 다음 서버가 초당 100 개의 요청을 처리하는 수준까지이를 증가시킵니다. 응답 시간이 1 초 미만이면 충분합니다. 우리는 삶을 시작하고 계속합니다.

성능 요구 사항이 극도로 높은 프로젝트의 경우 여전히 BadBoy와 JMeter를 사용하지만 테스트 장비의 서버 (일반적으로 웹 및 데이터베이스 서버)의 병목 현상을 이해하는 데 많은 에너지를 투입합니다. Microsoft 이벤트 로그를 분석 하는 데 유용한 도구 가 있습니다 하는 데 . 우리는 일반적으로 예상치 못한 병목 현상을 발견하고 가능한 경우 최적화합니다. "1 웹 서버, 1 데이터베이스 서버"에서 가능한 한 빠른 응용 프로그램을 제공합니다. 그런 다음 일반적으로 대상 인프라에 배포하고 "클라우드의 Jmeter"서비스 중 하나를 사용하여 테스트를 대규모로 다시 실행합니다.

다시 한 번 PAL 보고서는 테스트 중에 발생한 상황을 분석하는 데 도움이되며 생산 환경에서 매우 다른 병목 현상이 나타나는 경우가 많습니다.

핵심은 스트레스 테스트를 실행할뿐만 아니라 애플리케이션의 성능을 이해하는 데 필요한 정보를 수집하는 것입니다.

여기에 언급 된 좋은 도구가 많이 있습니다. "웹 응용 프로그램을 어떻게 스트레스 테스트합니까?"라는 질문에 도구가 대답인지 궁금합니다. 이 도구는 실제로 웹 앱을 강조하는 방법을 제공하지 않습니다. 내가 아는 것은 다음과 같습니다.

스트레스 테스트는 점점 더 많은 사용자에게 응답을 제공하면서 웹 앱이 실패하는 방법을 보여줍니다. 스트레스 테스트는 웹 앱이 실패하는 동안 어떻게 작동하는지 보여줍니다. 오늘날 대부분의 웹 응용 프로그램, 특히 소셜 / 모바일 웹 응용 프로그램은 서비스의 통합입니다. 예를 들어 2011 년 5 월 Facebook이 중단되면 Pepsi.com의 웹 앱에 로그온 할 수 없습니다. 앱이 완전히 실패하지는 않았으며, 정상적인 기능의 큰 부분 만 사용자가 사용할 수 없게되었습니다.

성능 테스트에 따르면 앱을 동시에 사용하는 사용자 수에 관계없이 응답 시간을 유지할 수있는 웹 앱 기능이 표시됩니다. 예를 들어 동시 사용자가 10 명인 초당 10 개의 트랜잭션을 처리하는 앱은 20 명의 사용자가 초당 20 개의 트랜잭션을 처리해야합니다. 앱이 초당 20 개 미만의 트랜잭션을 처리하면 응답 시간이 길어지고 앱이 선형 확장 성을 달성 할 수 없습니다.

또한 위의 예에서 초당 트랜잭션 수는 테스트 사용 사례 / 워크 플로의 성공적인 작업이어야합니다. 고장은 일반적으로 짧은 시간 내에 발생하며 TPS 측정이 지나치게 낙관적입니다. 실패는 앱에 부하를 생성하기 때문에 스트레스 및 성능 테스트에 중요합니다.

http://www.pushtotest.com/pushtotest-testmaker-6-methodology 의 TestMaker User Guide에서 PushToTest 방법론을 작성했습니다 . TestMaker는 오픈 소스 (GPL) 커뮤니티 버전과 TestMaker Enterprise (전문적인 지원이 큰 상용)의 두 가지 형태로 제공됩니다.

-솔직한

LoadBooster ( https://www.loadbooster.com )를 살펴보십시오 . 헤드리스 스크립트 가능 브라우저 PhantomJS / CasperJ를 사용하여 웹 사이트를 테스트합니다. Phantomjs는 모든 페이지를 구문 분석하고 렌더링하며 클라이언트 쪽 스크립트를 실행합니다. 헤드리스 브라우저 방식은 복잡한 AJAX Heavy Web 2.0 앱, 브라우저 탐색, 마우스 클릭 및 브라우저의 키 입력을 지원하거나 DOM에 요소가 존재할 때까지 기다리는 테스트 시나리오를보다 쉽게 ​​작성할 수 있습니다. LoadBooster는 셀레늄 HTML 스크립트도 지원합니다.

면책 조항 : LoadBooster에서 일합니다.

jMeter 보다 훨씬 사용하기 쉬운 ZebraTester 를 사용해보십시오 . jMeter를 오랫동안 사용해 왔지만로드 테스트의 총 설정 시간은 항상 문제였습니다. ZebraTester는 오픈 소스가 아니지만 지난 6 개월 동안 절약 한 시간이이를 보완합니다. 또한로드 생성기를 사용하여 테스트를 빠르게 실행하는 데 사용할 수있는 SaaS 포털이 있습니다.

웹 응용 프로그램에 대한 또 하나의 참고 사항은 잠금을 통한 스레드 간 경합으로 인해 큰 성능 문제가 있음을 알았습니다. 따라서 도덕적 인 잠금 방식은 매우 신중하게 생각하는 것이 었습니다. 우리는 비동기 http 핸들러를 사용하여 너무 많은 요청을 조절하기 위해 작업자 스레드를 갖게되었습니다. 그렇지 않으면 응용 프로그램이 압도되고 충돌하고 타 버릴 것입니다. 그것은 거대한 백 로그가 쌓일 수 있음을 의미했지만 적어도 사이트는 계속 유지 될 것입니다.

TestComplete를 살펴보십시오 .

나는 opensta 제안을 두 번째로한다. SMTP를 사용하여 테스트하는 서버를 모니터링하는 작업을 수행 할 수 있다고 덧붙였습니다. 우리는 프로세서로드, 사용 된 메모리, 보낸 바이트 수 등을 추적합니다. 유일한 단점은 무언가를 발견하고 수정을 원할 경우 더 이상 유지되지 않는 여러 오픈 소스 라이브러리에 의존하므로 컴파일을 수행한다는 것입니다 소스 버전은 대부분의 OSS보다 까다 롭습니다.

나는 JMeter와 함께 연주했다. ASP.NET Webforms는 테스트 할 수 없다고 생각했습니다. viewstate는 내 테스트를 중단했습니다. 이유는 확실하지 않지만 viewstate를 올바르게 처리하지 못하는 몇 가지 도구가 있습니다. 현재 프로젝트는 ASP.NET MVC이며 JMeter는 잘 작동합니다.

FunkLoad로 좋은 결과를 얻었습니다 .

• 사용자 상호 작용을 쉽게 스크립트 할 수 있습니다
• 보고서는 분명하다
• 서버 부하를 모니터링 할 수 있습니다

부끄러운자가 프로모션으로 고발 될 위험이 있으므로 무료로드 테스트 도구를 구할 때이 기사로 이동했음을 지적합니다. http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

원하는 처리량을 얻지 못했거나 원하는 유연성을 얻지 못했습니다. 그리고 사후 테스트 분석에서 여러로드 테스트 생성 호스트의 결과를 쉽게 집계하고 싶었습니다.

나는 목록에있는 모든 도구를 시험해 보았고 좌절감에 따라 내가 할 수있는 것을 아무것도하지 않았다는 것을 알았습니다. 그래서 하나를 만들어 공유하고 있습니다.

여기 있습니다 : http://sourceforge.net/projects/loadmonger

추신 : 도시 속어에 익숙한 사람들의 이름에 대한 맹렬한 언급은 없습니다. 나는 아니었지만 지금은 조금 더 세속적입니다.

나는 jMeter 에도 투표 하고 @PeterBernier 답변에 따옴표를 추가하고 싶습니다.

로드 테스트가 응답하는 주요 질문은 웹 응용 프로그램을 지원할 수있는 동시 사용자 수는 몇 명입니까? 적절한 답변을 얻으려면 로드 테스트는 가능한 한 실제 응용 프로그램 사용량을 나타내야합니다 .

마음에 위 유지 하여 JMeter는 많은 빌딩 블록이 논리 컨트롤러 , 구성 요소 , 예비 프로세서 , 리스너 , ... 당신이 도움이 될 수있다.

jMeter를 사용하여 실제 상황을 모방 할 수 있습니다. 예를 들면 다음과 같습니다.

1. JMeter를 구성을 구성하여 실제 브라우저 역할을하는 ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. 구성 JMeter를 사용자 요청을 생성하는 (정의하여 number of users per second, ramp-up time, scheduling, ...)
3. 분산로드 테스트를 수행하려면 jMeter를 사용하여 많은 클라이언트를 구성하십시오.
4. 테스트 중에 서버가 올바르게 응답하는지 확인하기 위해 응답을 처리하십시오. (예를 들어 assert텍스트를 찾기위한 응답)

고려하십시오 :

• 몇 분만에 jMeter로 실제 웹 애플리케이션 테스트를 쉽게 시작할 수 있습니다. jMeter에는 테스트 시나리오를 기록하는 매우 쉬운 도구가 있습니다 (로 알려짐 HTTP(S) Test Script Recorder).
• jMeter는 http://jmeter-plugins.org에 많은 플러그인을 가지고 있습니다 .
• jMeter UI는 스윙 기반이며 jMeter 3.2에서 크게 변경되었습니다. 반면에 JMeter GUI는 테스트 및 디버깅에만 사용해야합니다. 실제 테스트를 위해 GUI 모드에서 사용하는 것은 좋지 않습니다. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . 시나리오를 구성 및 테스트하고 GUI가 아닌 모드에서 실행하십시오.
• jMeter (로 알려짐 listeners)의 도구를 보여주는 많은보고가 있지만 테스트 중에는 켜져 있지 않습니다. 테스트를 실행하고 보고서 ( .jtl파일)를 생성해야합니다 . 그런 다음 이러한 도구를 사용하여 결과를 분석해야합니다. 한 번 봐 제발 https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats 또는 https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm을 .

https://www.blazemeter.com/jmeter은 테스트 환경을 구성하는 데 도움이되는 아주 좋은 실용적인 정보를 제공합니다.