On me pose souvent une question du genre "Je suis sur la version X et j'envisage de passer à la version Y ? La nouvelle version est-elle plus rapide ? Dans quelle mesure ? Peut-être prévoyez-vous une mise à niveau matérielle et avez-vous des questions similaires.
Je comprends votre intérêt. Mais voici mon problème. Bien que nous effectuions des benchmarks internes lorsque nous préparons une nouvelle version d'OpenVOS, nos benchmarks reflètent simplement la façon dont le système exécute le benchmark ! Dans la mesure où l'activité d'un benchmark reflète votre application, vous pouvez vous attendre à des résultats quelque peu similaires. Mais nous avons de nombreux clients OpenVOS, et ils exécutent de nombreuses applications différentes. Nous pouvons donc faire quelques déclarations générales sur ce à quoi vous pouvez vous attendre, mais nous devons toujours les formuler dans un langage prudent. Même si nous constatons une amélioration de 20 % des performances par rapport à notre référence, vos résultats seront probablement inférieurs, mais pourraient être meilleurs. Il s'ensuit que notre estimation n'est souvent pas très utile.
Il ne fait aucun doute que la compréhension des caractéristiques de performance d'une application est une étape importante dans la qualification de cette application sur une nouvelle version du système d'exploitation, ou sur une plate-forme matérielle plus récente. La plupart des clients d'OpenVOS font tourner des applications critiques sur leurs systèmes ; la dernière chose dont vous avez besoin est de faire une mise à jour et de voir une sorte de surprise.
J'aimerais donc proposer une approche différente. Au lieu de me demander des déclarations générales sur les performances d'une nouvelle version, j'aimerais vous suggérer de préparer un sous-ensemble de votre application - peut-être les parties les plus sensibles aux performances - à exécuter dans un environnement contrôlé et simulé. Composez des données fictives qui conservent l'étendue et la profondeur des données réelles. Si vous traitez des transactions pour 3 millions de clients dans le monde réel, alors remplissez 3 millions de clients simulés dans votre environnement de test. Si vous gérez 1 000 magasins dans le monde réel, remplissez 1 000 magasins à des fins de test. La raison pour laquelle vous devez prendre cette mesure est simple : vous voulez que la mémoire et l'empreinte de stockage de l'environnement de test reproduisent avec précision ce qui se passe en production.
Vous pouvez utiliser cet environnement de test pour établir les performances de base de votre installation actuelle, puis, lorsqu'il est temps de passer à une nouvelle version d'OpenVOS ou à une nouvelle plate-forme matérielle, vous pouvez utiliser votre propre environnement de test comme référence. Si vous souhaitez connaître les avantages d'une mise à niveau matérielle avant d'acheter le matériel, contactez-nous. Nous disposons d'un laboratoire de référence où vous pouvez venir effectuer vos tests sur n'importe lequel de nos produits actuels. Souvent, vous n'avez même pas besoin de vous déplacer ; nous pouvons mettre le matériel à disposition sur Internet.
Une fois que vous disposez d'un environnement de test logiciel réaliste et reproductible, vous pouvez facilement répondre à plusieurs questions vraiment cruciales : où se situe le haut de gamme des performances de mon application ? Combien de transactions puis-je effectuer dans ce système ? Quels sont les goulets d'étranglement que je rencontre lorsque j'essaie de faire cela ? D'après mon expérience, il y a toujours des goulets d'étranglement. Il vaut mieux trouver les goulets d'étranglement sur le système de test que dans la production.
Stratus Les services professionnels ont une grande expérience dans l'aide aux clients pour mesurer et optimiser les performances de leurs applications sur nos produits. Si vous avez besoin d'un peu d'aide pour cet exercice, veuillez téléphoner à votre responsable de compte.
Entreprise