sql-server - 将数据库和 Web 服务器分开时，RDS 性能真的很差吗？

Question

我们目前正在试用 RDS，并且遇到了一些非常糟糕的性能。我无法弄清楚瓶颈在哪里，希望得到一些指导!

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

---

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

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

(Dev 和 prod 服务器在同一个数据中心 - 不是 aws。都使用位于 prod 服务器上的数据库)

使用带有 sql express 的 T2 Medium rds 实例，加载时间如下:

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

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

---

RDS 实例位于法兰克福。我发现这个数据中心的 ping 时间对我们来说是最短的。

我曾短暂地尝试制作一个 M4 大型 RDS 实例来检查它是否只是使用规范不佳的实例的问题，但我看到了完全相同的结果。

数据库在任何方面都没有达到极限，似乎有足够的 cpu 积分并且 cpu 徘徊在 1-4% 左右。 我已经使用 SQL Server Profiler 来检查查询是否存在问题(可能是索引在有限的 ram 下无法正常工作或只是读取速度慢或其他问题)但每个单独的查询都非常快 - 尽管它们非常相距甚远。

我已尝试将存储类型从通用更改为预配置，但没有发现任何变化。

有人可以帮我找到瓶颈吗？或者这只是由于网络延迟而预期的？我期望将数据库从应用程序移到更远的地方会造成网络损失，但没有那么多。此设置是否可行 - 或者仅当我们在同一可用区中拥有 IIS 服务器时它才有效？

Answer 1

根据您的意见和您最初的问题，我认为您的应用程序不适合应用程序和数据库之间的高延迟连接。 DirectConnect 可能是一种改进，但它始终是一个瓶颈。我强烈建议不要尝试使用远程数据库运行生产应用程序，除非有非常强烈的动机这样做。在理想情况下，我建议您考虑并行化、缓存和优化 - 但如果您坚持只需要托管的东西，我会这样做。

CloudFront CDN，一个带有一些 ec2 实例的自动缩放组，一个带有 ACM 证书的负载均衡器，以及一个多 az rds 实例。所有服务都将彼此本地化，我怀疑您的应用程序会执行得更好。此配置将提供地理上独立的位置来运行 IIS 和 SQL 的副本以实现容错。基本概要:

• CloudFront CDN。这是您指向 DNS 的地方。使用 IIS 中的缓存 header 将静态 Assets 缓存在边缘位置，以加速页面加载/减少后端 IIS 上的负载。动态请求将通过 CloudFront 传递到负载均衡器，然后透明地返回给客户端。
• Autoscale 集团。管理在连接到负载均衡器的可用性区域之间拆分的实例集。提供基于触发器/计划的实例扩展数量，并可以重生不健康的实例。实例可以预先配置并保存为 AMI，或者可以在启动时通过 UserData 脚本动态配置。
• 负载平衡器 (ALB)。区域级负载均衡器将处理 aws 可用性区域将流量路由到剩余可访问实例的故障。您可以在负载均衡器上配置 SSL 卸载，因此实例 <--> ALB 通过 HTTP 进行通信，但公众仅通过 HTTPS 与负载均衡器通信。您还可以在实例上设置您自己的 SSL，并让 ALB 也通过 HTTPS 与后端实例对话，但它的工作量更大。
• ACM 证书(证书管理器)。它是一个基本的 DNS 验证 SSL 证书。您不能自己下载并使用它，它仅适用于 CloudFront 和 Load Balencers 等 - 但它是免费的!如果您自己的证书/中间证书/主 key 已转换为正确的格式并附加到负载均衡器，您仍然可以上传它们。
• 多可用区 RDS。您将获得一个区域/容错端点，而 AWS 会处理大部分细节。实际上，您在不同的 AZ 中有 2 个服务器，其中一个事件实例将数据复制到一个单独的备用从属实例。如果主站不可用，则从站透明地接管。

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