Neden Nginx'e ve Gunicorn gibi bir şeye ihtiyacım var?

Aşağıdaki soruya aşırı basitleştirilmiş bir cevap arıyorum. Nginx'in Gunicorn gibi bir şeyle birlikte nasıl çalıştığına dair temel bir anlayış oluşturmaya çalışıyorum.

Django uygulamalarını Nginx'e yerleştirmek için hem Nginx'e hem de Gunicorn gibi bir şeye ihtiyacım var mı?

Öyleyse, HTTP isteklerini gerçekte ne işliyor?

Ps. Apache ve mod_wsgi kullanmak istemiyorum!

Aşırı derecede basitleştirilmiş: Python'u çalıştıran bir şeye ihtiyacınız var ancak Python her türlü talebi yerine getirmede en iyisi değil.

[feragatname: Ben bir Gunicorn geliştiricisiyim]

Daha az basitleştirildi: Hangi uygulama sunucusunu kullandığınızdan bağımsız olarak (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) herhangi bir önemsiz olmayan dağıtım türü, Django uygulamanızın işlememesi gereken istekleri yerine getirecek bir akışa sahip olacaktır. Bu tür isteklerin önemsiz örnekleri statik varlıklardır (images / css / js).

Bu, klasik “üç katmanlı mimari” nin ilk iki katmanıyla sonuçlanır. Yani, web sunucusu (sizin durumunuzdaki Nginx), görüntüler ve statik kaynaklar için birçok talebi yerine getirecektir. Dinamik olarak yaratılması gereken talepler daha sonra uygulama sunucusuna iletilecektir (örneğinizdeki Gunicorn). (Bir kenara, üç kademenin üçte biri veritabanıdır)

Tarihsel olarak konuşursak, bu katmanların her biri ayrı makinelerde barındırılıyordu (ve muhtemelen ilk iki katmandaki birden fazla makine olacaktı, yani: 5 web sunucusu, tek bir veritabanını sorgulayan iki uygulama sunucusuna istek gönderir).

Modern çağda artık tüm şekil ve boyutlarda uygulamalara sahibiz. Her hafta sonu projesi veya küçük işletme sitesi aslında birden fazla makinenin beygir gücüne ihtiyaç duymuyor ve oldukça mutlu bir şekilde tek bir kutuda çalışacak. Bu, barındırma çözümleri dizisine yeni girdiler getirdi. Bazı çözümler uygulama sunucusuyla web sunucusuyla evlenir (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, vb.). Ve veritabanını bu web / uygulama sunucu kombinasyonlarından biriyle aynı makinede barındırmak da nadir değildir.

Şimdi Gunicorn örneğinde, Nginx'in proxy davranışı üzerine güvenirken, işleri Nginx'ten ayrı tutmak için özel bir karar verdik (Ruby'nin Unicorn'inden kopyalamak). Spesifik olarak, Gunicorn’in hiçbir zaman doğrudan internetten bağlantıları okumayacağını farz edersek, yavaş olan müşteriler için endişelenmemize gerek kalmaz. Bu, Gunicorn için işleme modelinin utanç verici derecede basit olduğu anlamına gelir.

Ayırma ayrıca Gunicorn'un saf Python ile yazılmasına izin verir, bu da geliştirme maliyetini en aza indirirken performansı etkilemez. Ayrıca, kullanıcılara başka proxy'ler kullanma olanağı da sağlar (doğru tamponlama yaptıklarını varsayarak).

HTTP isteğini gerçekten neyin karşıladığı hakkındaki ikinci sorunuza gelince, basit cevap Gunicorn. Tam cevap hem Nginx hem de Gunicorn'un talebi karşılaması. Temel olarak, Nginx isteği alacak ve eğer dinamik bir istek ise (genellikle URL modellerine dayanarak), o zaman bu isteği işleyecek olan Gunicorn'a verecek ve sonra Nginx'e bir cevap döndürecek ve ardından cevabı orijinaline geri gönderecektir. istemcisi.

Yani kapanışta, evet. Uygun bir Django konuşlandırması için hem Nginx'e hem de Gunicorn'a (veya benzer bir şeye) ihtiyacınız var. Eğer özellikle Django'yu Nginx ile ağırlamak istiyorsanız, o zaman Gunicorn, mod_uwsgi ve belki de CherryPy'i Django tarafının adayı olarak araştırırdım.

Bu açıklamayı sadeliği içinde sevdim:

Nginx dış dünya ile karşı karşıya kalacak. Doğrudan dosya sisteminden medya dosyalarına (görüntüler, CSS vb.) Hizmet eder. Ancak, doğrudan Django uygulamalarıyla konuşamaz; uygulamayı çalıştıracak, web'den istediği beslemeleri ve yanıtları döndürecek bir şeye ihtiyacı var.

Bu Gunicorn'un işi. Gunicorn, bir Unix soketi yaratacak ve wsgi protokolü ile nginx'e yanıt verecek - soket verileri her iki yönde de iletir:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071

Aşırı basitleştirilmiş bir cevap arıyorum ...

Django uygulamalarını Nginx'e yerleştirmek için hem Nginx'e hem de Gunicorn gibi bir şeye ihtiyacım var mı?

Öyleyse, HTTP isteklerini gerçekte ne işliyor?

Aşırı basitleştirilmiş cevap:

EVET.

Hem Nginx hem de Gunicorn.

Nginx'te konuşlandırdığınız için, elbette Nginx'e ihtiyacınız var.

Bir web çerçevesi olan Django'yu kullandığınız için, web sunucusu (Nginx) ile web çerçevesi (Django) arasındaki konuşmayı köprüleyen bir şeye ihtiyacınız var. Python dünyasında, böyle bir şeye bir WSGI sunucusu denir (fakat bunun bir orta gereç gibi olduğunu düşünün), bunlara örnekler Gunicorn ve uWSGI'dır. Bir isteği işlerken, Nginx, isteği Django kodunu çağırarak yanıtı veren Gunicorn veya uWSGI'ya bildirir.

Bu belge ve Paul'un cevabı daha iyi öğrenmenize yardımcı olacaktır.

Gunicorn bir kaynak kaybıdır. Proxy geçişini üstteki django'da topicorn çalıştırmak yerine bir bağlantı noktasını dinleyerek django'ya ve tüm bunların üzerine tekrar nginx yapabilirsiniz. Kriterlerde, gözle görülür bir hız artışı olduğunu gördüm. Nginx, django'ya doğrudan istekleri kolayca yapabilir. Gunicorn normal yolun üstünde bir köprüden (aslında daha yavaş bir köprü) başka bir şey değildir. Sadece oturur ve kaynaklarınızı yer ve web sitenizi güçlendirdiğini iddia etmeye çalışır.

nginx temel olarak tüm istekleri tamponlar ve statik dosya isteklerini kendisi yapar (eğer böyle yapılandırdıysanız). Ve tüm dinamik içeriği başka bir sunucuya proxy'ler. (Gunicorn / django).

Gunicorn'ın sadece talebi kabul etmekten başka bir faydası yoktur. Doğrudan camdan içebileceğiniz veya pipetten sınırlı bir hızda içebileceğiniz bir pipet gibidir (burada içen kişi django). Ve nginx sana bir bardak meyve suyu getiren garson.

Ben karşılaştırmalı buldum ve bunu buldum - gunicorn ile: 22k req / s gunicorn olmadan: 34k req / s

Siteniz ağır yük altında fazladan taleplere ihtiyaç duyacak.