Les métriques d'infrastructure ne sont plus efficaces que lorsqu'elles sont liées aux métriques d'application.
La clé d'une optimisation efficace des performances réside dans les données de performance.
Certains outils APM fournissent une prise en charge prête à l'emploi pour ASP.NET, donc démarrer avec ASP.NET ne nécessite qu'une configuration initiale minimale.
Les outils d'analyse de code donnent la vue la plus détaillée des performances du programme.
L'outil d'analyse léger donne une vue en temps réel des performances des pages Web et peut être utilisé dans les environnements de développement et de production.
"Cette page Web s'ouvre trop lentement !" Cette plainte concernant les sites Web est fréquente et courante, d'autant plus que les applications Web ont commencé à remplacer progressivement les applications de bureau. Bien que le Web apporte des fonctionnalités idéales telles que la diffusion mondiale, il apporte également des défis correspondants au niveau des performances.
L'utilisateur vous a donné l'URL d'une page Web « lente », alors que devez-vous faire ? D’où vient le problème de lenteur d’ouverture des pages Web ? Était-ce si lent depuis le début ? Est-ce lent pour tous les utilisateurs ? De nombreux problèmes comme ceux-ci doivent être résolus pour résoudre le problème de la lenteur d'ouverture des pages Web et garantir qu'elles ne ralentissent plus après une semaine.
Bien que vous puissiez rechercher des informations sur l'optimisation des performances sur Internet, elles portent généralement sur des sujets spécifiques tels que Jit, le garbage collection, l'optimisation des requêtes SQL, les pièges ORM, etc. Compte tenu de la perspective alléchante de mise en œuvre d’optimisations, une question se pose : comment savez-vous que la méthode d’optimisation choisie produira réellement de bons résultats pour votre problème de performances actuel ?
Il ne fait aucun doute qu’il manque quelque chose dans ce travail. Nous avons besoin de moyens pour trouver des problèmes de performance de manière durable. En utilisant cette approche, nous pouvons identifier les parties les plus lentes du système et disposer de mesures tangibles pour étayer notre diagnostic des problèmes de performances. Une fois que nous comprenons où se situent les problèmes de performances, nous pouvons déterminer si des améliorations des performances sont nécessaires et expliquer tout cela aux parties prenantes.
Pour les problèmes de performances mentionnés ci-dessus, une identification précise est un moyen plus efficace de les résoudre. Le problème ne vient peut-être pas en premier lieu d’un chargement lent de la page Web. En présence de délais d'attente (par exemple, l'équilibreur de charge peut attendre plusieurs secondes avant de gérer la connexion), il est impossible de savoir s'il s'agit d'un problème de blocage ou d'un problème de temps de réponse lent, car les deux problèmes provoquent la même chose. Le résultat est un temps mort. Cela nécessite des données pour trouver la véritable cause du problème.
Pour illustrer l'importance d'identifier avec précision les problèmes de performances, voici quelques points de dépannage possibles qui entraînent une réponse lente dans les applications Web :
JavaScript répond lentement ;
Le blocage se produit lors du chargement des ressources
Il y a un proxy côté client
Problème DNS
Problème de FAI ou de réseau
Commutateurs et routeurs
Équilibreur de charge ;
Code d'application (y compris les bibliothèques de logiciels tiers)
; Serveur HTTP (par exemple parfois ASP.net ou IIS
) Services tiers, tels que : prestataires de services de paiement, prestataires de services de cartes, etc.
; Sous-systèmes, notamment : SQL Server, Redis, Elasticsearch, Rabbit MQ, etc.
Des points de dépannage de performances supplémentaires peuvent être répertoriés, en fonction de la complexité et de la taille du système à résoudre. Comment pouvez-vous diagnostiquer les problèmes de performances alors qu’un si grand nombre de composants système peuvent affecter les problèmes d’optimisation des performances ? La réponse peut se résumer en un mot : données. Vous avez besoin de données pertinentes et significatives sur chaque composant du système. Pour le problème de la lenteur de réponse des applications Web, les données peuvent prouver si chaque composant du système a un impact sur le problème ou est totalement hors de propos.
Avec les données en main, vous pouvez commencer à extraire les points de dépannage de la liste ci-dessus en fonction de vos idées d'analyse, ce qui s'apparente à une recherche dans un arbre de tri. Chaque fois que vous descendez d'un niveau dans l'arborescence, vous vous rapprochez des détails et de l'essence du problème de performances. Vérifiez si le problème de performances existe dans :
. Côté client, côté serveur ou quelque part entre les deux ?
JavaScript lent, rendu ou blocage de ressources ?
Équilibreur de charge, serveur Web, sous-système ou logiciel tiers ?
Au fur et à mesure que vous descendez de niveau en niveau dans un tel arbre, les problèmes de performances deviennent de plus en plus évidents. Pour chaque niveau de dépannage, les données requises pour localiser les problèmes de performances doivent correspondre à la précision du problème correspondant. A cette époque, il est nécessaire d'utiliser des outils tels que des outils d'analyse des performances ou des plans d'exécution SQL.
Afin d’utiliser efficacement le temps, il est nécessaire de réitérer la loi d’Amdahl :
Peu importe l’amélioration d’une tâche, les parties de la tâche qui ne bénéficient pas de l’amélioration limitent l’accélération théorique de la tâche.
Par exemple, dans une requête Web, on suppose que 100 millisecondes de temps de traitement du serveur et 5 secondes de temps de requête SQL sont nécessaires. Même si vous pouvez optimiser le temps de traitement du serveur à moins de 1 milliseconde, l'amélioration du temps de réponse global est faible, de 5,1 secondes à 5 secondes. Les 5 secondes nécessaires à l'amélioration du traitement SQL constituent l'optimisation présentant le plus grand gain potentiel.
Cette méthode descendante de clarification des problèmes d'optimisation couche par couche a un bon effet sur les problèmes d'optimisation limités à une seule page. Alors, quel est l’effet lorsqu’il est appliqué à des problèmes d’optimisation qui s’étendent sur plusieurs pages ? Par exemple, le problème de l'ouverture lente par intermittence de certaines pages est dû au fait que le sous-système n'est pas en mesure de suivre le rythme de travail global ou au fait qu'il existe un ancien commutateur réseau dans le système qui peut ne plus fonctionner après le redémarrage.
Dans ce cas, l’approche de surveillance centrée sur les applications montre ses limites. Cela nécessite davantage de mesures au niveau logiciel et matériel pour évaluer chaque composant du système.
Au niveau matériel, les premières choses qui viennent à l’esprit sont les serveurs web et les serveurs de bases de données, mais ils ne représentent que la pointe de l’iceberg. Tous les composants matériels du système doivent être identifiés et surveillés. Cela inclut : les serveurs, les commutateurs réseau, les routeurs, les équilibreurs de charge, les pare-feu, les SAN, etc.
Étant donné que le travail habituel de l’administrateur système consiste à surveiller le matériel, tous les indicateurs ci-dessus peuvent être évidents pour l’administrateur système. Mais voici une mise en garde importante : la plupart de ces mesures matérielles sont inutiles du point de vue des performances si elles sont traitées séparément des mesures logicielles. En d’autres termes, les indicateurs ne peuvent fonctionner de manière optimale que s’ils sont placés dans un environnement approprié.
Par exemple, dans certains cas, il peut être tout à fait normal que l'utilisation du processeur soit en moyenne de 50 % sur un serveur de base de données, mais pour d'autres serveurs, cela constitue une bombe à retardement. Une utilisation du processeur de 50 %, si elle se produit aux heures de pointe, signifie qu'il reste encore beaucoup de place pour exécuter des tâches plus lourdes. Mais si une utilisation de 50 % du processeur se produit fréquemment pendant les périodes d'inactivité, cela signifie que l'application risque de ne pas être en mesure de résister à des pics soudains de requêtes entrantes.
L’essentiel est que pour évaluer l’état du système, les métriques à l’échelle du système telles que le processeur, la mémoire et le disque doivent être corrélées aux métriques des applications. Pour donner une vue plus complète de l'état du système, des métriques d'application telles que le débit des requêtes et des métriques système telles que l'utilisation du processeur peuvent être visualisées.
Les outils APM fournissent des opérations de base telles que la collecte de données, le stockage de données et la visualisation des données. Généralement, un agent est chargé de collecter et d'envoyer des données à un magasin de données, et d'utiliser une interface Web pour visualiser les données dans un tableau de bord axé sur les requêtes Web.
APM peut être utilisé pour :
Fournir une visualisation globale des performances des applications Web
Visualisez les performances de requêtes Web spécifiques
Envoyez automatiquement des alertes lorsque les performances de l'application Web se détériorent ou que plusieurs erreurs se produisent
Lorsque le volume d'activité est important, vérifiez le mode de réponse de l'application.
Des exemples sont donnés ici.
Voici une liste non exhaustive des outils APM prenant en charge ASP.NET et IIS :
NewRelic APM
Informations sur les applications
AppDynamics
Stackifier
Les outils de surveillance de l'infrastructure collectent des métriques au niveau de l'hôte, qui peuvent refléter plus complètement les performances. Ces métriques sont collectées aux niveaux matériel et logiciel.
DataDog
OpServer - Open Source
Des outils d'analyse légers fournissent des mesures de haut niveau pour des requêtes Web spécifiques et fournissent des commentaires en temps réel lorsque les développeurs parcourent les pages Web. Ces outils peuvent être utilisés dans tous les types d'environnements (y compris les environnements de développement, la vérification de l'assurance qualité, les environnements de test, les environnements de production, etc.), ils sont donc idéaux pour une évaluation rapide des performances d'une page spécifique.
Par rapport aux outils d'analyse complets correspondants, la différence essentielle entre les outils d'analyse légers est qu'ils ne sont pas liés au processus, ce qui signifie que vous n'avez pas à vous soucier de la surcharge qu'ils génèrent lors de l'utilisation d'outils d'analyse légers.
Dans l'environnement de développement, des outils d'analyse légers fournissent un retour en temps réel sur le code en cours d'écriture. Ceci est très utile pour repérer des problèmes comme N+1 ou des temps de réponse lents, puisque les temps de réponse sont toujours affichés dans le coin de la page.
MiniProfiler open source
Aperçu open source
Les compteurs de performances des systèmes Windows fournissent différents indicateurs au niveau matériel et logiciel. Les outils de surveillance signalent souvent des compteurs de performances, tels que l'utilisation du processeur et de la mémoire. Mais souvent, certains compteurs utiles manquent, comme le temps de ramassage des ordures, etc. La manière la plus pratique de commencer est d’utiliser une liste de base et d’ajouter les compteurs pertinents nécessaires à l’itération. De plus, il est possible d'utiliser perfmon pour collecter et visualiser des compteurs de performances en temps réel. Dans de nombreux cas, il est également possible d’intégrer des indicateurs ou des plug-ins personnalisés par l’utilisateur aux outils APM.
Étant donné que les bases de données sont couramment utilisées dans de nombreuses applications, la couche de persistance (c'est-à-dire la base de données SQL) devient souvent un goulot d'étranglement en termes de performances. Les outils professionnels de surveillance SQL peuvent fournir des mesures d'utilisation des ressources, ainsi que des mesures spécifiques telles que les temps d'attente, les compilations par seconde, etc., pour n'en nommer que quelques-unes.
En fournissant les données suivantes, certains types de problèmes peuvent être découverts et des améliorations de performances peuvent être apportées :
Débit excessif sur une ou plusieurs requêtes
Utilisation excessive du processeur, ce qui suggère des problèmes de requête ou des index manquants
; Requêtes à haut débit pouvant être mises en cache.
Les outils de surveillance SQL incluent :
Moniteur SQL RedGate
Conseiller en performances SQLSentry
Tous les sous-systèmes doivent être surveillés dans une certaine mesure. Pour les systèmes à faible débit ou non critiques, une simple collecte et visualisation de données suffira. Dans d’autres cas, une surveillance professionnelle plus avancée est requise.
Lorsqu'une page ou un morceau de code spécifique a été identifié comme lent, les outils d'analyse de code peuvent fournir la vue la plus détaillée possible pour l'identification des problèmes de performances. Les outils d'analyse de code fournissent également une vue précise des appels externes tels que les requêtes de base de données et les requêtes Web.
Outils d'analyse :
Fourmis Redgate
JetBrains dotTrace
Les métriques de surveillance de la mémoire et de garbage collection aident à détecter les problèmes potentiels. Mais même si ces indicateurs montrent qu’il y a un problème, ils ne permettent souvent pas de savoir où se situe le problème. Si vous avez besoin d’approfondir les problèmes de mémoire et de garbage collection, les outils d’analyse de la mémoire peuvent s’avérer utiles.
Outils d'analyse :
JetBrains dotMemory
Profileur de mémoire de fourmis RedGate
Les problèmes de performances peuvent également provenir du front-end. Ce problème est très courant de nos jours en raison de la prolifération d'applications monopage alimentées par JavaScript. Tous les principaux navigateurs disposent d'outils intégrés tels que l'analyse de code et l'analyse de la mémoire. Les outils qui affichent la séquence des événements et des demandes permettent de déterminer en un coup d'œil si un problème provient du front-end ou du back-end.
Outils :
Chronologie de Google Chrome
Firefox
Les outils clients de haut niveau constituent un point de départ pratique pour identifier et résoudre les problèmes de performances. Ces outils peuvent fournir une vue d’ensemble des causes profondes des problèmes de temps de réponse et formuler des recommandations. Par exemple, PageSpeed Insights de Google est un outil gratuit.
Il existe tellement de facteurs et d’outils liés aux performances du système que cela peut paraître compliqué. Mais ils peuvent se résumer en un mot : données. Avoir une vision claire et précise du système permet de raisonner sur les problèmes de performances. Cela vous permet également d'apprendre à résoudre les problèmes de performances sur place, car les mesures et graphiques de performances vous guideront pour découvrir ce qui affecte exactement les performances du système.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
