0


0

Sur les profils NServiceBus

J’ai essayé de trouver des moyens d’améliorer nos performances de code nservicebus. J’ai cherché et suis tombé sur ces profils que vous pouvez définir lors de l’exécution / de l’installation de l’hôte nservicebus.

Actuellement, nous exécutons l’hôte nservicebus tel quel, et j’ai lu que par défaut, nous utilisons la version "Lite" des profils disponibles. J’ai également appris de ce lien:

qu’il existe des profils intégrés et de production. La documentation ne dit pas grand-chose - quelqu’un a-t-il essayé les profils de production et remarqué une amélioration des performances de nservicebus? Affectant spécifiquement la vitesse de consommation des messages des files d’attente?

2 Answer


0


Une différence majeure entre les profils NSB est la façon dont ils gèrent le stockage des abonnements.

Les profils allégés, d’intégration et de production permettent à NSB de configurer sa fiabilité. Par exemple, le profil lite utilise le stockage d’abonnement en mémoire pour toutes les inscriptions pub / sub. Ceci est un problème car pour enregistrer un abonné dans le profil Lite, l’éditeur doit déjà être en cours d’exécution (afin que l’éditeur puisse stocker la liste des abonnés en mémoire). Cela signifie que si l’éditeur tombe en panne pour une raison quelconque (ou est mis hors ligne), toutes les informations d’abonnement sont perdues (jusqu’au redémarrage de chaque abonné).

Ainsi, le profil allégé est bon si vous exécutez sur une machine de développeur et que vous souhaitez tester rapidement comment vos services interagissent. Cependant, il n’est tout simplement pas adapté à d’autres environnements.

Le profil d’intégration stocke les informations d’abonnement dans une file d’attente locale. Cela peut être bon pour les environnements simples (comme l’AQ, etc.). Cependant, dans un environnement hautement distribué, il est préférable de conserver les informations d’abonnement dans une base de données, d’où le profil de production.

Donc, pour répondre à votre question, je ne pense pas qu’en changeant de profil vous verrez un gain de performance. Si quoi que ce soit, le passage du profil allégé à l’un des autres profils est susceptible de réduire les performances (car vous encourez le coût d’accès au stockage de la file d’attente ou de la base de données).


0


À moins que vous n’ayez réglé vous-même la journalisation, nous avons constaté de grandes améliorations basées sur une journalisation réduite. Les performances de lecture des files d’attente sont identiques. Comme les files d’attente sont locales, vous ne gagnerez pas beaucoup du transport. Je voudrais jeter un œil à l’optimisation de vos gestionnaires et de l’infrastructure sous-jacente. Vous voudrez peut-être vérifier le réglage de MSMQ et regarder le disque que vous utilisez, etc. Un autre point serait d’examiner le fonctionnement des transactions distribuées en supposant que vous utilisez une base de données distante qui en a besoin.

Une autre option pour augmenter le temps de traitement consiste à augmenter le nombre de threads consommant la file d’attente. Cela nécessitera une licence. Si une licence n’est pas une option, vous pouvez avoir plusieurs instances d’un seul point de terminaison threadé en cours d’exécution. Cela nécessite que vous partagiez votre travail en fonction du type de message ou d’autre chose.

En continuant à l’échelle, vous pouvez ensuite utiliser le distributeur pour équilibrer la charge de travail. Encore une fois, cela nécessitera une licence, mais vous pourrez ajouter plus de nœuds si nécessaire. Toutes les opportunités ci-dessus s’appliquent également à cette topologie.