Trouvez et corrigez 15 goulots d'étranglement des performances

«Goulot d'étranglement» est un terme merveilleusement descriptif. Il décrit une contrainte artificielle sur une forme de communication, d'interaction ou de transfert d'informations. Et cela porte à croire qu'une combinaison magique de chance, d'argent et d'ingéniosité peut briser ce goulot d'étranglement et laisser couler toutes les bonnes choses.

Le problème avec les goulots d'étranglement des performances est qu'ils peuvent être difficiles à identifier. Est-ce le CPU? Le réseau? Un morceau de code maladroit? Souvent, le coupable le plus évident est en fait en aval de quelque chose de plus grand et de plus mystifiant. Et lorsque les énigmes de performance ne sont pas résolues, la direction informatique peut se trouver confrontée au choix d'un Hobson entre admettre son ignorance et inventer des excuses.

Heureusement, comme pour les diagnostics médicaux ou le travail de détective, l'expérience aide. Forts de nos années de recherche et d'expérimentation, nous avons rassemblé 15 des affections les plus probables - et suggéré des remèdes - pour aider vos opérations informatiques à détecter et à résoudre les problèmes de performances.

Certains de ces goulots d'étranglement sont plus évidents que d'autres. Très probablement, vous avez quelque chose à dire sur vos propres spoilers sournois (et nous serions ravis d'entendre vos histoires à leur sujet). Mais en identifiant les tueurs de vitesse courants dans toutes les disciplines informatiques, nous espérons relancer votre quête pour créer l'infrastructure la plus performante que vos ressources permettront.

N ° 1: Ce ne sont probablement pas les serveurs

Les mises à niveau des serveurs faisaient toute la différence, c'est pourquoi la vieille scie «Quand tout le reste échoue, lancez plus de matériel» persiste aujourd'hui. C'est encore vrai dans certains cas. Mais quelle part de l'informatique est vraiment si gourmande en calcul? En règle générale, vous pouvez économiser beaucoup de temps et d'argent en détournant votre globe oculaire poilu du matériel serveur. La partie inférieure du spectre des serveurs a une puissance plus que suffisante pour gérer les tâches quotidiennes.

Voici un exemple concret. Sur un réseau de plus de 125 utilisateurs, un contrôleur de domaine Windows âgé semblait être prêt à être remplacé. Ce serveur exécutait à l'origine Windows 2000 Server et a été mis à niveau vers Windows Server 2003 il y a quelque temps, mais le matériel est resté inchangé. Ce HP ML330 avec un processeur 1Ghz et 128 Mo de RAM fonctionnait comme un contrôleur de domaine Active Directory portant tous les rôles AD FSMO, exécutant les services DHCP et DNS ainsi qu'exécutant IAS (Internet Authentication Services).

De la mélasse, non? En fait, il a très bien fait le travail. Son remplacement était un HP DL360 G4 avec un processeur 3Ghz, 1 Go de RAM et des disques SCSI de 72 Go en miroir. Avec tous ces services, il ne fonctionne pratiquement pas du tout - et la différence de performances est imperceptible.

Il est facile d'identifier les applications qui consommeront tout votre processeur et votre mémoire, mais elles ont tendance à être assez spécialisées. Pour presque tout le reste, l'humble boîte de produits fera l'affaire.

N ° 2: Accélérez ces requêtes

Vous pouvez créer l'application la plus astucieuse au monde, mais si l'accès aux serveurs de base de données principaux crée un goulot d'étranglement, vos utilisateurs finaux ou vos clients ne seront pas satisfaits. Affinez donc ces requêtes de base de données et optimisez les performances.

Trois mesures de base peuvent vous aider à améliorer les performances des requêtes. Premièrement, la plupart des produits de base de données incluent des outils (tels que DB2 UDB pour Visual Explain d'iSeries) qui peuvent disséquer votre requête pendant le développement, en fournissant des commentaires sur la syntaxe et la synchronisation approximative des différentes sections des instructions SQL. À l'aide de ces informations, recherchez les parties les plus longues de la requête et décomposez-les davantage pour voir comment vous pourriez raccourcir le temps d'exécution. Certains produits de base de données incluent également des outils de conseil en matière de performances, comme le moniteur de diagnostic automatique de base de données d'Oracle, qui fournissent des recommandations (telles que la suggestion de créer un nouvel index) pour accélérer les requêtes.

Ensuite, activez les outils de surveillance de base de données sur un serveur intermédiaire. Vous pouvez utiliser un produit de surveillance tiers, tel que NetVigil de Fidelia, si votre base de données ne prend pas en charge la surveillance. Avec les moniteurs activés, générez du trafic sur le serveur de base de données à l'aide de scripts de test de charge. Examinez les données recueillies pour voir comment vos requêtes se sont déroulées sous charge; ces informations peuvent vous conduire à d'autres ajustements de requête.

Si vous disposez de suffisamment de ressources serveur pour imiter assez fidèlement votre environnement de production de charges de travail mixtes, vous pouvez exécuter un troisième cycle de réglage des requêtes à l'aide d'un outil de test de charge, tel qu'OpenSTA, ainsi que la surveillance de la base de données pour voir comment vos requêtes fonctionnent avec d'autres applications base de données.

À mesure que les conditions de la base de données changent - avec la croissance du volume, les suppressions d'enregistrements, etc. - continuez à tester et à régler. Cela en vaut souvent la peine.

N ° 3: Quel coût, protection antivirus?

La protection antivirus sur les serveurs critiques est une exigence de base, en particulier pour les serveurs Windows. L'impact peut cependant être douloureux. Certains antivirus sont plus intrusifs que d'autres et peuvent réduire considérablement les performances du serveur.

Essayez d'exécuter des tests de performances avec et sans votre antivirus en cours d'exécution pour déterminer l'impact. Si vous constatez une nette amélioration sans le scanner, il est temps de chercher un autre fournisseur. Vérifiez également les caractéristiques spécifiques. Désactivez les analyses en temps réel et vous améliorerez souvent les performances.

Quelle que soit la qualité de l'écriture de votre logique métier, lorsque vous la déployez vers le niveau intermédiaire, vous devrez régler l'environnement d'exécution du serveur d'applications pour maximiser les performances.

Comme une chaîne stéréo vintage avec une multitude de boutons pour peaufiner la qualité du son, les serveurs d'applications de fournisseurs tels que BEA, IBM et Oracle, fournissent un ensemble étourdissant de commandes. L'astuce consiste à tourner les boutons dans le bon sens, en fonction des attributs de votre application.

N ° 4: Maximiser le niveau intermédiaire

Quelle que soit la qualité de l'écriture de votre logique métier, lorsque vous la déployez vers le niveau intermédiaire, vous devrez régler l'environnement d'exécution du serveur d'applications pour maximiser les performances.

Comme une chaîne stéréo vintage avec une multitude de boutons pour peaufiner la qualité du son, les serveurs d'applications de fournisseurs tels que BEA, IBM et Oracle, fournissent un ensemble étourdissant de commandes. L'astuce consiste à tourner les boutons dans le bon sens, en fonction des attributs de votre application.

Par exemple, si votre application est lourde de servlet, vous souhaiterez activer la mise en cache de servlet. De même, si votre application utilise de nombreuses instructions SQL pour prendre en charge une large base d'utilisateurs, vous souhaiterez activer la mise en cache des instructions préparées et définir la taille maximale du cache afin qu'il soit suffisamment grand pour prendre en charge la charge de travail prévue.

L'un des principaux domaines dans lesquels le réglage des performances peut vraiment aider est le pool de connexions à la base de données. Définissez les connexions minimum ou maximum trop bas et vous êtes certain de créer un goulot d'étranglement. Définissez-les trop haut et vous verrez probablement un ralentissement résultant de la surcharge supplémentaire nécessaire pour maintenir le pool de connexions plus important.

Si vous connaissez la charge de travail prévue, réglez l'environnement d'exécution du serveur d'applications en activant les outils de surveillance des performances tels que Tivoli Performance Viewer for WebSphere d'IBM sur un serveur d'applications intermédiaire. Générez la charge de travail que vous attendez à l'aide d'un outil de génération de charge, puis enregistrez les résultats de la surveillance et lisez-les pour analyser les boutons à ajuster.

En production, il est judicieux d'activer la surveillance passive à faible surcharge pour garder un œil sur l'exécution. Si votre charge de travail change au fil du temps, vous souhaiterez exécuter une nouvelle évaluation des performances.

N ° 5: Optimiser la connectivité réseau

La plupart des serveurs d'entreprise de niveau intermédiaire ont désormais des cartes réseau double gigabit, mais la plupart d'entre eux n'utilisent pas le deuxième canal. De plus, les prix des commutateurs Gigabit ont chuté à travers le plancher. Avec un lien de 120 Mbps vers votre serveur de fichiers, un certain nombre de clients de 100 mégabits peuvent accéder simultanément aux fichiers à débit filaire.

Même sans commutation Gigabit, la liaison NIC devrait être un élément essentiel. Dans sa forme la plus simple, la liaison de deux cartes réseau vous offre une redondance, mais ajoute un équilibrage de charge de transmission, et vous pouvez effectivement doubler la bande passante sortante. L'utilisation de l'association assistée par commutateur fournira le même effet sur le trafic entrant. Presque tous les principaux fournisseurs de serveurs proposent des pilotes d'association de cartes réseau - et il existe également des utilitaires tiers. C'est une grosse augmentation de bande passante bon marché.

N ° 6: Liquidation de vos serveurs Web

Pouvez-vous vraiment faire beaucoup pour régler un serveur Web et maximiser les performances? En fait, il y a - principalement en ajustant une poignée de paramètres critiques pour correspondre au trafic de production que vous attendez.

Pour les serveurs Web déjà en production, commencez par collecter des statistiques de serveur Web en temps réel (la plupart des principaux serveurs Web ont cette fonctionnalité intégrée). Passez ensuite à la mise en scène afin de déterminer quels paramètres, le cas échéant, doivent être ajustés.

Activez les outils de surveillance des performances du serveur Web sur le serveur intermédiaire. Exécutez un test de charge et inspectez les paramètres pertinents, tels que le temps de réponse, les octets envoyés et reçus et le nombre de demandes et de réponses.

Les paramètres clés que vous souhaiterez régler en fonction du volume de trafic incluent la mise en cache, le threading et les paramètres de connexion.

Activer la mise en cache pour le contenu fréquemment utilisé; certains serveurs Web vous permettent de mettre en cache des fichiers de manière dynamique en fonction de l'utilisation, tandis que d'autres vous demandent de spécifier ce qui sera mis en cache. Assurez-vous que la taille maximale de votre cache est suffisante pour le trafic que vous attendez. Et si votre serveur Web prend en charge l'accélération du cache, activez-la également.

Pour les paramètres de thread et de connexion, définissez les valeurs minimales et maximales en fonction de la charge de travail attendue. Pour les connexions, vous devrez également définir le nombre maximal de demandes par connexion et le paramètre de délai d'expiration de la connexion. Ne définissez aucune de ces valeurs sur une valeur trop petite ou trop grande, sinon des ralentissements pourraient en résulter.

N ° 7: Le malheur du WAN

Vous pensez avoir besoin de récupérer la bande passante WAN? Vous pouvez facilement dépenser un paquet sur des appliances de formation du trafic ou des moteurs de mise en cache pour tenter de limiter l'utilisation de la bande passante WAN. Mais que faire si ce n'est pas la pipe?

Tout d'abord: avant d'acheter quoi que ce soit, ayez une idée précise du trafic qui traverse le WAN. Les outils d'analyse de réseau tels qu'Ethereal, ntop, Observer de Network Instrument ou EtherPeek NX de WildPacket peuvent vous donner un nouveau regard sur ce qui est réellement sur le fil.

Vous constaterez peut-être que les temps de réplication de votre Active Directory sont définis beaucoup trop bas et que la simple configuration d'intervalles de réplication plus longs peut vous donner une marge de manœuvre pendant la journée de travail. Certains utilisateurs situés dans des emplacements distants mappent-ils des partages sur les mauvais serveurs et tirent des fichiers volumineux sur le WAN sans s'en rendre compte? Les vestiges d'un réseau IPX longtemps désactivé flottent-ils toujours? Certains problèmes de WAN se résument à une mauvaise configuration de l'application, où le trafic est dirigé sur le WAN alors qu'il aurait dû rester local. Des rapports réguliers sur les modèles de trafic WAN permettront d'économiser de l'argent et des maux de tête.

N ° 8: Jouons gentiment

Trop souvent, les applications, les services Web et les sites Web de plusieurs départements de l'entreprise se disputent les ressources serveur. Bien que chacun de ces composants puisse être bien réglé en soi, une application d'un autre service qui utilise également les mêmes clusters de production peut avoir une requête mal réglée ou un autre problème, qui à son tour affecte vos utilisateurs ou clients.

À court terme, tout ce que vous pouvez faire est de travailler avec vos administrateurs système et le service qui rencontre le problème de performances pour obtenir une résolution pour vos utilisateurs ou clients. À plus long terme, créez une communauté dans tous les départements qui utilisent les clusters de production où vos objets sont déployés. Travaillez au sein des équipes pour vous assurer qu'il existe un financement adéquat pour un environnement de préparation qui est vraiment représentatif de l'environnement de production à charge de travail mixte. En fin de compte, vous souhaiterez développer une série de tests de performance pouvant être utilisés pour valider les performances de charge de travail mixte dans l'environnement de test.

N ° 9: Mise en cache, mise en forme, limitation, oh là là!

Si votre WAN est vraiment sous-dimensionné - et que vous ne pouvez pas vous permettre un réseau de relais de trames longue distance - la mise en forme et la mise en cache du trafic peuvent aider à déboucher le tuyau.

Les configurations qui façonnent le trafic sont plus un art qu'une science. La hiérarchisation des applications est souvent plus politique que technique, mais peut avoir des effets considérables sur les performances perçues du réseau.

La mise en cache est une toute autre bête. Cela nécessite moins de travail que la mise en forme du trafic, mais l'impact sera probablement moindre. Les moteurs de mise en cache stockent et diffusent des copies locales des données fréquemment utilisées pour réduire le trafic WAN. L'inconvénient est que le contenu dynamique ne peut pas vraiment être mis en cache, de sorte que les e-mails ne bénéficieront pas de la même amélioration de performances.

N ° 10: Patching prédictif

Vous arrivez au travail le lundi seulement pour apprendre qu'un groupe de postes de travail est bloqué ou que les performances d'une application critique ont ralenti à une analyse. Après enquête, vous déterminez qu'un correctif qui a été appliqué pendant le week-end en est la cause.

C'est pourquoi vous avez besoin d'outils qui prennent en charge les annulations de correctifs. Mieux encore, incluez les tests de correctifs dans le cadre de votre stratégie de gestion des correctifs. Tout d'abord, vous devez faire un inventaire régulier des applications et technologies en jeu sur les postes de travail et les serveurs. La plupart des outils de gestion de systèmes, tels que les SMS de Microsoft, ont la capacité de faire automatiquement un inventaire pour vous.

Ensuite, répliquez les applications et les technologies dans un environnement intermédiaire. Si votre système d'exploitation et votre logiciel d'infrastructure n'incluent pas d'outils de test de correctifs, procurez-vous un outil tiers tel que FLEXnet AdminStudio ou Wise Package Studio.

Vous pouvez également écrire des scripts pour exercer de manière fonctionnelle la plate-forme ou la technologie avec les derniers correctifs en jeu. Vous devrez répéter ce scénario (et ajuster les scripts) à mesure que de nouveaux correctifs arrivent et que des modifications logicielles sont apportées.