Web和数据库服务器之间的2-5毫秒是否合适? (不同的数据中心)

我目前有一个在数据中心(DC)1中运行的专用networking和数据库服务器。我正要扩展数据中心2中的另一个networking服务器,它将与DC 1中的数据库进行通信。

两个数据中心之间的延迟大约为2-5毫秒。 适合高stream量的网站(每天有400,000多人)?

也许(TM)。 这当然不会帮助你的performance,而且我会担心,只是从潜在的故障模式引入我的机器,这可能不是你最大的性能问题。

另一方面,如果托pipe服务提供商能够推送这些服务器,这是惊人的,所以我会告诉您的提供商,他们提出的解决scheme对于您的需求是不可接受的,如果他们无法在与现有机器相同的networking中部署另一台服务器,那么你会把你的业务放在其他地方。 有机会他们会奇迹般地发现附近的一些空间。

2-5毫秒不是不好的恕我直言。 再次,这也取决于你的应用程序如何处理数据库调用。

更有意思的是,可能要考虑容错 ,您可能需要在DC2中设置一个相同的解决scheme,这样您就可以同时拥有一个数据库服务器,这样您就可以快速从一个数据中心中的任何灾难中恢复。 2-5ms的延迟对于数据库复制非常合适,如果使用mySQL,甚至可以设置多主机复制,并在Web服务器和最近的数据库服务器之间获得更好的性能

尽pipe推动服务提供商达到可接受的性能水平没有任何问题,但您还需要“面对现实”。 如果数据中心距离300公里,则前2ms仅仅是因为光纤WAN线路甚至不能超过光速(大约300.000km / s)。 平时是一个往返时间,所以300公里实际上是指行驶600公里(每路300公里)的时间。 这需要2毫秒的光速,并没有托pipe服务提供商可以篡改像光速的物理常数

回答你的问题是不太可能的 – 你没有提供任何对你网站影响的衡量标准,也没有定义你的绩效目标。

但是,一个重要的指针:许多webapp框架使用阻塞式读取策略 ,即当webapp框架正在进行SQL查询时,问题中的webapp线程被标记为操作系统繁忙。 所以你可以看到前端服务器上的CPU使用率显着增加,因为增加了SQL查询延迟。

一些像ASP.NET MVC这样的webapp框架提供了一个asynchronousI / O接口,可以缓解上述问题。 但是asynchronousI / O在默认情况下不会被使用,而且重新构build您的站点代码来使用它几乎肯定会太贵。

为什么不把旧的服务器迁移到新的DC中,并为新的DC中的所有服务器设置一个很好的专用VLAN?

这对我来说似乎相当高,虽然我在不同的networking上有数据库,但他们一直处于相同的物理位置,所以延迟不是问题。 根据每次请求平均处理多less个查询(以及您在Web /应用程序层中进行的caching有多less),可能真的开始累积起来。 我想在模拟适合您的使用模式的负载时进行彻底的testing。

是否有一个原因,你在不同的数据中心build立一个Web服务器? 如果是为了冗余,也许在数据中心2设置复制scheme到另一个本地数据库会更合适。