Nach einer normalen Event-Werbung gab der Kundenservice nacheinander Rückmeldung, dass er die Webseite oder APP nicht öffnen konnte, als er sie öffnete, da die Gebote bereits eingeholt worden waren Zuerst war ich besonders interessiert. Ist es nicht so, wenn man um Gebote konkurriert, und ist es nicht so, wenn man um Xiaomi-Telefone konkurriert? Im weiteren Verlauf der Veranstaltung protestierten immer mehr Nutzer heftig, die Zinsgutscheine oder Geldgutscheine erhielten, konnten sich die Gebote nicht sichern, da sie der Ansicht waren, dass die Plattform betrügerisch sei und deren Nutzung absichtlich verhinderte, um Ressourcen zu sparen.
Analyseprozess
Tatsächlich gab es in der Vergangenheit kontinuierlich Benutzer-Feedbacks, die nicht abnahmen, und Kunden wurden getäuscht, indem sie Xiaomi als Beispiel verwendeten, um sich Mobiltelefone zu schnappen. Diesmal das Benutzer-Feedback war zu stark, also sind wir aufgestanden. Wir haben insgesamt drei Front-End-Produkte: App, offizielle Website und H5. Die App wird am häufigsten verwendet, und die offizielle Website wird im täglichen Leben selten verwendet, aber der Verkehr wird stark zunehmen Bei Veranstaltungen (bei Veranstaltungen handelt es sich in der Regel hauptsächlich um H5-Spiele, und H5 eignet sich auch gut für Werbung und Marketing.) verwenden die drei Front-End-Produkte alle LVS, um in die beiden Back-End-WebService-Server zu laden (wie Diesmal erfolgt das Benutzerfeedback hauptsächlich auf der Web- und App-Seite. Konzentrieren Sie sich also auf die Beobachtung dieser vier Server.
Zuerst vermutete ich, ob die Netzwerkbandbreite voll war, und fand einen Netzwerktechniker, der sie über das Tool überwachte , die maximale Bandbreitenauslastung betrug nur etwa 70 % und dann zweifelte ich erneut daran, ob der Webserver dem nicht mehr standhalten würde Auf der offiziellen Website steigt der Wert auf etwa 6 bis 8, und nach dem Gebot kehrt er langsam zur Normalität zurück, und die beiden Server der App erreichen ihren Höhepunkt bei 10 bis 12 . Verfolgte das Webserver-Geschäftsprotokoll und stellte fest, dass die Datenbank-
Aktualisierungsschicht
meldete, dass keine neuen Datenbankverbindungen angefordert werden konnten oder die Datenbankverbindungen aufgebraucht waren Die Anzahl der Verbindungen in der Datenbank war zu gering, daher wurden Anpassungen vorgenommen. MySQL-DatenbankDie maximale Anzahl von Verbindungen ist dreimal so hoch wie in der Vergangenheit. Ich werde beim nächsten Bieten weiterhin das Geschäftsprotokoll beobachten und feststellen, dass Fehler vorliegen im Zusammenhang mit Datenbankverknüpfungen werden nicht mehr gemeldet, aber viele Benutzer berichten immer noch, dass die Seite während des Bietens nicht geöffnet werden kann. Verfolgen Sie weiterhin den Webserver, verwenden Sie den Befehl (
), um die Anzahl der httpd-Verbindungen zu überprüfen, die etwa 1.000 beträgt, und überprüfen Sie nach dem Zufallsprinzip die in der Apache
Konfiguration festgelegte maximale Anzahl von Verbindungen Dateips -ef|grep httpd|wc -l 1024 (die standardmäßige maximale Anzahl von Verbindungen beträgt 256). Es stellt sich heraus, dass die Anzahl der Verbindungen während des Ausschreibungsprozesses die maximale Anzahl von Verbindungen erreicht hat. Dies führt dazu, dass die Seite nicht mehr reagiert oder die App gewartet hat. Passen Sie daher die maximale Anzahl von Verbindungen in der Apache-Konfigurationsdatei auf 1024*3 an. Beobachten Sie weiterhin während des Ausschreibungsprozesses, dass die Anzahl der Apache-Verbindungen während der Ausschreibung immer noch auf 2600–2800 ansteigen kann. Dem Feedback des Kundendienstes zufolge berichten immer noch viele Benutzer über Ausschreibungsprobleme, aber es ist etwas besser Ein wenig mehr als zuvor, aber es gibt vereinzelt Rückmeldungen von Benutzern, dass sie das Ziel bereits erreicht haben, und schließlich wurde es zurückgesetzt. Beobachten Sie dann weiterhin den Datenbankserver und verwenden Sie den Befehl top und MySQL Workbench, um die verschiedenen Lasten der MySQL-Hauptbibliothek und der Slave-Bibliothek anzuzeigen Peak, während die Slave-Bibliothek fast nicht zu groß ist.
Beim Verfolgen des Codes wurde festgestellt, dass die Geschäftscodes an den drei Enden alle mit der Hauptbibliothek verbunden waren und nur das Hintergrundgeschäft
Abfrage
verwendet wurde aus der Slave-Bibliothek, sodass die Transformation sofort gestartet wurde. Mit Ausnahme von Abfragen während des Ausschreibungsprozesses wurden alle Abfragen auf anderen Seiten oder Diensten in Abfragen in der Slave-Datenbank umgewandelt Der Druck auf die Master-Datenbank wurde deutlich reduziert und der Druck auf die Slave-Datenbank begann zuzunehmen. Wie unten gezeigt:
Laut dem Feedback des Kundendienstes gibt es nach der Umwandlung fast kein Problem, das Gebot zurückzugeben, wenn man das Gebot erhält. Es gibt auch das Problem dass die Seite während des Ausschreibungsprozesses nicht geöffnet werden kann oder sich langsam öffnet, aber einige Benutzer berichten immer noch über dieses Problem. Aus den Analyseergebnissen der oben genannten Projekte wird geschlossen, dass:
Auf der Grundlage dieser Umstände habe ich einen Optimierungsbericht geschrieben, siehe unten:
Optimierungsbericht
1 Hintergrund
Mit der kontinuierlichen Weiterentwicklung des Geschäfts des Unternehmens sind das Geschäftsvolumen und das Benutzervolumen sprunghaft angestiegen. Auch der offizielle Website-PV ist von ursprünglich xxx-xxx auf den aktuellen xxx-xxxx gestiegen, und die aktiven Benutzer der APP sind gestiegen Daher hat es auch die Technologie
Architektur der aktuellen Plattform vor größere Herausforderungen gestellt. Insbesondere wenn die Gebotsressourcen der Plattform in letzter Zeit knapp sind, wird die Zeit bis zum Abschluss der Gebotsabgabe immer kürzer. Auch der Druck auf Server nimmt zu; daher muss die aktuelle Systemarchitektur aktualisiert werden, um eine größere Anzahl von Benutzern und ein größeres Geschäftsvolumen zu unterstützen.
2 Benutzerzugriffsdiagramm
Derzeit stehen den Benutzern drei Produkte zur Verfügung, darunter die offizielle Website der Plattform, die Plattform-APP und die kleine Plattform-Webseite , die offizielle Website der Plattform und die Plattform-APP Der Druck ist relativ hoch.
3 Probleme
Wenn Benutzer um Gebote konkurrieren, konzentrieren sich die Probleme auf die folgenden Aspekte
Die Webseite oder APP kann nicht geöffnet werden
Die Website oder APP ist langsam zu öffnen
3. Nachdem die Übertragung während des Ausschreibungsprozesses erfolgreich war, scheiterte das Update aufgrund der starken Belastung des Servers, sodass erneut eine Rückerstattung gewährt wurde
4. Die Anzahl der Datenbankverbindungen war erschöpft, was dazu führte, dass Es konnten keine Investitionsdatensätze hinzugefügt werden, nachdem die Ausschreibung abgeschlossen war, und der Fortschritt der Ausschreibung wurde zurückgesetzt
4. Analyse
Durch eingehende Analyse der aktuellen Serverparameter, Parallelität und Systemprotokolle Daraus wird geschlossen, dass:
1. Der Serverdruck ist während des Ausschreibungsprozesses der offiziellen Website und der Plattform-APP besonders groß Die Anzahl der Apache-Verbindungen für einen einzelnen APP-Server liegt bei nahezu 2600, was nahe an der maximalen Verarbeitungskapazität von Apache liegt
2. Der Datenbankserver steht unter enormem Druck. Der Datenbankdruck ist hauptsächlich in zwei Zeiträumen ausgeprägt
1) Wenn die Plattform aktiv ist, steigt die Anzahl der Besuche auf der offiziellen Website, kleinen Webseiten und APPs dramatisch an, was zu einem enormen Anstieg des Datenabfragevolumens führt Wenn die Datenbankverarbeitungsgrenze erreicht ist, treten Probleme auf, wie zum Beispiel das langsame Öffnen der Website.
2) Wenn Benutzer um Gebote konkurrieren, ist der Druck auf Benutzer, um Gebote zu konkurrieren, in zwei Phasen unterteilt: vor dem Bieten und während Bieten. Da die Gebote sehr schnell ausgeschöpft sind, öffnen Benutzer die Gebotsseite im Voraus und aktualisieren sie kontinuierlich. Dies erhöht den Abfragedruck auf die Datenbank. Wenn die Anzahl der um Gebote konkurrierenden Benutzer sehr groß ist, erhöht sich die Anzahl der Datenbankverbindungen wird vor der Gebotsabgabe aufgebraucht sein. Für einen einzelnen Kauf werden voraussichtlich etwa 15 Tische zum Wechseln und Abfragen benötigt, und etwa 100 bis 200 Personen werden jeweils das gesamte Gebot abgeben Zeit. Berechnet auf der Grundlage des Mittelwerts von 150 Personen in wenigen Sekunden. Die Daten müssen innerhalb eines Zeitraums 2000-
3000 Mal aktualisiert werden (nur Aktualisierungen, ohne Abfragen), was zu einer großen Zeit führt Ausmaß der Parallelität, was zu Aktualisierungsfehlern oder Verbindungs-Timeouts führen kann und sich somit auf die Benutzergebote und die normale Systemzufriedenheit auswirkt.
5 Lösungen
1. Webserver-Lösung
Schematische Darstellung eines einzelnen Benutzers, der auf Webdienste zugreift
Aktuelle Website und Plattform Die APP nutzt zwei Dienste für eine ausgewogene Verantwortung. Jeder Server ist mit Apache für die serverseitige Verarbeitung ausgestattet. Jeder Apache kann maximal etwa 2.000 Verbindungen verarbeiten. Daher kann die aktuelle Website oder APP theoretisch mehr als 4.000 Benutzeranfragen verarbeiten. Wenn Sie 10.000 Anfragen gleichzeitig unterstützen möchten, benötigen Sie dafür 5 Apache-Server, sodass Ihnen derzeit 6 Webserver fehlen.
Zugriffsdiagramm nach dem Upgrade des Servers
2. Datenbanklösung
Aktueller Datenbankbereitstellungsplan
1) Master-Slave separat Lösen Sie 80 % des Abfragedrucks der Hauptdatenbank. Derzeit sind die offizielle Website und die APP der Plattform mit der MySQL-Hauptdatenbank verbunden, wodurch sich der Druck auf die Hauptdatenbank verdoppelt. Durch die Migration aller Abfragen im Dienst in die Slave-Datenbank kann der Druck auf die Hauptdatenbank erheblich verringert werden. 
2) Fügen Sie einen Cache-Server hinzu. Wenn die Slave-Datenbankabfrage ihren Höhepunkt erreicht, wirkt sich dies auch auf die Master-Slave-Synchronisation und damit auf Transaktionen aus. Daher werden häufig von Benutzern verwendete Abfragen zwischengespeichert, um den Anforderungsdruck auf die Datenbank zu verringern. Es ist notwendig,
drei Cache-Server
hinzuzufügen, um einen
Redis-Cluster zu erstellen.
3. Weitere Optimierungen
1) Die Homepage der offiziellen Website ist laut cnzz-Statistik für etwa 15 % aller Besuche auf der Website verantwortlich werden statisch verarbeitet, um das reibungslose Öffnen der offiziellen Website zu verbessern.
2) Optimieren Sie den Apache-Server, aktivieren Sie die gzip-Komprimierung, konfigurieren Sie eine angemessene Anzahl von Links usw.
3) Entfernen Sie den Update-Hotspot im Investitionsprozess: den Zielplan. Jedes Mal, wenn ein Gebot erfolgreich ist oder fehlschlägt, muss der Gebotsplan aktualisiert werden. Bei Multi-Thread-Updates können Probleme wie optimistisches Sperren auftreten. Entfernen Sie Aktualisierungen während des Prozesses und speichern Sie die Informationen zum Angebotsfortschritt erst dann im Gebotsplan, wenn das Angebot vollständig ist, um den Druck auf die Datenbank während des Investitionsprozesses zu optimieren.
6 Server-Upgrade-Plan
1 Der größte Druck auf die Plattform geht von der Datenbank aus, die von einem Master und einem Slave auf einen Master und vier Slaves geändert werden muss. Eine große Anzahl von Abfragen, die von der offiziellen Website/App/kleinen Webseite generiert werden, werden über virtuelle IP an drei Slave-Datenbanken verteilt, und die Hintergrundverwaltungsabfragen gehen an eine andere Slave-Datenbank. Die Datenbank muss drei neue Server hinzufügen
Schematische Darstellung nach dem Datenbank-Upgrade
2. Erhöhen Sie den Cache, um den Datendruck zu verringern. Es müssen zwei neue Cache-Server mit großem Speicher hinzugefügt werden
3. Drei neue Webserver müssen hinzugefügt werden, um Benutzerzugriffsanfragen zu zerlegen
Die App muss zwei neue Server hinzufügen
Der Druck auf dem App-Server während des Ausschreibungsprozesses. Nach Abschluss der Konfiguration müssen höchstens zwei neue Server hinzugefügt werden.
Auf der offiziellen Website muss ein weiterer Server hinzugefügt werden
Die offizielle Website hat auch gewisse Schwierigkeiten im Bieterverfahren, ein neuer Server muss wie folgt hinzugefügt werden:
Insgesamt müssen 8 Server gekauft werden, von denen zwei großen Speicher benötigen (64 G oder mehr)
Klicken Sie hier, um den Optimierungsbericht mit derordVersion
Hinweis: Nachdem alle Optimierungslösungen in Produktion gegangen sind, sind die Probleme gelöst und es besteht kein Grund zur Sorge um Angebote!
Autor: Pure Smile
Quelle: http://www.php.cn/
Copyright gehört dem Autor. Bitte geben Sie beim Nachdruck die Quelle an
Das obige ist der detaillierte Inhalt vonOptimierungserfahrung eines Produktionsunfalls. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
