我们开发和维护Web应用程序; 并在我们目前的设置; 我们正在使用数据库服务器，应用程序服务器和Web服务器的三层系统。
到现在为止还挺好。
我们面临的问题是， 理论上这个设置是为了帮助我们平衡这些机器之间的负载，并根据需要插入新的碎片。 在实践中，这种对我们后台networking的压力正在成为一个严重的瓶颈。
还有服务静态文件的问题; 由于我们目前的设置; 这些必须由应用程序提供服务（耗尽可用于处理传入请求的FastCGI进程），或者首先在运行应用程序的机器上使用Web服务器作为本地代理。
那么问题就变成了：
只需将Web和应用程序服务器合并为一个; 它带来的configuration简化; 和访问的直接性（本地套接字而不是TCP）; 以及通过Web服务器提供静态文件的能力提高可能会提高性能; 还是有我错过的开销因素？
一般来说，我是分散架构的粉丝：数据库服务器场，“公共www”服务器场（商业网站）和应用服务器场 – 可能需要其他中间件层。
这背后的逻辑是旧的 – 基本上，公共www服务器不需要访问任何敏感的数据，所以一些好奇的黑客在www.mycompany.com捅了我们的营销网站可能会妥协，但他们没有得到还要别的吗。
这里有一些其他的一般想法…
回复：networking负载的后盾，如果我们谈论的是与您的FastCGI主机联系的stream量负载，我会说在这些机器上粘贴Web服务器，让他们直接与外部世界交stream可能是一个好主意。
要记住的一件事是在安全性妥协的情况下保持数据库的隔离/保护，这可能是将FastCGI内容推送到Web服务器上的一个参数，并且写出更轻量级的内容来与数据库交谈。
（如果我们正在谈论别的东西让我知道，我会摆在它:-)
Re：静态文件问题，有很多方法可以解决这个问题。
把静态数据的副本放在每个需要发送的服务器上。
我们称之为“磁盘便宜”方法 – 它避免了在托pipe静态内容的单个盒子上倾倒大量的负载，并消除了单点故障。 缺点是你必须以某种方式同步这些内容（部署脚本，cron'd rsync，cvs / git / svn等）
在您的前端服务器上安装caching基础结构
这是类似于上面的“磁盘便宜”的解决scheme，只有一个后端服务器具有静态内容，当前端服务器需要时，它们caching$ LIFETIME的副本，从而不需要同步脚本（caching基础设施为你做）。
把你的静态内容放在内容交付networking上
这真的只适用于如果你不做SSL的东西 – 商业CDN解决负载问题，并为用户提供地理分布点，他们可以抓住你的内容。 不足之处在于大多数浏览器都会采用SSL，除非你的CDN也是安全的（即使偏执狂的浏览器应该正确地抱怨）。