Expérience d'optimisation d'un accident de production

Après une promotion d'événement normale, le service client a commencé à donner des commentaires les uns après les autres. Les utilisateurs ont signalé qu'ils ne pouvaient pas ouvrir la page Web ou l'application lors de la saisie des offres. Lorsqu'ils l'ont ouverte, les offres avaient déjà été récupérées. particulièrement intéressé au début. N’est-ce pas ce que c’est lorsque vous êtes en compétition pour un téléphone Xiaomi ? Au fur et à mesure que l'événement se poursuivait, de plus en plus d'utilisateurs ont vivement protesté. Les utilisateurs qui recevaient des coupons de taux d'intérêt ou des coupons en espèces n'ont pas pu récupérer les offres, estimant que la plateforme était frauduleuse et ont délibérément empêché leur utilisation afin d'économiser des ressources.

Processus d'analyse

En fait, il y avait des retours continus d'utilisateurs dans le passé qui n'ont pas diminué, et les clients ont été trompés en utilisant Xiaomi pour prendre les téléphones mobiles comme exemple. était trop fort, alors nous y avons prêté attention et nous nous sommes levés. Nous avons un total de trois produits frontaux, l'application, le site officiel et H5. Parmi eux, l'application est la plus utilisée et le site officiel est rarement utilisé dans la vie quotidienne, mais le trafic augmentera fortement. lors d'événements (les événements sont généralement principalement des jeux H5, et H5 est également pratique pour la promotion et le marketing. ), les trois produits frontaux utilisent tous des LV pour se charger dans les deux serveurs webservice back-end (comme ci-dessous). Cette fois, les commentaires des utilisateurs concernent essentiellement le Web et les applications, alors concentrez-vous sur l'observation de ces quatre serveurs.

Tout d'abord, j'ai soupçonné que la bande passante du réseau était pleine et j'ai trouvé un ingénieur réseau pour la surveiller via l'outil pendant le processus d'appel d'offres. , l'utilisation maximale de la bande passante n'était que d'environ 70 %, puis je l'ai exclu ; j'ai encore une fois douté que le serveur Web ne puisse plus y résister. Utilisez la commande top pour vérifier la charge des deux serveurs. sur le site officiel. Au moment de l'enchère, il montera à environ 6-8, puis lentement après l'enchère, il reviendra à la normale, et les deux serveurs de l'application ont culminé à 10-12, puis reviendront à la normale. .

J'ai suivi le journal d'activité du serveur Web et constaté que la couche de mise à jour de la base de données a signalé qu'aucune nouvelle connexion à la base de données ne pouvait être demandée ou que les connexions à la base de données avaient été utilisées. On pensait que le nombre maximum était atteint. Le nombre de connexions dans la base de données était trop petit, des ajustements ont donc été effectués base de données mysqlLe nombre maximum de connexions est 3 fois celui du passé, je continuerai à observer les journaux d'activité lors des enchères la prochaine fois et je trouverai ces erreurs ; Les liens liés aux bases de données ne sont plus signalés, mais de nombreux utilisateurs signalent toujours que la page ne peut pas être ouverte pendant les enchères.

Continuez à suivre le serveur Web, utilisez la commande (ps -ef|grep httpd|wc -l) pour vérifier le nombre de connexions httpd, qui est d'environ 1 000, et vérifiez de manière aléatoire le nombre maximum de connexions défini dans la configuration Apache file 1024 (le nombre maximum de connexions par défaut d'Apache est de 256). Il s'avère que le nombre de connexions pendant le processus d'enchère a atteint le nombre maximum de connexions. De nombreux utilisateurs n'ont pas pu obtenir de connexions http pendant le processus d'enchère, ce qui fait que la page ne répond plus ou que l'application attend. Ajustez donc le nombre maximum de connexions dans le fichier de configuration Apache à 1024*3.

En continuant à observer pendant le processus d'enchère, le nombre de connexions Apache peut encore grimper entre 2 600 et 2 800 pendant l'enchère. Selon les commentaires du service client, de nombreux utilisateurs signalent encore des problèmes d'enchères, mais c'est légèrement mieux. qu'avant. Un peu, mais il y a des retours sporadiques d'utilisateurs selon lesquels ils ont déjà saisi la cible, et finalement elle a été annulée. Continuez ensuite à observer le serveur de base de données, utilisez la commande top et MySQL Workbench pour afficher les différentes charges de la bibliothèque principale mysql et de la bibliothèque esclave. J'ai été choqué (comme indiqué ci-dessous. Les indicateurs de la bibliothèque principale du serveur mysql ont atteint leur niveau). pic, alors que la bibliothèque esclave n'est presque pas trop grande.

Le suivi du code a révélé que les codes commerciaux aux trois extrémités étaient tous connectés à la bibliothèque principale et que seule la requête en arrière-plan était utilisée à partir de la bibliothèque esclave, la transformation a donc été lancée immédiatement ; à l'exception des requêtes pendant le processus d'enchère, toutes les requêtes sur autres pages ou services ont été transformées en requêtes sur la base de données esclave. Après la transformation, nous avons constaté que le. la pression sur la base de données principale a été considérablement réduite et la pression sur la base de données esclave a commencé à augmenter. Comme indiqué ci-dessous :

D'après les retours du service client, après la transformation, il n'y a quasiment aucun problème de retour de l'enchère lors de la saisie de l'enchère. Il y a aussi le problème. de la page qui ne s'ouvre pas ou s'ouvre lentement pendant le processus d'enchère. Cela a été atténué dans une certaine mesure, mais certains utilisateurs signalent toujours ce problème. D'après les résultats de l'analyse des projets ci-dessus, il est conclu que :

• 1 Les deux serveurs sous charge ont atteint la limite de traitement et doivent être configurés en plus de serveur à charger.

• 2 La pression sur la base de données principale mysql a été considérablement réduite, mais la pression sur la base de données esclave a augmenté. Il est nécessaire de remplacer l'actuel maître et l'esclave par un seul maître. et plusieurs esclaves

  Modèle .

• 3 Pour résoudre complètement ces problèmes, nous devons considérer de manière globale l'optimisation globale de la plateforme, telle que : l'optimisation commerciale (suppression des points chauds dans l'entreprise), l'ajout de mise en cache , paginationstatique partielle (vous pouvez utiliser les règles d'optimisation frontales de Yahoo et de Google, et il existe de nombreux sites Web de test sur Internet pour l'évaluation) et ainsi de suite.

J'ai rédigé un rapport d'optimisation basé sur ces circonstances, voir ci-dessous :

Rapport d'optimisation

1 Contexte

Avec le développement continu des activités de l'entreprise, le volume d'affaires et le volume d'utilisateurs ont augmenté. Le pv du site officiel a également augmenté du xxx-xxx initial au xxx-xxxx actuel, et le nombre d'utilisateurs actifs de l'APP a augmenté. de manière significative, cela a également affecté la technologie

architecture actuelle de la plate-forme qui présente de plus grands défis. Surtout lorsque les ressources d'enchères de la plateforme sont devenues limitées ces derniers temps, le temps nécessaire pour finaliser les enchères est de plus en plus court. La pression sur les serveurs augmente également ; par conséquent, l'architecture système actuelle doit être mise à niveau pour prendre en charge un plus grand nombre d'utilisateurs et un plus grand volume d'activité.

2 Schéma d'accès des utilisateurs

Actuellement, la plate-forme propose trois produits destinés aux utilisateurs, parmi lesquels le site Web officiel de la plate-forme, l'application de la plate-forme et la petite page Web de la plate-forme ; , le site officiel de la plateforme et la plateforme APP La pression est relativement élevée.

3 Problèmes

Lorsque les utilisateurs rivalisent pour des offres, les problèmes se concentrent sur les aspects suivants

1 La page Web ou l'application ne peut pas être ouverte
2 Le site Web ou l'application est lent. pour ouvrir
3. Une fois le transfert réussi pendant le processus d'enchère, la mise à jour a échoué en raison de la forte pression exercée sur le serveur, un remboursement a donc été émis à nouveau
4. Le nombre de connexions à la base de données a été épuisé, ce qui a entraîné échec d'ajout d'enregistrements d'investissement une fois l'enchère terminée et la progression de l'enchère a été annulée

Analyse

Grâce à une analyse approfondie des paramètres récents du serveur, de la concurrence et des journaux système. , il est conclu que :

1. La pression du serveur est énorme pendant le processus d'appel d'offres sur le site officiel de la plateforme et sur la plateforme APP, parmi lesquels le problème de l'APP de la plateforme est plus important pendant la période d'enchères maximale. Les connexions Apache pour un seul serveur APP étaient proches de 2600, ce qui est proche de la capacité de traitement maximale d'Apache

2. Le serveur de base de données est soumis à une pression énorme. La pression sur la base de données est principalement importante sur deux périodes

1) Lorsque la plateforme exerce des activités, le nombre de visites sur le site officiel, les petites pages Web et les applications augmente considérablement, ce qui entraîne une énorme augmentation du volume de requêtes de données. . Lorsque la limite de traitement de la base de données est atteinte, des problèmes surviennent. Il y a des problèmes tels qu'une ouverture lente du site Web
2) Lorsque les utilisateurs se disputent des offres, la pression sur les utilisateurs pour qu'ils se disputent des offres est divisée en deux étapes : les enchères et pendant les enchères. Avant d'enchérir, étant donné que les enchères sont remplies très rapidement, les utilisateurs ouvrent la page d'enchères à l'avance et la rafraîchissent continuellement. Si le nombre d'utilisateurs en compétition pour les enchères est très important, le nombre de connexions à la base de données augmentera. sera utilisé avant l'enchère. Au cours du processus d'enchère, un seul achat impliquera probablement environ 15 tables de modification et de requête. Chaque offre a une part de 10 millions, et environ 100 à 200 personnes achèteront et termineront l'offre complète. temps. Calculé sur la base de la valeur médiane de 150 personnes, en quelques secondes. Les données doivent être mises à jour 2000 à
3000 fois sur une période donnée (uniquement les mises à jour, à l'exclusion des requêtes), ce qui donne un résultat important. quantité de concurrence, ce qui peut entraîner des échecs de mise à jour ou des délais d'attente de connexion, affectant ainsi les enchères des utilisateurs et la note normale de satisfaction du système.

5 Solutions

1. Solution de serveur Web

Schéma schématique d'un seul utilisateur accédant aux services Web

Site Web et plateforme actuels L'APP utilise deux services pour une responsabilité équilibrée. Chaque serveur est

installé avec Apache pour le traitement côté serveur. Chaque Apache peut gérer un maximum d'environ 2 000 connexions. Par conséquent, en théorie, le site Web ou l’application actuel peut traiter plus de 4 000 demandes d’utilisateurs. Si vous souhaitez prendre en charge 10 000 requêtes en même temps, vous avez besoin de 5 serveurs Apache pour le prendre en charge, il vous manque donc actuellement 6 serveurs Web. Schéma d'accès après mise à niveau du serveur

2. Solution de base de données

Plan de déploiement actuel de la base de données

1) Maître-esclave séparément résolvez 80 % de la pression des requêtes de la base de données principale. À l'heure actuelle, le site officiel et l'APP de la plateforme sont connectés à la base de données principale MySQL, ce qui double la pression sur la base de données principale. La migration de toutes les requêtes du service vers la base de données esclave peut réduire considérablement la pression sur la base de données principale.

2) Ajouter un serveur de cache. Lorsque la requête de la base de données esclave atteint son apogée, cela affectera également la synchronisation maître-esclave, affectant ainsi les transactions. Par conséquent, les requêtes fréquemment utilisées par les utilisateurs sont mises en cache pour réduire la pression des requêtes sur la base de données. Il est nécessaire d'

ajouter trois serveurs de cache pour construire un cluster redis.

3. Autres optimisations
1) La page d'accueil du site officiel est statique Selon les statistiques du cnzz, la page d'accueil représente environ 15 % du total des visites du site Web. Les données ne changent pas fréquemment sur la page d'accueil. sont traités de manière statique pour améliorer la fluidité de l'ouverture du site officiel.

2) Optimiser le serveur Apache, activer la compression gzip, configurer un nombre raisonnable de liens, etc.

3) Supprimer le hotspot de mise à jour dans le processus d'investissement : le calendrier cible. Chaque fois qu'une offre réussit ou échoue, le calendrier des enchères doit être mis à jour. Des problèmes tels que le verrouillage optimiste peuvent survenir lors des mises à jour multithread. Éliminez les mises à jour pendant le processus et enregistrez les informations sur la progression de l'offre dans le calendrier d'appel d'offres uniquement une fois l'offre terminée, optimisant ainsi la pression sur la base de données pendant le processus d'investissement.

6 Plan de mise à niveau du serveur

1. La plus grande pression sur la plateforme vient de la base de données, qui doit passer d'un maître et un esclave à un maître et quatre esclaves. Un grand nombre de requêtes générées par le site Web/l'application/la petite page Web officiels sont distribuées à trois bases de données esclaves par IP virtuelle, et les requêtes de gestion en arrière-plan sont envoyées à une autre base de données esclave. La base de données doit ajouter trois nouveaux serveurs
Diagramme schématique après la mise à niveau de la base de données

2. Augmentez le cache pour réduire la pression des données Deux nouveaux serveurs de cache avec une grande mémoire doivent être ajoutés

3. Trois nouveaux serveurs Web doivent être ajoutés pour décomposer les demandes d'accès des utilisateurs

L'application doit ajouter deux nouveaux serveursLa pression sur le serveur d'application pendant le processus d'appel d'offres. Au maximum, deux nouveaux serveurs doivent être ajoutés. Schéma schématique une fois la configuration terminée

Le site officiel doit ajouter un serveur supplémentaire. Le site officiel rencontre également certaines difficultés dans le processus d'appel d'offres, un nouveau serveur doit être ajouté. Le schéma complété est le suivant :

. Un total de 8 serveurs doivent être achetés, dont deux nécessitent une grande mémoire (64 Go ou plus)

Cliquez pour télécharger le rapport d'optimisation wordversion

Remarque : Une fois toutes les solutions d'optimisation mises en production, les problèmes sont résolus et il n'est pas nécessaire de rivaliser pour les appels d'offres !

---

Auteur : Pure Smile
Source : http://www.php.cn/
Copyright appartient à l'auteur Veuillez indiquer la source lors de la réimpression

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!