nginx worker_process를 조정하여 분당 100k 적중을 얻습니다.


115

하나의 html 파일을 제공하는 서버가 있습니다.

현재 서버에는 2 개의 CPU와 2GB의 램이 있습니다. blitz.io에서 우리는 분당 약 12,000 개의 연결을 얻고 있으며 매초 250 개의 동시 연결로 60 초 동안 200 번의 시간 제한을받습니다.

worker_processes  2;

events {
 worker_connections 1024;
}

제한 시간을 늘리면 응답 시간이 1 초 이상 증가하기 시작합니다.

이것에서 더 많은 주스를 짜기 위해 또 무엇을 할 수 있습니까?

답변:


188

구성 파일 :

worker_processes  4;  # 2 * Number of CPUs

events {
    worker_connections  19000;  # It's the key to high performance - have a lot of connections available
}

worker_rlimit_nofile    20000;  # Each connection needs a filehandle (or 2 if you are proxying)


# Total amount of users you can serve = worker_processes * worker_connections

추가 정보 : 높은 트래픽로드를위한 nginx 최적화


14
초당 총 사용자 수에 대해 제공된 방정식이 잘못되었다고 생각합니다. 대신 초당 평균 사용자 수는 다음과 같아야합니다. = worker_processes * worker_connections / (keepalive_timeout * 2) 따라서 위의 conf 파일은 @ablemike가 필요로하는 것보다 훨씬 많은 초당 ~ 7.6K 연결을 서버 할 수 있습니다. 그러나 ulimit가 제한적이고 수정하지 않으려는 경우 worker_rlimit_nofile을 사용하는 것이 좋습니다.
Ethan

2
@Ethan, 왜 2로 나누어야합니까? 매초마다 100 개의 새로운 연결을 얻고 시간 초과가 5이고 6 초로 시작하면 서버 측에서 아직 종료되지 않은 5 * 100 개의 연결이 계속 유지됩니다. 일부 사용자가 자신의 연결을 중단하는 경우 우리는 더 적은있을 수 있습니다
하기 Bulat

3
공식이 작품은 킵 얼라이브는 0으로 지정하지 않는 경우 있음 (장애인)
는 Tila

5
각 연결에는 이미지 / JS / CSS와 같은 정적 파일의 경우에도 2 개의 파일 핸들이 필요합니다. 이것은 클라이언트 연결의 경우 1이고 정적 파일을 열기위한 두 번째입니다. 따라서 worker_rlimit_nofile = 2 * worker_connections를 변경하는 것이 더 안전합니다.
Ethan

4
worker_rlimit_nofile을 사용하지만 프로세스 당 열린 파일 수 값을 설정하려면 'ulimit -n'도 호출해야합니다. 이것은 init 스크립트에서 더 잘 수행됩니다.
Ethan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.