连接许多设备时如何改善套接字的挂起状态？

时间：2018-12-17 15:36:12

标签： fiware fiware-orion

  • 我正在测试在以下环境中将许多设备连接到FIWARE。

  • 每个组件都部署在物理服务器上的容器中。

    +-------------------------------------------------+
|Comet - Cygnus - Orion - IoTAgentJSON - Mosquitto| - device*N
+-------------------------------------------------+

  • 在每台设备以1 msg / sec传输数据的情况下，当设备数量为350（即350 msg / sec）时，在IoTAgent上发生以下错误

    {"log":"time=2018-12-16T14:57:24.810Z | lvl=ERROR | corr=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | trans=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | op=IoTAgentNGSI.NGSIService | srv=n/a | subsrv=n/a | msg=Error found executing update action in Context Broker: Error: socket hang up | comp=IoTAgent\n","stream":"stdout","time":"2018-12-16T14:57:24.81037597Z"}
{"log":"time=2018-12-16T14:57:24.810Z | lvl=ERROR | corr=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | trans=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | op=IoTAgentNGSI.Alarms | srv=n/a | subsrv=n/a | msg=Raising [ORION-ALARM]: {\"code\":\"ECONNRESET\"} | comp=IoTAgent\n","stream":"stdout","time":"2018-12-16T14:57:24.810440213Z"}
{"log":"time=2018-12-16T14:57:24.810Z | lvl=ERROR | corr=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | trans=ec11c37f-5194-4cb3-8d79-e04a2d1e745c | op=IoTAgentJSON.MQTTBinding | srv=n/a | subsrv=n/a | msg=MEASURES-002: Couldn't send the updated values to the Context Broker due to an error: Error: socket hang up | comp=IoTAgent\n","stream":"stdout","time":"2018-12-16T14:57:24.810526916Z"}

  • 请求的ps ax | grep contextBroker命令的结果如下。

    ps ax | grep contextBroker
19766 ?        Ssl   29:02 /usr/bin/contextBroker -fg -multiservice -ngsiv1Autocast -dbhost mongodb-orion-demo -statCounters -statSemWait -statTiming

问题1：原因在哪里？ IoTAgent？还是猎户座？还是MongoDB？还是内核参数？

  • Error found executing update action in Context Broker: Error: socket hang up，但在Orion中没有显示错误日志。

问题2：如何提高FIWARE的处理性能？

问题3：IoT代理上是否有批处理操作？

1 个答案:

答案 0 :(得分：0)

很难提供正确的答案，因为性能取决于许多因素，特别是在涉及多个组件交互的复杂设置中。但是，我将根据您提供的信息和我以前的经验尝试提供一些想法和见解。

关于Orion，我建议您看看documentation on performance tunning。按照该页面上的指示，您可以提高组件的性能。

但是，话虽如此，我认为基于您的情况，Orion并不是问题的根源

  • 即使没有性能优化，Orion通常也能达到约1,000 tps的吞吐量。它应该能够以350 tps的速度处理更新，而不会出现问题。
  • Orion没有显示错误日志。据我了解，您的错误日志是由IOTAgent组件生成的。

因此，专注于IOTA，也许最好使用IOTA-UL而不是IOTA-JSON。 UL编码比JSON编码更有效，因此您可以提高效率。此外，IOTA-UL允许您发送多重测量（使用#作为分隔符），我不知道它是否适合您的情况，但可以看作是批量更新的一种有限形式（请参见UL documentation详情）。

如果这样不起作用，则另一种可能性是使用其NGSIv2 API将数据直接发送到Orion。那将有几个优点：

  • 简化的设置（少了两块：MQTT代理和IOTAgent）
  • 在相同的资源条件下，Orion的本机性能通常高于IOTAgents的性能（正如我之前提到的〜1,000 tps或在应用性能优化后甚至更高）
  • NGSIv2 API提供了批处理更新操作（请在上面引用的NGSIv2规范文档中查找POST /v2/op/update）
相关问题
最新问题