跨多个服务扩展Web应用程序

我们正在开发我们的Web应用程序,并一直在努力减less我们的加载时间。 当我们开始开发应用程序时,我们与一家知名的托pipe服务提供商签约,在云上提供“专用解决scheme”。 因此,我们为我们的Web应用程序提供一台专用服务器,为我们的数据库提供一台专用服务器。 两台服务器都安装了相同数量的RAM,相同的CPU和SSD驱动器。 即使在我们的基础设施投入时间和资金,我们注意到8-10秒的加载时间。

我们被另一个托pipe公司告知,我们应该缩减并将所有内容放到一个服务器上(而不是分割)。 他们提到,由于networking延迟,将服务器分开将导致更高的加载时间,并声明PHP将通过套接字比通过networking更快地与SQL进行通信。 我知道这是真的,但我没有想到我们得到的结果。 将所有内容移动到原来的应用程序服务器后,我们的加载时间从8-10秒降到3-4秒!

问题是,我们现在正在寻找一个新的托pipe服务提供商,并build议使用负载平衡器,数据库服务器,应用程序服务器和规模的集群。 值得关注的是,如果我们将应用程序和数据库服务器再次分开,我们将回到原点。

从我读过的所有内容看来,几乎总是build议将这些服务器拆分而不是组合在一起。 在设置正确的时候这样做是否会带来性能上的提升,还是仅仅为了长期的可伸缩性呢?

我感谢帮助!

你的问题是非常广泛的,所以我只提到几个方面:

  • 本地套接字I / O速度比TCP快,但对于大多数应用程序来说,与周转时间的其他部分(负载平衡器,PHP处理,数据库查询处理…)相比,这应该是微乎其微的。

  • 拆分系统允许更好的caching,例如DB服务器可以在RAM中保留更多的索引。

  • 可能是一个可扩展性点:拆分系统更容易configuration,例如部署一个新的软件版本或更新PHP,你可以添加一个新的应用程序服务器,testing它,最后删除旧的。

  • 调查您的问题:检查为每个Web请求打开了多less个数据库连接。 测量的一个解释是使用许多 SQL查询而没有持久连接的应用程序,因此为每个数据库访问打开一个新的TCP连接。

我不知道你在做什么来获得8-10秒的加载时间(假设你把“加载时间”定义为“HTTP请求到达和页面被build立并发送到浏览器之间的时间)”。

您不应该能够通过Web服务器和数据库使您的CPU达到100%的使用率,即使您以某种方式进行pipe理,将Web服务器和数据库放在一台服务器上也无济于事。

而且,DB服务器上的任何一种过载都不会通过在同一硬件上移动两个服务器来缓解。

所以这个问题几乎必须要处理

  • 非常多的非常小的SQL语句被单独发送到数据库,因此即使是本地networking上的小延迟也会累积(想象一下,每页有10000个SQL语句,networking延迟为0.1毫秒,这将导致10秒的负载时间)。
  • 存储在数据库中的大数据块需要通过sql连接到达Web服务器,这通常比为文件传输devise的协议慢,特别是在networking上
  • 您的主机之间的networking连接被人为地限制在某种程度上

也许这是我目前无法想象的东西,因为一个典型的Web应用程序分布在更多的CPU上时速度会变慢,只要这些CPU之间有一个快速的networking连接,这是非常罕见的。

只要你不知道在不同的主机上是什么原因造成了麻烦,你可能会再次遇到同样的问题,或者你可能不会。

去年我遇到了第一个问题 – 我的一个客户签约了第三方为他们开发一些软件。 演示笔记本电脑上的典型操作需要大约4个小时才能完成。 当我的客户将软件移动到预期的生产环境(BIG应用服务器,BIG数据库集群)时,同样的事情花了超过16个小时。 通过查看日志并进行networking跟踪,我们发现应用程序在开发系统上每秒执行了大约15000次select,而应用程序服务器和数据库之间的延迟为0.3毫秒,将其限制为每秒稍微超过3000次select。 开发人员被告知要改变他们访问数据库的方式(在两个表上进行连接,而不是一个select,然后对每个结果进行单行select),导致整个操作less于30分钟。

问题是,你遇到的麻烦是不寻常的,可能与你的软件行为exception有关,你真的应该调查这里发生了什么,以及为什么双机设置慢得多。

拆分为2台机器通常应该可以提高性能,因为您有更多的CPU来完成这项工作。 这也增加了可维护性。 您的数据库可能需要特殊的内核参数或修补程序级别才能正常工作; 您的Web服务器可能有冲突的要求。 而且,无论何时进行升级,都可以轻松升级两个系统中的一个,而无需另一个。