每个人把nginx（或Apache等其他服务器）放在应用服务器前面的原因是每个人都有静态的内容，比如图片，CSS和JavaScript，以及对他们的应用来说是独特的奇怪的要求。

您的应用程序服务器（CherryPy，gunicorn，无论）都经过优化，可以运行您的应用程序并提供其输出。 虽然应用程序服务器也可以提供静态内容，但是它们几乎从来没有很好地完成这个任务，因为它是应用程序服务器的主要目的的次要。 （一些应用程序服务器也可以通过缩小和压缩CSS和JS来帮助，这样前面的Web服务器可以更快地提供这些资源。）

另外，实际的networking服务器可以做比高性能内容服务更多的function。 像caching，标题操作，URL重写，地理位置和许多其他function，只是将应用程序服务器膨胀到没有好的目的。

通常情况下，只有在开发应用程序时，只有当您是唯一的用户时，才能单独运行应用程序服务器，而性能不是问题。 即使你的网站stream量很低，你也希望它更快，对吧？ 低stream量的网站，一般不会成长为高stream量的网站…

为什么人们把Nginx放在前面？

1. Nginx是一个asynchronous的networking服务器。 这意味着它不会为每个连接分配一个线程或一个进程。 相反，它使用OS的首选套接字轮询库，因此能够处理成千上万个连接。 作为应用程序开发人员，为什么要关心？ 因为Nginx会caching连接，并且只在请求被完全读取时才将请求传递给您的CherryPy上游实例。 答复也一样。 这样，你的CherryPy应用程序（它是一个线程服务器，在很多方面都是Nginx的后台）变得asynchronous。 具体而言，您可以慢慢地解决客户端缓慢的问题，缓解loris DOS攻击。
2. Nginx具有开箱即用的连接速率限制。 说，我不想从同一个IP多于8个同时连接。
3. CherryPy有SSL问题 。 Nginx没有。
4. Python可以像C一样来回发送字节。Python的zlib只是C库的一个包装。 但是因为Nginx有效地处理连接，所以释放你的CherryPy工作线程在生产环境中提供静态内容是一个好主意，而且只能用于dynamic内容。
5. 在相同的端口，域，path等上复用多个CherryPy实例。通常还有其他configuration级别的灵活性。

使用CherryPy是否安全？

据其中一位原作者说， 是的 。 大多数与CherryPy有关的networking相关的东西都可以自己做。

CherryPy有一个应用程序的概念，你可以用一个CherryPy实例来提供多个应用程序 。 CherryPy也可以服务于其他WSGI应用程序 。

部署CherryPy

在传统的* nix风格的部署中，您可以编写初始化脚本，进行守护进程，放弃其特权，编写PID等。当您有几个CherryPy实例时，这并不重要。 当你有几十个时，它变得单调乏味，将stream程pipe理移交给Gunicorn或uWGSI并将你的CherryPy实例从HTTP切换到WSGI是有意义的。

我写了一个教程/项目框架， cherrypy-webapp-skeleton ，目标是填补在Debian上为networking开发人员部署（传统）实际CherryPy应用程序的空白。

包起来

1. 低stream量，无特殊要求→ CherryPy * 1 ⇐ HTTP ⇒ Client 。
2. 高stream量，特殊要求→ CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client 。
3. 数十个单独的CherryPy实例在同一台服务器上，急于浪费所有人的解决scheme → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client 。