Birden çok düşük trafikli CherryPy uygulamasını alt dizinler olarak dağıtmak için tek bir VPS kullanmayı planlıyorum; örneğin: example.com/app1, example.com/app2vb

WSGI dağıtımı üzerinde araştırma yaptıktan sonra, uygulamaları dağıtmak için tercih edilen yöntem, ters proxy kurulumunda bir WSGI sunucusu (Gunicorn, uWSGI, vb.) Ve NGinx kullanmaktır. Tandemde iki web sunucusu kullanmak aşırıya kaçmış gibi görünüyor - özellikle de CherryPy uygulamamın kendisi bir web sunucusu olduğundan - ancak her yerde göründüğü gibi fikri reddetmek istemiyorum . Kesinlikle bir uzman değilim, bu yüzden tartışmak istiyorum.

Üç seçenek görüyorum:

• CherryPy'yi kendi başına dağıtın.
• Gunicorn veya başka bir WSGI sunucusunun altına konuşlandırın.
• Bir WSGI sunucusunun altına konuşlandırın ve herkesin çözümü gibi görünen NGinx'e ters proxy uygulayın.

Sorularım:

• Bu modeli her yerde görmemizin ana nedeni nedir? NGinx bu kadar iyi mi?
• Düşük trafikli uygulamalar için yerel CherryPy sunucusu yeterince iyi mi, yoksa denememeliyim mi?

Herhangi bir tavsiye takdir, teşekkür ederim.

Herkesin nginx'i (veya Apache gibi başka bir sunucuyu) uygulama sunucularının önüne koymasının nedeni, herkesin resim, CSS ve JavaScript gibi statik içeriğe ve uygulamalarına özgü garip gereksinimlere sahip olmasıdır.

Uygulama sunucunuz (CherryPy, gunicorn, neyse), uygulamanızı çalıştırmak ve çıktısını sunmak için optimize edilmiştir. Uygulamanın sunucusu iken olabilir ayrıca statik içerik sunmak bu uygulama sunucusunun amacını ikinci beri, onlar neredeyse iyi bu görev için optimize asla. (Bazı uygulama sunucuları, CSS ve JS'nizi küçülterek ve sıkıştırarak da yardımcı olur, böylece öndeki web sunucusu bu kaynakları daha hızlı sunabilir.)

Ayrıca, gerçek web sunucusu yüksek performanslı içerik sunumundan çok daha fazlasını yapabilir. Önbellekleme, başlık manipülasyonu, URL yeniden yazma, coğrafi konum belirleme ve uygulama sunucusunu iyi bir amaç için şişiren diğer birçok özellik gibi şeyler.

Genellikle uygulama sunucusunu yalnızca uygulamayı geliştirirken, yalnızca kullanıcı olduğunuzda çalıştırırsınız ve performans bir sorun değildir. Siteniz trafiği az olsa bile daha hızlı olmasını istiyorsunuz, değil mi? Yavaş trafik seviyesi düşük siteler genellikle yüksek trafikli sitelere dönüşmez ...

İnsanlar neden Nginx'i öne koyuyor?

1. Nginx, eşzamansız bir web sunucusudur. Bu, bağlantı başına bir iş parçacığı veya işlem ayırmayacağı anlamına gelir. Bunun yerine OS'nin tercih edilen soket yoklama kütüphanesini kullanır ve böylece yüz binlerce bağlantıyı yönetebilir. Uygulama geliştiricisi olarak neden ilgilenmelisiniz? Çünkü Nginx bağlantıları arabelleğe alır ve yalnızca istek tamamen okunduğunda CherryPy akış yukarı örneğinize iletir. Yanıtlar için de aynı şey geçerli. Bu şekilde, Nginx'in arkasında iş parçacıklı bir sunucu olan CherryPy uygulamanız birçok anlamda eşzamansız hale gelir. Özellikle, yavaş bir istemci sorunu ve yavaş loris DOS saldırılarına el sallamak.
2. Nginx'in bağlantı hızı sınırlayıcıdır. Aynı IP'den 8'den fazla eşzamanlı bağlantı istemiyorum.
3. CherryPy'de SSL sorunu var . Nginx bilmiyor.
4. Python, baytları neredeyse C kadar iyi ileri geri gönderebilir. Python's zlib, C kütüphanesinin etrafındaki bir paketleyicidir. Ancak Nginx bağlantıyı etkin bir şekilde ele aldığından CherryPy çalışan iş parçacıklarınızı üretimde statik içerik sunmaktan ve yalnızca dinamik içeriğe adamaktan kurtulmak iyi bir fikirdir.
5. Aynı bağlantı noktası, etki alanı, yol vb. Üzerinde birkaç CherryPy örneğini çoğaltma. Genel olarak başka bir yapılandırma düzeyinin ek esnekliği.

CherryPy'yi tek başına kullanmak güvenli mi?

Orijinal yazarlardan birine göre, evet . CherryPy ile kendi başınıza yapabileceğiniz web ile ilgili şeylerin çoğu.

CherryPy bir uygulama kavramına sahiptir ve bir CherryPy örneği ile çeşitli uygulamalar sunabilirsiniz . CherryPy ayrıca diğer WSGI uygulamalarına da hizmet verebilir .

CherryPy'i Dağıtma

Geleneksel bir * nix tarzı dağıtımda, init betiği yazıyor, işlediğiniz cinsten, ayrıcalıklarını bırakıyor, PID'sini yazıyorsunuz, vb. Düzinelerce, sıkıcı hale gelir ve süreç yönetimini Gunicorn veya uWGSI'ye devretmek ve CherryPy örneklerinizi HTTP'den WSGI'ya değiştirmek mantıklıdır.

Bir web geliştiricisi için Debian üzerinde gerçek bir CherryPy uygulaması dağıtmak (geleneksel) için boşlukları doldurmak olan bir öğretici / proje iskeleti, cherrypy-webapp-iskelet yazdım .

Sarmak

1. Düşük trafik, özel gereksinim yok → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Yüksek trafik, özel gereksinimler → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Bir overkill için istekli aynı sunucuda ayrı CherryPy örnekleri, düzinelerce herkesin çözümü → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.