라이브로 가기 전에 nginx 스택을 설정하고 구성을 최적화하고 있습니다. 기계를 스트레스 테스트하기 위해 ab를 실행 한 결과, 초당 150 번의 요청에서 많은 요청이 발생하고 1 초 이상 걸리는 것을보고 실망했습니다. 이상하게도 기계 자체는 열심히 호흡하지 않았습니다.
나는 마침내 상자를 핑하기로 생각하고 약 100-125 ms의 핑 시간을 보았습니다. (놀랍게도 기계는 전국에 있습니다.) 따라서 네트워크 대기 시간이 내 테스트를 지배하는 것처럼 보입니다. 서버와 동일한 네트워크의 시스템에서 동일한 테스트를 실행하면 (ping 시간 <1ms) 초당 5000 개 이상의 요청이 표시되는데 이는 시스템에서 예상 한 것과 더 일치합니다.
그러나 이것은 나에게 생각을 주었다 : 웹 서버에 대한 초당 "현실적인"요청 측정을 어떻게 결정하고보고합니까? 항상 성능에 대한 주장이 있지만 네트워크 대기 시간을 고려해서는 안됩니까? 물론 서버 옆의 컴퓨터에는 초당 5000 개의 요청을 처리 할 수 있지만 전국의 컴퓨터에는 처리 할 수 없습니다. 연결 속도가 느리면 결국 서버 성능에 영향을 미치게됩니다. 아니면이 모든 것에 대해 생각하고 있습니까?
이것이 네트워크 엔지니어링 101 물건이라면 용서하십시오. 저는 무역 개발자입니다.
업데이트 : 명확성을 위해 편집되었습니다.
나는 ab의 동시성 옵션에 익숙하고 상자의 한계를 발견하기 위해 광범위한 값을 시도했습니다. 위에서 쓴 것처럼, 나는 초기 테스트가 네트워크에 의해 주도되고 서버의 기능을 반영하지 않았다는 것을 이해합니다. 그러나 내 질문은 여전히 현실입니다 : 대부분의 사람들은 현실적인 메트릭을 얻기 위해 어디에서 테스트를 실행합니까? 서버와 동일한 네트워크의 상자에서 테스트를 실행하면 (효과적으로 네트워크 대기 시간을 효과적으로 줄임) 큰 숫자가 반환되지만 실제 사용자는 네트워크 외부에서 나오기 때문에 "공평한"숫자처럼 보이지 않습니다.
—
Don
동일한 네트워크에서 실행되는 테스트는 실제로 네트워크를 무시하므로 더 '공정'할 수 있습니다. 사용자가 모두 다른 네트워크에있을 가능성이 높으므로 모든 해당 네트워크의 집계 대역폭이 서버의 사용 가능한 대역폭을 쉽게 초과해야합니다. 따라서 모든 사용자를 고려하면 병목 현상은 서버의 기능이며 개별 사용자를 고려하면 병목 현상은 단일 사용자의 대역폭 일 수 있습니다. (아마도 대부분의 경우 필요하지는 않지만 실제 환경을 가장 잘 시뮬레이션하기 위해 여러 원격 위치에서 이상적인 테스트를 실행합니다.)
—
cyberx86
ab동시성 옵션이 있습니다. 무엇으로 설정 했습니까? 또한 국내 ADSL 연결에서 테스트하는 경우 테스트가 대역폭에 의해 지배 될 가능성이 높으며 서버에서 아무것도 테스트하지 않습니다.