当将数据库和web服务器分开时，RDS性能真的很差吗？

Question

我们目前正在尝试RDS，并且正在经历一些非常糟糕的性能。我无法找出瓶颈在哪里，并希望得到一些指导！

我们有一个简单的web应用程序，运行在位于丹麦的IIS服务器上。现在，我们的数据库也位于此IIS-服务器上。我们的web应用程序相当过时，所以在服务器使用文档进行响应之前，它会进行大约30个数据库查询，以生成初始的HTML文档。

与我们当前的数据库设置(位于prod-server上)文档加载时间如下：

localhost: 7 seconds
Dev-server: 0.9 seconds
Prod-server: 0.5 seconds 

(Dev和prod服务器位于同一个数据中心，而不是aws。所有这些都使用位于prod服务器上的数据库)

有一个带有sql的T2介质rds实例，加载时间如下所示：

localhost: 12.22 seconds
Dev-server: 24.76 seconds
Prod-server: 11.49 seconds

澄清了服务器配置，我们的生产数据库与应用程序一起运行在我们的生产服务器上。这是一个单一的执行一切的单一实例。我所有的第一次测试都使用了生产数据库。服务器和me/localhost位于丹麦，而RDS-实例位于法兰克福/DE。因此，对于RDS-测试，我在丹麦的服务器上运行应用程序逻辑，而在德国使用RDS-数据库。

RDS-实例在法兰克福。我发现这个数据中心对我们的点击时间是最小的。

我简要地尝试了制作一个M4大的RDS实例，以检查它是否仅仅是使用一个糟糕的规范实例的问题，但是我看到了完全相同的结果。

数据库并没有在任何方面都达到极限，似乎有足够的cpu学分，cpu在1-4%左右徘徊。我使用了来检查查询是否有问题(比如索引不能正确地处理有限的ram，或者只是缓慢的读取或其他什么)，但是每个查询都非常快--尽管它们相距很远。

我尝试过将存储类型从一般用途更改为供应，但没有发现任何更改。

有人能帮我找到瓶颈吗？或者这仅仅是由于网络延迟而引起的呢？我希望通过将数据库进一步远离应用程序，这会给网络带来损失，但不会太大。这个设置是可行的吗?或者，只有当IIS服务器位于相同的可用性区域时，它才能工作吗？

Answer 1

基于您的评论以及您最初的问题，我认为您的应用程序不能很好地在应用程序和数据库之间建立高延迟连接。DirectConnect可能是一个改进，但它始终是一个瓶颈。我强烈建议不要尝试运行带有远程数据库的生产应用程序，除非有很强的动机。在一个理想的世界Id建议你看看并行化，缓存和优化-但如果你坚持的东西，你只是需要托管，这是我会这样做。

CloudFront CDN，一个包含一些ec2实例的自动规模组，一个具有ec2证书的负载平衡器，以及一个多个az rds实例。所有的服务都是本地的，我怀疑您的应用程序会执行得更好。此配置将提供地理上分离的位置，运行IIS和SQL的副本以实现容错。基本的简况：

• CloudFront CDN.这就是你指出DNS的地方。使用IIS中的缓存头将静态资产缓存在边缘位置，加速后端IIS上的页面加载/减少加载。动态请求将通过CloudFront传递到负载平衡器，然后透明地送达客户端。
• 奥托斯卡尔集团。管理连接到负载平衡器的可用性区域之间的一组实例。提供基于触发器的/计划的实例数量，并可以重新生成不健康的实例。实例可以预先配置并保存为AMI，也可以在启动时通过UserData脚本动态配置。
• 负载平衡器(ALB)区域级负载平衡器将处理aws可用性区域的故障，将通信量路由到剩余的可达实例。您可以在负载平衡器上配置SSL卸载，因此实例<--> ALB通过HTTP进行通信，但是公众只能通过HTTPS与负载平衡器对话。您还可以在实例上设置自己的SSL，并让ALB通过HTTPS与后端实例对话，但它的工作更多。
• ACM证书(证书管理器)。它是一个基本的DNS验证SSL证书。您不能下载和使用它自己，它只有CloudFront和加载Balencers等-但它是免费的！如果将证书/中间证书/主密钥转换为正确的格式并附加到负载平衡器，则仍然可以上载它们。
• 多AZ RDS您得到一个区域/容错端点，AWS负责大部分细节。实际上，在不同的AZ中有两个服务器，其中一个活动实例将数据复制到一个单独的备用从实例。如果主程序不可用，奴隶就透明地接管。

就现场直播而言，有几件事要检查。请确保您的SSL证书涵盖站点名称(www.example.com)和裸/顶级域(example.com)，并确保IIS处理将流量重定向到适当的站点。另外，请确保您的DNS TTL已降至适当的小值，以允许合理的响应更改(如果存在重大问题，则回滚)。您需要允许当前的TTL在TTL的任何更改完全生效之前过期，所以提前计划(如果值非常高的话，可能会逐步更改TTL )。

Answer 2

当您移到云时，性能指标(响应)几乎没有变差。这似乎是明智的，因为移动到云可能需要多个网络跳(基于您的AZ或区域)完成假设，当它执行在同一个数据中心(原始DC)。然而，我仍然不相信这种不同。如果不了解AWS中的基础设施设置，就很难量化这种差异的原因。

现在回到你的问题上。据我说，你没有看到任何明显的性能差异，不是因为你原来的DC或什么时候搬到AWS。相反，它可能与应用程序本身有关。如果您的应用程序执行了30个同步IO (一步一步地执行)，那么您就必须在这里对代码进行微调。如果是这样的话，那么您就可以实现异步IO，并在返回客户端之前编写您的最终结果。这种方法(假设您可以并行化当前的逻辑)可以帮助您构建可组合的执行setp，从而减少总体响应时间。

请记住，拥有高端硬件并不一定能提高性能，除非您在如何最大限度地利用硬件方面对应用程序进行测试。