(disqus.com 및 getentry.com에서) 많은 실험 끝에 uwsgi가 Python 세계의 표준이 되어야 한다고 확실히 말할 수 있습니다. 이를 nginx와 결합하면 Python 기반 웹 애플리케이션의 스레드(또는 스레드가 아닌)에서 더 나은 성능 경험을 얻을 수 있습니다.

업데이트: "제공하는 모든 측정항목은 느립니다"라는 오래된 말을 무시하세요. 여기서 요청은 백엔드 노드를 의미하며 들어오는 이벤트(크기가 20KB에서 1MB에 이르는 요청)를 처리하고 네트워크의 다양한 홉을 통과합니다. 정책이며 대부분 일부 대기열 작업을 형성합니다. 최대한 많은 작업 부하를 오프로드하세요. (이 문단의 번역에 문제가 있으니 원문, 번역자 노트를 참고해주세요)

서비스 전략

Python 애플리케이션을 실행하는 방법은 이미 여러 가지가 있습니다. 나는 mod_wsgi를 사용하지 않을 것이며 가장 중요한 것은 이벤트 모델이 어떻게 작동하는지 설명하려고 하지 않는다는 것입니다. 나는 이것이 Python 세계에서 여전히 사용되고 있다고 믿지 않으므로 이 기사의 주제는 전통적인 스레드(또는 다중 프로세스) Python 애플리케이션에 관한 것이 아닙니다.

대신, 가장 잘 알고 있는 가장 인기 있는 두 가지 솔루션인 gunicorn과 uwsgi에 중점을 두겠습니다.

Gunicorn(Python UNIX 플랫폼용 wsgi 서버)

과거를 돌이켜보면 Python의 웹 서버에 대한 솔루션은 기본적으로 mod_wsgi였습니다. 최근 가장 인기 있는(또는 유행하는 것으로 간주되는) 방법 중 하나는 Gunicorn입니다.

사실 저는 여전히 불편함을 크게 줄여주는 gunicorn을 사용하는 것을 권장합니다. Django를 아름답게 내장하고 설정도 쉽습니다.

또한 uwsgi와 동일한 구성 옵션이 10% 있지만(일부 사람들에게는 좋은 점임) 그 외에는 uwsgi(또는 다른 Python 웹 서버)와 거의 동일한 기본 기능을 제공합니다.

으으으으으

제 생각에는 이것이 Gunicorn에서 uwsgi까지 유일한 옵션입니다. 더 높은 성능, 이해하기 쉬운 더 많은 구성 옵션, 프로토콜을 통해 nginx와 상호 작용할 수 있는 기능도 이점을 추가합니다.
구성도 매우 간단합니다. 관련 기사를 찾아 나중에 자세히 알아보세요.
나는 uwsgi를 사용하여 일부 애플리케이션을 실행하기 시작했고 –processes=10 및 –threads=10을 사용하여 서버의 다중 CPU를 테스트했습니다.

• 지원

• 
  

• 메모리 사용량 감소 가능성 테스트

• 
  

• 테스트 스레드 안전 지원

(이러한 테스트가 가치가 있는지에 대해서는 DISQUS가 단일 스레드에서 실행됩니다. 최대한 간소화하고 각 노드의 기능을 최대화하고 싶습니다.)

성공을 향한 지속적인 반복

평균 API 응답 시간을 40ms 미만으로 단축했는데, 이는 매우 자랑스럽습니다. 여기서 말하는 API 응답 시간은 요청이 Python 서버에 도달하는 시점부터 서버가 프록시에 응답을 반환하는 시점까지 걸리는 시간을 의미합니다.

불행하게도, 점점 더 많은 트래픽이 발생하고 액세스 급증이 발생하면서 응답 시간이 잘못되기 시작했습니다. 서비스 노드에 여전히 약 30%의 메모리가 있음에도 불구하고 변동하는 응답 시간이 더 이상 처음에 상상했던 것과 일치하지 않았습니다. 그리고 자원의 60%를 사용할 수 있습니다.

많은 조정 후에 우리는 다수의 uwsgi 프로세스를 비활성화하고 nginx에서 로드 밸런싱을 수행하도록 했습니다(이전에는 uwsgi 자체에서 로드 밸런싱을 수행했습니다).

이것이 의미하는 바는 uwsgi process=10을 수행하는 대신 --processes=10 대신 10개의 별도 uwsgi 인스턴스를 실행한다는 것입니다.

그 결과 아름답고 일관적인 20ms의 평균 응답 시간이 탄생했습니다.

API 응답 시간

함께 모아보세요

저는 이야기하는 것보다 직접 해보는 것을 좋아합니다. 따라서 여기서는 온라인 서버의 실제 설정에 대해 설명하겠습니다.

nginx

첫 번째 구성은 Nginx입니다. 실제로 uwsgi 프로세스 백엔드 수를 계산하고 추가해야 하므로 상황이 약간 복잡합니다.

​먼저 웹 페이지

# recipes/web.rb

hosts = (0..(node[:getsentry][:web][:processes] - 1)).to_a.map do |x|
  port = 9000 + x
  "127.0.0.1:#{port}"
end

template "#{node['nginx']['dir']}/sites-available/getsentry.com" do
  source "nginx/getsentry.erb"
  owner "root"
  group "root"
  variables(
    :hosts => hosts
  )
  mode 0644
  notifies :reload, "service[nginx]"
end

에서 구성 목록을 만듭니다. Nginx의 구성은 매우 간단합니다:

# templates/getsentry.erb

upstream internal {
<% @hosts.each do |host| %>
  server <%= host %>;
<% end %>
}

server {
  location / {
    uwsgi_pass         internal;

    uwsgi_param   Host                 $host;
    uwsgi_param   X-Real-IP            $remote_addr;
    uwsgi_param   X-Forwarded-For      $proxy_add_x_forwarded_for;
    uwsgi_param   X-Forwarded-Proto    $http_x_forwarded_proto;

    include uwsgi_params;
  }
}

이제 uwsgi 구성에서 사용하는 소켓 주소인 포트 9000부터 시작하여 uwsgi 호스트 수와 할당된 가중치 값을 설정했습니다.

으으으으으

반면에 우리는 Supervisor를 사용하여 uwsg 프로세스를 제어하는데 이 역시 매우 간단합니다.

# recipes/web.rb

command = "/srv/www/getsentry.com/env/bin/uwsgi -s 127.0.0.1:90%(process_num)02d --need-app --disable-logging --wsgi-file getsentry/wsgi.py --processes 1 --threads #{node['getsentry']['web']['threads']}"

supervisor_service "web" do
  directory "/srv/www/getsentry.com/current/"
  command command
  user "dcramer"
  stdout_logfile "syslog"
  stderr_logfile "syslog"
  startsecs 10
  stopsignal "QUIT"
  stopasgroup true
  killasgroup true
  process_name '%(program_name)s %(process_num)02d'
  numprocs node['getsentry']['web']['processes']
end

위치선택

왜 다른 방법(또는 이 경우에는 작동하지 않는 방법)이 있어야 하는지 매우 설득력 있는 주장을 누군가 내놓지 않는 한, Python 세계가 더욱 표준이 됨에 따라 이 패턴에 대해 듣고 싶습니다. 최소한 uwsgi 내에서 프로세스 관리를 개선하는 방법에 대한 논쟁이 촉발되기를 바랍니다.

위 내용은 Nginx + UWSGI 사용 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!