다음과 같이 웹사이트와 동일한 서버에서 Apache Bench를 실행할 때:
ab -n 1000 -c 10 localhost:8080/
다양한 위치에서 서버를 공격하는 사용자와 비교할 때 정확한 결과를 얻지 못할 가능성이 높습니다.
중국 사용자는 동일한 주/국가에 있는 사용자와 비교할 때 대기 시간 문제가 다르기 때문에 이것이 실제 성능에 어떻게 또는 왜 영향을 미치는지 이해하려고 노력하고 있습니다.
내 웹 서버의 최대 스레드 제한이 100이라고 가정해 보겠습니다.
최종 사용자 대기 시간이 서버 성능에 어떤 영향을 미칠 수 있는지 자세히 설명할 수 있는 사람이 있습니까?
여기서는 각 요청이 10ms에 동일하게 계산된다고 가정합니다.
내가 이해하지 못하는 것은 외부 요인이 전반적인 서버 성능, 특히 인터넷 연결(위치 또는 모바일과 같은 장치) 및 http/tcp 핸드셰이크 등에 어떻게 영향을 미칠 수 있는지입니다.
답변1
일반적으로 최종 사용자 대기 시간은 서버 성능에 영향을 미치지 않습니다. 주요 차이점은 최종 사용자 대기 시간이 높을수록 각 연결을 완료하는 데 시간이 조금 더 걸리기 때문에 서버가 한 번에 더 많은 연결을 갖게 된다는 것입니다. 그러나 서버는 여전히 각 연결에 대해 동일한 양의 작업을 수행합니다. 서버 제한(주로 메모리)에 도달하지 않는 한 문제가 되지 않습니다.
서버는 전체 요청이 완료될 때까지 연결에 대한 무거운 작업을 시작하지 않습니다. 따라서 연결을 설정하고 요청을 받는 데 시간이 더 오래 걸린다면 서버는 기본적으로 아무것도 하지 않고 실제 처리를 수행하기 전에 조금 더 기다려야 한다는 의미일 뿐입니다.
일반적으로 서버는 요청을 처리하고 한 번에 응답을 대기열에 넣습니다. 그러면 클라이언트 및 네트워크 대기 시간으로 인해 해당 대기열을 비우는 데 시간이 조금 더 걸릴 수 있습니다. 그러나 이를 처리하는 서버 부분은 크게 최적화되어 있으며 특정 페이지나 개체에 대한 논리는 이미 응답 생성을 완료하기 위해 실행되었습니다. 다시 말하지만 일반적으로 서버 성능에는 큰 영향이 없습니다.
그러나 클라이언트 경험은 훨씬 더 나쁠 수 있습니다. 클라이언트가 서버에서 정보를 가져온 다음 추가 정보를 얻기 위해 다시 연결해야 하는 경우가 서비스에 많은 경우 특히 그렇습니다. 예를 들어, 웹 페이지가 클라이언트에게 여러 프레임을 로드하라고 지시하고 해당 프레임이 클라이언트에게 여러 이미지를 로드하라고 지시하는 경우, 클라이언트가 실행되기 전에 많은 "뒤로" 작업(각각 네트워크 대기 시간이 증가함)이 발생합니다. 클라이언트는 결과를 봅니다. 그러나 서버는 동일한 양의 작업을 수행합니다.
답변2
실제로 실시간으로 작동하는 다중 다중 프로세서(예: 1K CPU 수), 많은 메모리 슈퍼 컴퓨터가 없으면 문제가 되지 않습니다.
다중 프로세스 시스템에서 모든 프로세스에는 시간 창(time window)이 있습니다 Quantum Size. 대략 80년대부터 90년대까지 현재까지의 경우인 다중 프로세스 기능을 갖춘 운영 체제는 실행 중인 프로세스 사이를 앞뒤로 전환하여 각 프로세스에 양자 크기를 제공합니다. 이 시간 창은 현대 운영 체제에서 약 20밀리초이며 전환은 매우 낮은 전환 오버헤드로 매우 빠르게 수행됩니다. 예를 들어, 하나의 CPU가 있고 두 개의 프로세스가 1초(1000밀리초에 해당) 사이에 전환되면 900-950-980(어쩌면)밀리초 동안 실행할 수 있습니다(프로세스 전환에는 차이가 없습니다). ). 어쨌든 제가 말했듯이 이 전환은 매우 빠르게 이루어지며 50개의 프로세스가 실행되고 있다고 상상해 보면 모든 프로세스가 동시에 실행되는 것을 볼 수 있습니다. 실제로는 그렇지 않으며 다중 처리, 프로세스 스케줄링의 기본입니다...
프로세스에 다중 스레드가 있는 경우 OS는 먼저 프로세스를 예약하고 퀀텀을 제공한 다음 해당 프로세스의 스레드를 예약합니다. 그리고 그 양자에서는 스레드도 예약됩니다. 전체 퀀텀이 종료되면 OS는 다른 프로세스(또는 스케줄링 알고리즘에 따라 동일)를 예약하고 해당 새 프로세스의 스레드도 예약됩니다.
스레드에는 두 가지 수준의 실행 환경이 있습니다. 하나는 사용자 수준이고, 두 번째는 커널 수준입니다. 위에서 언급한 것은 사용자 수준입니다. 프로세스 스케줄링, 해당 양자 크기의 스레드 스케줄링. 그러나 커널 수준으로 내려가면 스케줄러는 서로 다른 프로세스에서 서로 다른 스레드를 예약할 수 있습니다. 퀀텀은 커널 수준에서 스레드에 직접 적용됩니다.
모든 내용을 살펴본 후 최종 연결 대기 시간이 서버 성능에 어떤 영향을 미칠 수 있는지 이해해 보겠습니다.
최대 성능을 원한다면 스레드가 커널 수준에 있어야 하며, 아파치 스레드는 커널 모드에 있지 않다는 것을 알고 있습니다. Apache 자체는 사용자 모드에 있고 사용자 측 애플리케이션이며 해당 스레드는 사용자 수준 모드에서 실행됩니다. 따라서 어떤 식으로든 해당 서버에서 100%의 성능을 얻을 수 없습니다. 스레드가 커널 모드에서 실행되고 있고 CPU가 두 개 있다고 가정해 보겠습니다. 첫 번째 CPU에 스레드 1개, 두 번째 CPU에 스레드 1개. 이제 두 개의 스레드가 실제로 동시에 실행되고 있습니다. 웹 작업자 스레드는 실제로 I/O BoundedOS 관점에서 볼 때 스레드이며 일부 파일을 요청하면 파일이 준비될 때까지 차단됩니다. 스케줄러는 실행할 다른 작업자 스레드를 예약합니다. '해당' 파일이 준비되면 차단된 스레드는 준비 대기열로 이동하고 다시 예약됩니다. 그럼 정말 좋습니다... 작업자 스레드가 100개 있으면 어떻게 될까요? 이 질문은 또 다른 질문을 가져옵니다. 작업자 스레드가 언제 생성됩니까?
웹 서버 애플리케이션에 대해 말하면 작업자 스레드는 low-level IP connection is made. 따라서 실제 두 스레드가 이미 실행 중이고 하드웨어에 의해 새 연결이 설정되었으며(자체 PU가 있고 데이터 정보 전송을 위한 기본 시스템이 중단됨) 새 작업자 스레드가 팝업되어 예약을 위해 준비 대기열로 전송되었습니다. ...
기본 주제로 돌아가서 외부 요인이 시스템 성능에 어떤 영향을 미치는지 알아보겠습니다. 그것은 시스템 제한에 관한 것입니다. 스레드 수는 시스템이 이를 처리할 수 있는 충분한 프로세스 단위가 있는지 여부에 따라 성능에 영향을 미칩니다. 기본 수학, 두 개의 프로세서는 동시에 두 개의 스레드만 처리합니다. 네트워크 연결 불량 폭은 "허용할 수 있는 연결 수"에 따라 성능에 영향을 미칩니다. 연결 데이터가 10바이트이고 대역폭이 초당 100바이트라고 가정하면 초당 10개의 연결을 가질 수 있습니다.
이를 확장하는 것은 귀하에게 달려 있습니다. 한 가지만 기억하면 됩니다. 총 CPU 리소스가 이미 준비 대기열에 있는 스레드를 처리하고 있습니다. 따라서 새 스레드가 팝업되어도 현재 스레드의 상황이 악화되지는 않습니다.
서버 앱을 사용할 때 성능이 문제가 될 수 있습니다. 처음 시작합니다. 곧 상한선에 도달하게 됩니다. 일종의 자동차 가속이다. 먼저 가속되고 일정 시간이 지나면 최고 속도에 도달합니다. 연료가 부족하거나 가속 페달에서 발을 떼기 전까지 최고 속도로 이동할 수 있습니다.