웹 애플리케이션 성능 벤치마크에 대한 권장 사항
https://stackoverflow.com/questions/41857
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
인트라넷 웹 애플리케이션 테스트를 시작하려고 합니다.구체적으로는 애플리케이션의 성능을 결정해야 합니다.
누군가 애플리케이션 성능을 판단할 수 있는 공식/비공식 표준을 제안해 주실 수 있나요?
해결책
스트레스 및 부하 테스트를 위해 일부 도구를 사용하십시오.Java를 사용하는 경우 다음을 살펴보십시오. JMeter.애플리케이션 성능을 테스트하는 다양한 방법을 제공합니다.다음 사항에 집중해야 합니다.
- 응답 시간:일반 요청에 대해 애플리케이션이 실행되는 속도입니다.일부 읽기/쓰기 사용 사례 테스트
- 부하 테스트:트래픽이 많은 시간에 애플리케이션이 작동하는 방식.도구는 일정 기간 동안 여러 요청을 제출합니다(올바르게 구성할 수 있음).
- 스트레스 테스트:귀하의 애플리케이션이 장기간 작동할 수 있습니까?이 테스트는 애플리케이션을 한계까지 밀어붙입니다.
이것부터 시작하세요. 관심이 있으시면 다른 종류의 테스트도 있습니다.
다른 팁
프런트 엔드를 테스트하려면 YSlow는 사용자 관점에서 페이지를 로드하는 데 걸리는 시간에 대한 통계를 얻는 데 적합합니다.각 특정 HTTP 요청에 대한 통계, 소요 시간 등으로 분류됩니다.그것을 얻으십시오 http://developer.yahoo.com/yslow/
물론 Firebug도 필수적입니다.프로필 버튼을 눌러 JS를 명시적으로 또는 실시간으로 프로필할 수 있습니다.필요한 경우 최적화를 수행하고 모든 기능을 실행하는 데 걸리는 시간을 확인합니다.이로 인해 JS 코드의 성능을 측정하는 방식이 변경되었습니다. http://getfirebug.com/js.html
실제로 제가 생각하는 가장 큰 것은 응답 시간이지만, 제가 살펴볼 다른 지표는 프로세서 및 메모리 사용량과 응답 시간입니다.동시 사용자/프로세스 수.또한 정상 부하와 최대 부하에서 모든 것이 예상대로 작동하는지 확인합니다.다양한 요청이 서로 겹쳐서 로드가 높을수록 애플리케이션 오류가 발생하는 시나리오가 발생할 수 있습니다.
정말로 자세한 정보를 얻으려면 다양한 유형의 부하/스트레스 테스트를 실행해야 합니다.아마도 단계 로드 테스트(시간이 지남에 따라 시스템 사용자의 점진적인 증가)와 스파이크 테스트(이전에는 거의 아무도 액세스하지 않았던 동시에 상당한 수의 사용자가 모두 액세스함)를 살펴보고 싶을 것입니다.또한 서버가 재부팅된 직후에 서버에 대해 테스트를 실행하여 이것이 시스템에 어떤 영향을 미치는지 확인했습니다.
또한 HEAT(적대적인 환경 응용 프로그램 테스트)라는 개념을 살펴보고 싶을 수도 있습니다.실제로 이는 시스템의 일부가 오프라인 상태가 될 때 어떤 일이 발생하는지 보여줍니다.시스템 성능이 성공적으로 저하됩니까?이것이 핵심 표준이 되어야 합니다.
제가 제안하는 가장 큰 제안 중 하나는 테스트를 수행하기 전에 시스템이 수행해야 할 작업을 설정하는 것입니다.가장 큰 이유는 책임이다.사람들이 시스템이 뭔가를 해야 한다는 것을 인정하게 한 다음 그것이 사실인지 테스트해 보세요.사람들이 결과를 즉시 확인할 수 있고 이것이 허용 가능한 기준에 대한 기본 벤치마크가 되기 때문에 이것이 중요합니다.
"구체적으로는 애플리케이션의 성능을 판단해야 하는데...."
이는 요구사항 문제, 즉 합리적이고 효과적인 것으로 간주되는 것에 대한 사용자 커뮤니티의 기대를 완전히 반영합니다.요구사항에는 다양한 구성요소가 있습니다.
- 일반 응답 시간, " 부하가 많은 경우 ....사이트의 일반 응답 시간은 x, y% 미만입니다..."
- 특정 응답 시간, "부하가 있는 경우 ....신용 카드 처리는 전체 시간의 1%인 z초 이내에 완료됩니다..."
- 시스템 용량 항목, "부하가 너무 많아서....CPU|네트워크|RAM|DISK는 용량의 n%를 초과할 수 없습니다...."
- 로드 프로필은 시스템 성능을 결정하기 위해 구체적인 목표 측정값이 수집되는 사용자 수와 트랜잭션 수를 혼합한 것입니다.
응답 시간과 기타 측정값이 절대적이지 않다는 것을 알 수 있습니다.6가지 시그마 제조 원칙을 살펴보면, 백만 분의 1 예외에서 10억 분의 1 예외로 이동하는 데 드는 비용은 엄청나며, 예외 없음으로 이동하는 데 드는 비용은 일반적으로 일반 조직에서는 감당할 수 없는 비용입니다.귀하의 조직에 고유한 애플리케이션에 대해 허용 가능한 응답 시간으로 간주되는 것은 공용 인터넷에 연결된 애플리케이션인 고도로 상용화된 제품과 완전히 다를 가능성이 높습니다.경쟁이 치열한 솔루션의 경우 인터넷에서의 응답 시간 기대치는 사용자 이탈이 심각하게 증가하는 2~3초 범위로 기울고 있습니다.이는 지난 10년 동안 8초에서 4초로 감소했으며 이제는 2~3초 범위로 떨어졌습니다.Facebook과 같은 일부 애플리케이션은 경쟁적인 이유로 거의 감지할 수 없는 1초 미만의 응답 시간을 자랑합니다.엄격한 표준을 찾고 있다면 그 표준은 존재하지 않습니다.
스타일, 형태, 기능에 대한 몇 가지 업계 벤치마크를 읽어 보는 것이 이해에 도움이 될 것입니다.
귀하의 요구 사항을 나타내는 견고한 성능 테스트 세트를 설정하는 것은 중요한 문제입니다.QA 노력의 이 단계를 처리하기 위해 전문가를 초대할 수도 있습니다.
도구 선택 시 다음을 수행할 수 있는 도구를 선택하십시오.
- 인터페이스를 연습해보세요
- 귀하의 요구사항에 대해 보고하세요
- 귀하 또는 귀하의 팀은 사용할 수 있는 기술을 보유하고 있습니다.
- 경영자의 축복을 받아 교육을 받고 참석할 수 있습니다.
위의 네 가지 요소 중 하나라도 실패하면 시장에서 가장 비싼 도구를 구입하고 이를 배포하기 위해 가장 비싼 회사를 고용하게 됩니다.
행운을 빌어요!
