php - 与 AWS DynamoDB 通信时的整秒延迟

Question

我正在努力诊断我在系统性能日志中看到的一个奇怪症状，有时，写入 DynamoDB 需要几秒钟才能完成。

给出一些基础设施的背景:

• 这是一个托管在 AWS(东部地区)的网络应用
• 一个包含两个 EC2 实例的 ELB (c3.2xlarge)
• 为每秒 1000 次读/写

我有一个在 EC2 实例上运行的 PHP Web 服务，它从连接用户接收一个小请求，将记录写入 dynamo，然后返回空响应。传输的数据量远低于 1kb。 ELB 的流量全天都在变化，但从每秒几个请求到超过 100 个请求不等。这里需要注意的是，我直接为我需要的发电机操作编写了一个小型 CURL 客户端，因为 AWS SDK 引入了 70 毫秒我们的处理时间之上的开销。

我使用的唯一选项是:

CURLOPT_POST
CURLOPT_RETURNTRANSFER
CURLOPT_TCP_NODELAY

关于我看到的行为:对于 99% 的情况，ELB 记录的响应时间都在 30 毫秒以下，这是我们的目标。但是，如果我更改图表以显示同一范围内的最大值，我会看到截然不同的图片 ( graph )，时间间隔接近整秒。该图与负载无关，因为它甚至发生在交通流量最小的半夜。这些趋势促使我进行更深入的挖掘，并且能够将延迟与 DynamoDB 的连接隔离开来。

这些看起来像是程序化的阈值，而不是一般的噪音。我的第一个想法是它是指数退避，但我没有在 dynamo web 服务的响应中看到任何暗示这一点的迹象(所有 200 个)，我们现在的吞吐量是我们配置的 10%，即使在峰值时也是如此.再一次，即使在交通流量最小的半夜，我们也能看到这种性能趋势。如果它不是后退，那么它肯定感觉像是某种节流。想法？

对我的 Dynamo API 调用使用 CURL 的详细输出，我看到如下条目:

Line 151190: 2014-03-12T16:48:35-04:00 - INFO - Time: 1.001436, (Start Transfer: 1.001416, DNS: 2.6E-5, Connect: 0.998141, Pre-Transfer: 0.998199)

Line 196871: 2014-03-12T16:48:42-04:00 - INFO - Time: 1.001528, (Start Transfer: 1.001488, DNS: 3.1E-5, Connect: 0.99694,  Pre-Transfer: 0.996981)

Line 430508: 2014-03-12T16:49:19-04:00 - INFO - Time: 1.002823, (Start Transfer: 1.002807, DNS: 3.2E-5, Connect: 0.998972, Pre-Transfer: 0.999009)

Line 870236: 2014-03-12T16:50:31-04:00 - INFO - Time: 1.000663, (Start Transfer: 1.000642, DNS: 3.0E-5, Connect: 0.001506, Pre-Transfer: 0.001537)

Line 950109: 2014-03-12T16:50:43-04:00 - INFO - Time: 1.010762, (Start Transfer: 1.010737, DNS: 3.3E-5, Connect: 0.001357, Pre-Transfer: 0.001394)

这里的关键发现是，似乎在 50% 的情况下是连接时间，而对于另外 50%，不清楚时间花在了哪里。似乎这里还有另一个组件可能会影响端到端时间，但我正在努力查明它可能是什么。

如有任何帮助，我们将不胜感激!

Answer 1

确保您不发送 Expect: 100-continue header ，这是造成像这样约 1 秒延迟的常见原因。我相信 cURL 默认发送此 header ，因此您需要执行一些操作以将其删除。

如果您最终使用适用于 PHP 的 AWS 开发工具包，请确保您还使用了操作码缓存，例如 APC 或 Zend Opcache。