J'essaie de régler les performances de ma suite de tests d'acceptation. J'ai découvert que la plus grande partie du goulot d'étranglement des performances est due aux fichiers de stockage MSMQ se trouvant sur un disque VM d'E/S lent. J'ai essayé de déplacer le dossier Stockage MSMQ vers un DISQUE RAM, mais pour une raison étrange, MSMQ génère une erreur de périphérique d'E/S lorsque vous essayez de créer une file d'attente privée à l'aide de "Gestion de l'ordinateur" sur Windows Server 2012 R2. Cela fonctionne très bien dans Windows 7, 8 et 10. Donc, je ne sais vraiment pas quel est le problème avec RAM DISKS, MSMQ et Windows 2012 R2. Comme alternative, je pensais plutôt que de stocker mes fichiers MSMQ sur un disque rapide ou même un disque RAM, pourquoi ne pas simplement créer une nouvelle instance de composant MSMQ en mémoire, puis avoir toutes mes files d'attente en mémoire .Instance MSMQ en mémoire
Notez que ce code ne sera utilisé que pour améliorer les performances de ma suite de tests nunit d'acceptation. ATM, il faut 2,5 heures pour terminer (4000 tests, en utilisant NServiceBUS, MSMQ et RavenDB). J'ai réussi à déplacer tous les composants vers RAMDISK, ce qui a réduit le temps d'exécution de près de 40%. C'est quand je le tester sur Windows 7,8,10 en utilisant MSMQ sur le RAMDISK. En faisant de même dans Windows 2012 R2, je peux tout déplacer sur le disque RAM et ça marche bien, mais je ne peux pas obtenir MSMQ pour fonctionner sur le RAMDISK. Et étrangement, j'ai perdu tous les gains de performance quand MSMQ n'est pas sur le RAMDISK. Je suppose que le goulot d'étranglement de l'E/S est vraiment mauvais!
Un conseil?
Achetez un SSD! Qu'est-ce que tu attends? ;) –
Les files d'attente MSMQ sont * NOT * persistantes par défaut. L'option par défaut est le stockage de la mémoire. Vous devez explicitement les rendre persistants lorsque vous les créez. Ne pas –
@ MatíasFidemraizer: Ce n'est pas si facile. Je travaille pour une grande entreprise, nous utilisons des instances de serveur AWS pour héberger nos environnements. Team City est hébergé sur une machine virtuelle AWS et, comme mentionné précédemment, la suite de tests dure 2,5 heures. Les disques sur cette VM lisent/écrivent à 150MB/s, avec un disque RAM sur ce serveur, je reçois 5000MB/s – FaNIX