La chaine de valeur d’un projet LoRaWAN est vaste, et les sources de limitations ou de goulots d’étranglements sont nombreux et variés. Nos clients nous demandent régulièrement les limites physiques de nos solutions: combien de capteurs notre système peut supporter ? Combien de messages peuvent transiter par une instance ?

Pour aujourd’hui, nous allons seulement nous concentrer sur les performances de Chirpstack, que nous utilisons dans certains de nos produits.

Chirpstack, selon son site web, “est un serveur de gestion de réseaux LoRaWAN, qui peut être utilisé pour déployer des réseaux LoRaWAN”

Chez Wi6labs, nous l’utilisons déjà pour l’une de nos solutions: µWiotys, donc naturellement nous sommes curieux des performances.

Pour qualifier celles-ci, nous avons mis Chirpstack dans des situations quasi-réelles afin de voir comment il allait réagir sous pression (voir Résultats).

Merci de noter que les résultats seront dépendants de la machine utilisée, de la version logicielle, etc… Il faut donc les prendre comme une indication.

Le créateur de Chirpstack propose un simulateur afin de créer et d’envoyer des trames LoRaWAN vers une instance Chirpstack. Bien que cela soit super pratique ( et on écrira surement un post sur son fonctionnement ), dans notre cas cela complique nos analyses:

• Le simulateur génère des capteurs et des gateways aléatoirement à chaque lancement

• Chaque capteur doit compléter une procédure de Join avant d’envoyer un Uplink ( et donc avant de générer de nouvelles clés de sessions ).

Pour éviter le côté aléatoire, à la place d’utiliser le simulateur, nous avons décidé de créer une migration Postgres. Cela nous permet d’avoir un jeu de données statique.

Par expérience, nous savons que la procédure de Join n’est généralement pas un cas d’usage compliqué à gérer par le LNS, en effet cela représente une partie mineure du traffic réseau. Dans la vie d’un capteur, les procédures de Join sont faites beaucoup moins de fois que des Uplinks ( sauf pour certains capteurs vraiment étranges ou mal configurés ).

Donc nos tests vont seulement se concentrer sur envoyer des Uplinks et voir combien Chirpstack peut en traiter avant que cela plante.

Grâce à notre migration, nous avons “seulement” à envoyer des Uplinks en simulant ce qu’une passerelle enverrait à Chirpstack sur le port 1700 ( plus d’informations dans les prochaines parties ).

Finalement, pour rendre nos tests un peu plus réalistes, nous avons enregistré de nombreux capteurs (300 000) et de nombreuses passerelles (2 000) sur notre instance de Chirpstack pour voir si cela impacterait le système d’une manière ou d’une autre.

En utilisant le Protocole de Semtech, nous pouvons envoyer des données directement à Chirpstack. Pour cela, nous allons utiliser l’outil linux: netcat avec les options afin de ne pas attendre et pour envoyer les données vers notre instance Chirpstack sur le port 1700.

La commande ressemble à nc -w 0 -u chirpstack 1700

Afin de stresser notre instance, nous envoyons des trames à Chirpstack en utilisant un script bash qui prend une liste de trames et de passerelles et les envoi le plus rapidement possible.

Notre instance Chirpstack est configurée pour envoyer des Uplinks vers un Webhook local (voir Plateforme de test utilisée), cela nous permet d’extraire le temps de traitement et d’envoi des Uplinks.

Tous nos tests on été réalisés sur un contenaire Proxmox :

• 16 GiB RAM

• 128 Gb Disk

• 8 Processeurs

• Rocky linux 9.4-x86_64

Et utilisant:

• Docker 28.5.1

• Chirpstack 4.16.2

  • La version docker sans modification

• Webhook

  • En utilisant le docker-compose.yaml disponible et avec une modification afin de pouvoir recevoir plus de 500 messages

Nos tests et leurs résultats sont listés dans le tableau suivant:

Comme vous pouvez le noter, nous avons perdu quelques Uplinks entre ce que nous avons envoyé et ce qui a été reçu, cela est normal et cela est dû à la façon dont nous utilisons netcat.

Il est aussi intéressant de voir que le nombre de passerelles n’a pas d’importance.

A la fin, nous obtenons entre 147 et 258 Uplinks par secondes. Cela veut dire que l’on peut théoriquement avoir environ 13 à 22 Millions d’Uplinks traités par jour.

Il est toutefois important de noter que:

• A cause de la façon dont nous envoyons les Uplinks, cela pourrait cacher des problèmes ou fausser les performances obtenables lors de l’utilisation de vraies passerelles

• Nous envoyons seulement des vagues de messages, les performances peuvent donc être réduites en cas de charge constante

• Nous observons une petite diminution de performances quand le nombre de message augmente

• Nous n’appliquons actuellement aucun décodage, leurs utilisations pourraient diminuer les performances

Nous avons aussi essayé de trouver les limites avant lesquelles notre instance prendrait plus de temps pour traiter les Uplinks. Nous avons décidé de manière arbitraire de mettre un seuil à 15s de retard.

Toutefois, dû fait que les limites ne sont pas si claires que cela et que nous ne sommes pas 100% sûr que Chirpstack prend vraiment plus de temps, nous avons choisi de ne pas mettre ces résultats dans le tableau ci-dessus. Il faut donc prendre le résultat qui suit comme une indication.

Il semblerait que, nous ayons une limite au dela de 260 messages par secondes, lorsqu’ils sont envoyés lors de plus de quelques minutes (3 min). Dans ce cas là, nous observons que le dernier Uplink serait envoyé avec quelques secondes (~ 30s) de retard sur notre Webhook.

Chirpstack est bien plus capable que nous le pensions initialement. Et en se basant sur nos résultats, on peut espérer avoir de meilleures performances en utilisant un ordinateur plus puissant.

En voyant ces résultats, nous lancerons sûrement ce genre de tests sur notre solution µWiotys afin de voir où se trouverait ces limites.

Nous voulions remercier les super projets listés ci-dessous que nous avons utilisés durant nos tests:

• https://proxmox.com/en/

• https://github.com/chirpstack/chirpstack

• https://github.com/brocaar/chirpstack-simulator

• https://github.com/webhooksite/webhook.site

• https://github.com/Lora-net/packet_forwarder

• https://netcat.sourceforge.net/