내부 AB 테스트를 통해 서버가 초당 3k 적중에서 1k 동시성을 처리 할 수 ​​있다고 잘못 가정했습니다.

현재 나의 이론은 네트워크가 병목 현상이라는 것입니다. 서버가 충분한 데이터를 충분히 빨리 보낼 수 없습니다.

1k 동시성에서 blitz.io의 외부 테스트에 따르면 서버가 초당 180 만 리턴 할 수 있기 때문에 응답 시간이 길어지고 시간이 더 오래 걸리는 내 적중이 180에서 상한값으로 표시됩니다.

nginx에서 빈 파일을 제공하고 벤치에 올렸습니다. 동시성으로 1 : 1로 확장됩니다.

이제 IO / memcached 병목 현상 (nginx는 일반적으로 memcached에서 가져옴)을 배제하기 위해 파일 시스템에서 캐시 된 페이지의 정적 버전을 제공합니다.

결과는 내 원래 테스트와 매우 유사합니다. 나는 약 180 RPS에서 모자를 씌운다.

HTML 페이지를 반으로 나누면 RPS가 두 배가되므로 페이지 크기에 따라 제한됩니다.

로컬 서버에서 내부적으로 ApacheBench를 사용하는 경우 전체 페이지와 1/2 페이지 모두에서 약 4k RPS의 높은 전송률로 일관된 결과를 얻습니다. 전송 속도 : 62586.14 [Kbytes / sec] 수신

외부 서버에서 AB를 검색하면 blitz.io 결과와 동일한 약 180RPS를 얻습니다.

의도적으로 제한되지 않는 것을 어떻게 알 수 있습니까?

여러 외부 서버에서 벤치마킹하면 모든 결과가 나빠져서 벤치마킹 서버 / blitz.io의 다운로드 속도 문제가 아니라 내 서버 아웃 바운드 트래픽에 문제가 있다고 생각합니다.

따라서 서버가 데이터를 충분히 빨리 전송할 수 없다는 결론에 도달했습니다.

내가 맞아? 이 데이터를 해석하는 다른 방법이 있습니까? 솔루션 / 최적화로 초당 180 개의 적중을 처리 할 수있는 다중 서버 +로드 밸런싱을 설정합니까?

나는 서버 최적화에 익숙하지 않으므로이 데이터를 해석하는 확인에 감사드립니다.

아웃 바운드 트래픽

아웃 바운드 대역폭에 대한 자세한 정보는 다음과 같습니다. 네트워크 그래프는 최대 16Mb / s : 초당 16MB의 출력을 보여줍니다. 전혀 들리지 않습니다.

스로틀 링에 대한 제안으로, 나는 이것을 조사하고 linode가 50mbps 캡을 가지고 있음을 발견했습니다 (물론 타격에 가깝지 않습니다). 나는 그것을 100mbps로 올렸다.

linode가 트래픽을 제한하고 적중하지 않기 때문에 서버가 실제로 최대 100mbps를 출력 할 수 있어야하지만 다른 내부 병목 현상으로 인해 제한을 받습니까? 이 대규모 규모의 네트워크가 어떻게 작동하는지 이해하지 못합니다. 문자 그대로 HDD에서 읽을 수있는 한 빨리 데이터를 전송할 수 있습니까? 네트워크 파이프 가 큰가요?

결론적으로

1 : 위의 내용을 바탕으로, LB 뒤 서버 당 정확히 180RPS로 다중 nginx 서버 설정 위에 nginx로드 밸런서를 추가하여 180RPS를 확실히 올릴 수 있다고 생각합니다.

2 : linode에 전혀 맞지 않는 50 / 100mbit 제한이있는 경우 단일 서버 설정으로 해당 제한에 도달하기 위해 수행 할 수있는 작업이 있어야합니다. 로컬에서 충분히 빠르게 데이터를 읽거나 전송할 수 있고 linode가 50mbit / 100mbit 캡을 갖도록 귀찮게하는 경우 감지 방법을 잘 모릅니다. 옳은?

나는 지금 질문이 거대하고 모호하다는 것을 알고 있지만 그것을 어떻게 압축해야할지 모르겠다. 내가 한 결론에 대해 모든 의견을 부탁드립니다.

문제는 linode.com 그래프 피크가 실제 피크라고 가정했습니다. 그래프는 5 분 평균 데이터 포인트를 사용하므로 실제로 50mbit 한도에 도달했을 때 피크가 24mbits 인 것으로 나타났습니다.

그들이 100mbits까지 올렸으므로, 나의 벤치 마크는 즉시 새로운 아웃 바운드 트래픽 한도까지 올라갔습니다.

내가 더 일찍 알아 차렸다면! 저의 많은 추론은 그 그래프로 인해 아웃 바운드 트래픽 제한에 도달하지 않았다는 아이디어에 달려있었습니다.

이제 초당 370 건의 요청이 최고치인데,이 시점에서 요청의 "백 로그"를 받기 시작하는 시점에 100mbps 미만이며 응답 시간이 길어지기 시작합니다.

이제 페이지를 축소하여 최대 동시성을 높일 수 있습니다. gzip을 사용하면 600RPS를 얻습니다.

갑자기 피크가 발생하고 보류중인 요청의 백 로그 (대역폭으로 제한됨)가 누적되기 시작해도 여전히 문제가 발생하지만 다른 질문처럼 들립니다.

최적화 /이 데이터 읽기 / 가능한 문제를 좁히는 데 훌륭한 교훈이었습니다. 입력 해 주셔서 감사합니다!

조금 늦게 알아 차 렸지만 ... 때때로 ServerFault 블로그를 읽는 것이 좋습니다.

나는 특히이 게시물에 대해 생각하고 있는데 , 그들은 1 초 폴링 간격을 갖는 것이 때때로 당신과 가진 매우 유사한 문제와 관련하여 때때로 그것을 줄이지 않는 이유를 논의 합니다.

우리는 10-30MBit / s의 속도로 1Gbit / s 인터페이스에서 패킷을 매우 자주 버리고 성능을 저하시키는 것으로 나타났습니다. 이것은 10-30MBit / s 속도가 실제로 1 분 속도로 변환 된 5 분당 전송 된 비트 수이기 때문입니다. Wireshark와 더 가까이 파고 1 밀리 초 IO 그래프를 사용할 때, 우리는 소위 1Gbit / s 인터페이스의 밀리 초당 1Mbit 속도를 자주 터뜨리는 것을 보았습니다.

물론 나는 생각했다. 그리고 나는 내가 처음으로 얻을 수있는 기회를 내 가게의 다른 SA에서 파산하고 있다는 것을 알고 있으며, 우리 가이 문제에 부딪 칠 때 사악하게 훌륭하고 지각 적으로 보일 것입니다.

누가 알 겠어, 나는 심지어 그들 중 일부를 비밀리에 둘 수도있다. :)

네트워크에 의해 제한 될 수 있지만 반드시 대역폭 문제 일 필요는 없습니다. 원격 테스트 장치의 대기 시간은 연결이 진행되는 동안 창 크기의 협상 및 안정화뿐만 아니라 주어진 시간에 보류중인 연결 수 (확인을 위해 50ms 대기하는 것이 로컬에서 0.5ms와 크게 다름)에 영향을 미칩니다. 또한 정체의 기능 또는 이동 통신사 (또는 업스트림)의 대역폭 제한 메커니즘으로 인해 일정량의 패킷 손실에 노출 될 수 있습니다.

합리적인 기준선을 도출하기 위해 방정식에서 가능한 한 많이 제거하는 것이 좋습니다. 일반 인터넷에서 서버의 최대 대역폭, 대기 시간 및 패킷 손실을 몇 지점까지 측정하십시오. 소리가 나지 않을 수도 있으므로 "Voip 트래픽 테스트"또는 이와 유사한 것을 검색해보십시오. VOIP 서비스의 일부 공급자는 이러한 종류의 패턴을 양방향으로 정확하게 측정 할 수있는 앱을 가지고 있습니다. 링크의 실제 유용한 속도에 대한 유효한 경험적 데이터가 있으면 결과의 유효성을 검사 할 수 있습니다.

대역폭 테스트 외에도 하위 수준 웹 트래픽의 패킷 캡처를보고 과도한 재전송 횟수를 확인하고 서버가 요청에 응답하는 데 걸리는 시간을 측정하는 것이 유용 할 수 있습니다. 연결 수의 함수로 값이 크게 증가하고 있습니다.