한 서버의 상황만 이야기하세요. 동시성 수는 클라이언트의 관점에서 동시에 도착하는 요청 수를 나타내며, 서버의 동시 처리 능력은 이상적으로(프로세스 전환 없이) 서버가 처리할 수 있는 요청 수를 나타냅니다. 동시성 처리 능력은 CPU의 코어 수와 동일합니다. 위에서 설명한 내용에 따르면 8개의 코어가 있고 요청된 작업이 모두 IO가 없는 순수 컴퓨팅 작업인 경우 각 코어는 초당 10,000개(간단한 컴퓨팅 작업)를 처리할 수 있다고 가정합니다. 이 숫자가 완전히 가능하다면) 이 서버는 초당 80,000개의 요청을 처리할 수 있습니다. 이제 IO를 추가하세요. CPU가 IO 중에 기다려야 하고 다른 작업을 수행할 수 없다면 분명히 CPU가 초당 처리할 수 있는 요청 수가 10,000에서 수백, 심지어 수십 또는 여러 개로 크게 줄어들 것입니다. 다음으로 프로세스 전환, 알고리즘 효율성 등 다양한 요소를 하나씩 추가하면 복잡하지만 실제적인 서버를 얻을 수 있습니다.
동일한 개념은 아니지만 서로 관련이 있습니다. 평균 응답 시간을 t(단위는 밀리초), 동시성 c, 초당 처리되는 요청 수를 q라고 가정하면 q = (1000/t) * c 이것은 q를 늘리는 방법은 두 가지뿐입니다. 1) t를 낮추는 것 2) c를 높이는 것 '1'의 경우 최선을 다해 노력해야만 달성할 수 있습니다. '2'의 경우 일반적으로 c 서버 프로그램의 요청 처리 모델과 관련이 있습니다. 서버 프로그램이 "하나의 스레드가 하나의 요청에 해당" 모드인 경우 c의 최대값이 제한됩니다. 지원할 수 있는 스레드 수에 따라 "하나의 프로세스가 하나의 요청에 해당" 모드인 경우 c의 최대값은 최대 프로세스 수에 따라 달라집니다.
c를 늘리는 과정에서 주목해야 할 한 가지는 스레드/프로세스가 많을수록 컨텍스트 전환 및 스레드/프로세스 스케줄링 오버헤드가 증가한다는 것입니다. 이로 인해 t의 값이 상당히 간접적으로 증가하고 q가 방지됩니다. .c의 값은 비례적으로 증가하기 때문에 무턱대고 c를 증가시키면 일반적으로 실험적 실험을 통해 가장 적절한 c 값을 결정해야 합니다.
또한 특별한 상황이 있습니다. 서버에서 제공하는 서비스가 "데이터 양이 적고 반환 시간이 길다"라는 특징을 가지고 있다고 비즈니스에서 판단하는 경우, 즉 바쁘지는 않지만 매우 느린 비즈니스 유형입니다. , 그러면 NIO를 사용할 수 있습니다. 모드는 서비스를 제공합니다. 예를 들어 nginx는 기본적으로 nio 모드를 사용합니다.
이 모드에서 c 값은 더 이상 스레드/프로세스 수와 관련이 없고 "소켓 연결 수"에만 관련됩니다. 일반적으로 "소켓 연결 수"는 매우 클 수 있으며, 특별히 구성된 Linux 서버에서는 동시에 수백만 개의 소켓 연결을 지원할 수 있습니다. 이 경우 c는 100만 개에 도달할 수 있습니다. t가 아무리 크더라도 여전히 매우 높은 q를 지원할 수 있습니다. 동시에 실제 스레드/프로세스 수는 CPU 활용도를 최대화하기 위해 CPU 코어 수와 일치하도록만 열 수 있습니다. 물론 이 모든 것의 전제는 "데이터량이 적고 반환 시간이 길다"는 점입니다. "특징
귀하의 웹사이트가 정적 사이트이고 모든 요청이 nginx를 통과한다고 가정합니다. 그런 다음 테스트 머신과 서버 간의 네트워크 통신이 원활한지 확인해야 합니다. ab와 같은 도구는 스트레스 테스트에 그다지 설득력이 없습니다. jmeter 또는 loadrunner를 권장합니다. 스트레스 테스트 중에는 테스트 중인 서버의 실제 성능으로 간주되기 전에 테스트의 응답 시간 곡선이 일정 시간 동안 안정적인지 확인할 필요가 있습니다. 이는 특정 워밍업 시간 때문입니다. 일반적으로 일정 시간이 지나면 곡선이 안정화되고 현재 응답 시간을 판단합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
한 서버의 상황만 이야기하세요.
동시성 수는 클라이언트의 관점에서 동시에 도착하는 요청 수를 나타내며, 서버의 동시 처리 능력은 이상적으로(프로세스 전환 없이) 서버가 처리할 수 있는 요청 수를 나타냅니다. 동시성 처리 능력은 CPU의 코어 수와 동일합니다.
위에서 설명한 내용에 따르면 8개의 코어가 있고 요청된 작업이 모두 IO가 없는 순수 컴퓨팅 작업인 경우 각 코어는 초당 10,000개(간단한 컴퓨팅 작업)를 처리할 수 있다고 가정합니다. 이 숫자가 완전히 가능하다면) 이 서버는 초당 80,000개의 요청을 처리할 수 있습니다.
이제 IO를 추가하세요. CPU가 IO 중에 기다려야 하고 다른 작업을 수행할 수 없다면 분명히 CPU가 초당 처리할 수 있는 요청 수가 10,000에서 수백, 심지어 수십 또는 여러 개로 크게 줄어들 것입니다.
다음으로 프로세스 전환, 알고리즘 효율성 등 다양한 요소를 하나씩 추가하면 복잡하지만 실제적인 서버를 얻을 수 있습니다.
동일한 개념은 아니지만 서로 관련이 있습니다.
c를 늘리는 과정에서 주목해야 할 한 가지는 스레드/프로세스가 많을수록 컨텍스트 전환 및 스레드/프로세스 스케줄링 오버헤드가 증가한다는 것입니다. 이로 인해 t의 값이 상당히 간접적으로 증가하고 q가 방지됩니다. .c의 값은 비례적으로 증가하기 때문에 무턱대고 c를 증가시키면 일반적으로 실험적 실험을 통해 가장 적절한 c 값을 결정해야 합니다.평균 응답 시간을 t(단위는 밀리초), 동시성 c, 초당 처리되는 요청 수를 q라고 가정하면
q = (1000/t) * c이것은
q를 늘리는 방법은 두 가지뿐입니다. 1) t를 낮추는 것 2) c를 높이는 것
'1'의 경우 최선을 다해 노력해야만 달성할 수 있습니다.
'2'의 경우 일반적으로 c 서버 프로그램의 요청 처리 모델과 관련이 있습니다. 서버 프로그램이 "하나의 스레드가 하나의 요청에 해당" 모드인 경우 c의 최대값이 제한됩니다. 지원할 수 있는 스레드 수에 따라 "하나의 프로세스가 하나의 요청에 해당" 모드인 경우 c의 최대값은 최대 프로세스 수에 따라 달라집니다.
또한 특별한 상황이 있습니다. 서버에서 제공하는 서비스가 "데이터 양이 적고 반환 시간이 길다"라는 특징을 가지고 있다고 비즈니스에서 판단하는 경우, 즉 바쁘지는 않지만 매우 느린 비즈니스 유형입니다. , 그러면 NIO를 사용할 수 있습니다. 모드는 서비스를 제공합니다. 예를 들어 nginx는 기본적으로 nio 모드를 사용합니다.
이 모드에서 c 값은 더 이상 스레드/프로세스 수와 관련이 없고 "소켓 연결 수"에만 관련됩니다. 일반적으로 "소켓 연결 수"는 매우 클 수 있으며, 특별히 구성된 Linux 서버에서는 동시에 수백만 개의 소켓 연결을 지원할 수 있습니다. 이 경우 c는 100만 개에 도달할 수 있습니다. t가 아무리 크더라도 여전히 매우 높은 q를 지원할 수 있습니다. 동시에 실제 스레드/프로세스 수는 CPU 활용도를 최대화하기 위해 CPU 코어 수와 일치하도록만 열 수 있습니다. 물론 이 모든 것의 전제는 "데이터량이 적고 반환 시간이 길다"는 점입니다. "특징귀하의 웹사이트가 정적 사이트이고 모든 요청이 nginx를 통과한다고 가정합니다. 그런 다음 테스트 머신과 서버 간의 네트워크 통신이 원활한지 확인해야 합니다. ab와 같은 도구는 스트레스 테스트에 그다지 설득력이 없습니다. jmeter 또는 loadrunner를 권장합니다. 스트레스 테스트 중에는 테스트 중인 서버의 실제 성능으로 간주되기 전에 테스트의 응답 시간 곡선이 일정 시간 동안 안정적인지 확인할 필요가 있습니다. 이는 특정 워밍업 시간 때문입니다. 일반적으로 일정 시간이 지나면 곡선이 안정화되고 현재 응답 시간을 판단합니다.
초당 요청 수 = 일정 기간 내에 완료된 총 요청 수/시간
동시성은 현재 유지되는 연결 수입니다.
netstat -net을 통해 모든 연결을 확인하세요.예:
으아악