Question

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

提供基础设施的一些背景知识：

这是在AWS（东部地区）
涵盖两个EC2实例的ELB（c3.2xlarge）
为其配置的单个DynamoDB表每秒1000次读/写

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

我使用的唯一选项是：

CURLOPT_POST
CURLOPT_RETURNTRANSFER
CURLOPT_TCP_NODELAY

关于我所看到的行为：对于99％的情况，ELB记录的响应时间低于30ms，这是我们的目标。但是，如果我更改图表以显示相同范围内的最大值，我会看到一个非常不同的图片（graph），其中时间会落入接近整个第二个间隔。此图表与负载无关，因为它甚至在交通最少的半夜也会发生。这些趋势促使我深入挖掘，我能够将延迟与DynamoDB的连接隔离开来。

这些似乎是程序化阈值，而不是一般噪音。我的第一个想法是它是指数退避，但我没有看到发电机网络服务的响应中的一个迹象表明这个（全部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标题，这是导致这样的〜1秒延迟的常见原因。我相信cURL默认发送此标头，因此您需要做一些事情来删除它。

如果您最终使用AWS SDK for PHP，请确保您还使用了像APC或Zend Opcache这样的操作码缓存。

与AWS DynamoDB通信时的全秒延迟

1 个答案: