sitewhere
sitewhere copied to clipboard
sitewhere
Performance
How many concurrences can the device have at the acquisition frequency of 1 second in Version 2.X？Does having only one MQTT Broker have an impact on performance?
The number of concurrent devices supported depends on many factors. For instance, if there are scripts which do expensive processing in the event processing pipeline, they can lower the max number supported significantly.
If the MQTT broker becomes a bottleneck, you can add multiple MQTT brokers and configure the tenant event sources such that the load is spread across the brokers. Additionally, if there are bottlenecks in other parts of the event pipeline, you can increase the number of replicas of the given microservice to better handle the load.
Now we have improved some functions of version 2.x. During the trial run, we may encounter problems with Zoopkeeper connecting. Do you have any Suggestions on system deployment?
We moved to a different Kafka/Zookeeper Helm chart for SiteWhere 3.0 due to issues with the charts used in 2.x. We now use https://strimzi.io/ which has a great implementation. Unfortunately, SiteWhere 2.x uses Zookeeper directly for storing configuration and that pattern is not supported out-of-the-box in Strimzi due to concerns over the Zookeeper data becoming corrupted. There are workarounds such as this (https://github.com/strimzi/strimzi-kafka-operator/issues/1337), but we have not had time to back-port those to 2.x.
If possible, could you please solve this problem in the 2.x version first? After all, the 3.0 version is not available yet. Should we have a stable and reliable version before upgrading?Thank you very much!