考虑一个web应用程序，其中对应用程序的调用由运行多个MySQL查询的PHP脚本组成，其中一些是memcached。 PHP不会做非常复杂的工作。它主要是用一些格式化服务MySQL数据。使用Nginx代替Apache时，单独的MySQL服务器是否有意义？
过去曾建议将MySQL和应用程序引擎（PHP/Apache）放在不同的盒子上。但是，当数据可以水平分割时（例如，当有十个不同的客户使用该服务并且可以划分每个客户的数据时），并且当使用Nginx + FastCGI而不是较重的Apache时，doesn'不会使用Nginx + FastCGI，把Nginx的Memcache和MySQL放在同一个盒子里有意义吗？那么当更多的客户来到时，添加类似的盒子？
背景：我们正在转向Amazon Ec2。另外一个用于MySQL和应用服务器的盒子意味着双EBS卷（在应用服务器上需要保持代码不变，因为它经常变化）。此外，如果数据库框出现问题，则更多客户将失败。
说明：目前应用程序在单个服务器上运行LAMP（在转移到EC2之前）。
的托管你需要仔细衡量多少内存一切都有开销 - 我看不到enginex与Apache有什么不同，它是使用所有RAM的PHP（这反过来取决于Web服务器选择运行多少个进程，但这更像是一个调优问题）。
就我个人而言，我会远离enginex，理由是在生产中运行这样一个奇怪的服务器风险太大。
数据库总是需要大量ram，而且您可以明智地调整内存缓冲区的唯一方法是让它们位于专用服务器上。假设你有大数据。
如果你有非常小的数据，你可以保持它在同一个盒子。
同样，如果你没有在专门的盒子上运行它，memcached几乎没有意义。从MySQL获取内存给memcached真的是抢劫彼得支付保罗。 MySQL可以非常高效地在其innodb_buffer_pool中缓存东西（这可以节省IO，但最终可能会使用更多的CPU，因为您不会缓存表示逻辑等，这可能会对memcached产生影响）。
Memcached只有在您使用大量内存的专用盒子上运行时才是明智的;如果你的数据库服务器没有足够的咕噜声来服务你的应用程序的读取工作负载，这也是明智之举。在部署之前考虑这一点。
如果您的应用程序体系结构已经设计为在单独的实例上支持Nginx和MySQL，您可能希望将所有服务托管在同一实例上，直到获得足够的流量来证明分离。
一般来说，使用完整堆栈（Nginx +您的应用程序+ MySQL）创建新的相同实例会使您的设置更加难以维护。考虑采取备份，发布应用程序更新，修补数据库引擎，更新数据库模式，在所有客户端上生成报告等。如果您选择此方法，您将确实需要找到一些重大优势来抵消所有缺点。