在我们的物联网解决方案中，利用服务器端的Azure IoT Hub和设备端的Azure IoT Client SDK，我们看到设备通过MQTT发送状态消息和IoT Hub收到消息之间的间歇性延迟 .
在某些情况下，我们看到IoT Hub将消息排队62秒 .
例如，下面的消息ID：5cfbe0ac-d987-3317-bda6-f63ec5fe562a
T1-T0 = 62秒
设备时间戳（T0）= 2017-12-13T12：31：12
物联网中心时间戳（T1）= 2017-12-13T12：32：14.3600000Z
Question:
-
消息到达IoT Hub的延迟原因是什么？
-
我们如何进一步挖掘（在内部组件中添加日志以确定延迟的确切位置）？
-
有什么建议吗？
示例物联网中心排队消息：{
"data"：{
"attributes"：[
{
"code"："STS"，"value"："1"，}]，"type"："status"}，"messageid"："5cfbe0ac-d987-3317-bda6-f63ec5fe562a"，"protocol"："MQTT"，“ DeviceTimestamp ":" 1513168272 ", " EventProcessedUtcTime ":" 2017-12-13T12：32：14.0683721Z ", "的partitionid ":5, " EventEnqueuedUtcTime ":" 2017-12- 13T12：32：14.3010000Z ", " IoTHub“：{
"MessageId"：null，"CorrelationId"：null，“ EnqueuedTime ":" 2017-12-13T12：32：14.3600000Z ", " StreamId”：null}}
更新：设备正在使用Azure客户端SDK版本1.1.27 . 设备代码使用C语言编写 . 该设备不在防火墙后面或使用任何特殊的网络拓扑，它通过MQTT连接到IoT Hub . 通过MQTT发送状态消息时会观察到延迟 .
更新2：设备在使用Azure客户端SDK方法发送消息之前将时间戳添加到消息中 . 在大多数情况下，时间戳匹配，除非我们看到尖峰，例如以上信息 . 它使用NTP时间服务器计算时间戳并作为EPOCH发送 . 物联网中心位于更高层（10个单位） .
根据我们今天的分析，我们怀疑Azure客户端SDK . 我们的假设是，我们认为SDK在尝试与IoT Hub Build 连接时在内部（在列表或队列中）存储消息 . 如果它没有连接到IoT Hub，它会在几秒钟后重试 . 当它恢复连接时，它传递存储在其队列中的消息（再次当消息被延迟时，我们看到一堆消息以相同的延迟聚集在一起，这证明了这个假设） .