Praxiserfahrung beim Skalieren und Optimieren der Leistung

Die Website, an der ich arbeite, wird angeblich bald nach dem Start eine massive Trefferquote haben . Der Kunde spricht über die Möglichkeit von ungefähr 2500 Treffern pro Sekunde pro Tag.

Ignoriert man die Tatsache, dass diese Trefferquote wahrscheinlich ein wilder Client-Optimismus ist und abgesehen davon, dass die größtmöglichen Server verfügbar sind, sollte Drupal am besten so konfiguriert werden, dass eine hohe Trefferquote unterstützt wird.

Ich habe Scaling the drupal.org Infrastructure , den Drupal-Performance-Blog , Best Practices for Scaling Drupal und viele andere Seiten gelesen erwarten von.

Markdorisons Antwort ist im Grunde die akzeptierte Methode, um dieses Problem zu bekämpfen. Ich gehe noch ein bisschen weiter.

Wenn Pressflow für D6 oder Drupal für D7, Memcached und Varnish gut zusammenarbeiten, müssen Sie Ihre VCL- Datei benutzerdefiniert codieren . Es gibt kostenlose, die als Ausgangspunkt dienen, aber Sie müssen immer damit spielen.

Damit Varnish optimal funktioniert, müssen Sie es mit -s malloc xG und nicht mit der Standardeinstellung -s file / path / to / file starten. Auch mit Varnish können Sie statische Elemente so lange wie möglich im Varnish-Cache speichern.

Wenn Sie mehr als einen Webserver haben, entfernen Sie das ETag aus dem Header, der in VCL an Varnish gesendet wurde. Ich entferne auch Expires und verlasse mich einfach auf Age und max-age in den Headern, damit die Browser wieder auf die Site gelangen.

Version 1.5 (ab 3. März 2011) ist immer noch die schnellste Version des Memcached-Moduls von Drupal.org. Normalerweise verwende ich ein einzelnes Fach pro Server, um den TCP-Verkehr für Verbindungen zu mehreren Fächern im großen Maßstab zu verringern.

Konfigurieren Sie das Caching in "Leistung" auf extern und legen Sie ein maximales Alter fest, das die richtigen Header an einen Caching-Proxy wie Varnish sendet.

Wenn bestimmte Seiten in Varnish nicht ordnungsgemäß zwischengespeichert werden können, lesen Sie die Blogposts im Web, in denen ausführlich erläutert wird, wie die Anforderungen überprüft werden. Hier ist ein Beispielbeitrag, den ich vor einiger Zeit geschrieben habe: Was hindert Varnish und Drupal Pressflow daran, Seitenaufrufe anonymer Benutzer zwischenzuspeichern?

Sie sollten InnoDB (oder einen seiner anderen Namen von anderen Anbietern wie XtraDB) für MySQL auswählen und alle Tabellen in dieses Verzeichnis verschieben. Dann lesen Sie diesen Blog-Beitrag, um grundlegende Tipps zur Optimierung zu erhalten. Http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Ein großer Pufferpool ist von grundlegender Bedeutung. Aktivieren Sie beim Testen der Site das langsame Abfrageprotokoll. Sie möchten wahrscheinlich zuerst Abfragen erfassen, die länger als 50 ms dauern, dann die Abfragen optimieren und die langsame Protokollerfassungszeit wiederholt verringern, bis die meisten Abfragen mithilfe von Indizes ausgeführt werden und relativ schnell ausgeführt werden.

Andere Grundlagen beinhalten APC für PHP. Wenn Sie sich für schnelles CGI anstatt für mod_php entscheiden, sollten Sie einige Zeit damit verbringen, den APC-Cache für alle PHP-Instanzen gemeinsam zu nutzen, indem Sie ein gutes Wrapper-Skript konfigurieren. Stellen Sie außerdem sicher, dass sich der APC-Cache in einer Speicherzuordnungsdatei befindet, um das letzte Bit aus PHP herauszuholen.

Ich würde empfehlen, mit Pressflow (wenn Sie Drupal 6 verwenden), Memcache , Varnish und einer Form von Content Distribution Network (CDN) wie Akamai zu beginnen. Das Endergebnis sollte sein, dass so wenige dieser Benutzer wie möglich tatsächlich Ihren Ursprungsserver erreichen.

Wenn Sie Teile der Seite haben, die Sie nicht für anonyme Benutzer zwischenspeichern können (Dinge, die für diesen Benutzer spezifisch sind, "Welcome userX" usw.), können Sie Optionen untersuchen, um diese Teile der Seite zu füllen, z. B. asynchron Callbacks oder Edge Side Includes.

Wenn Sie eine kleinere Gruppe interner Benutzer (z. B. eine Gruppe von Editoren) haben, die eine nicht zwischengespeicherte Version der Site anzeigen müssen, würde ich empfehlen, eine nicht zwischengespeicherte Version Ihrer Site unter einer anderen URL (geschützt hinter einem VPN) bereitzustellen oder gleichwertig, wenn möglich).

2500 Zugriffe pro Sekunde über einen Tag - Wenn Sie mit "Zugriffen" "Ausgelieferte Seite" meinen, sind das 216 Millionen Seiten pro Tag. Lassen Sie mich das sagen: Sie haben nicht 216 Millionen Seiten pro Tag. Ich liebe diese Kunden ...

Das heißt, eine rohe Verkehrsdaten sagt nichts aus. Der Ratschlag in diesem Thread zu Varnish / CDN ist zwar gut, wenn Sie nur anonymen Datenverkehr haben, aber wenn Sie sich angemeldet haben, stehen Sie vor einer Herausforderung. Stellen Sie jedoch sicher, dass Sie ein Problem haben, bevor Sie gottlos viel Zeit und Mühe aufwenden, um ein Problem zu lösen . 2500 Hits pro Sekunde, Bing wird kürzer, das merkt man doch, oder?

• Serverseite

  • Installieren Sie Varnish zum Zwischenspeichern von Seiten für anonyme Benutzer.
  • Installieren Sie ein persistentes Cache-System (Memcached, APC, Memcache).
  • Verwenden Sie eine CDN wie Akamai, um statische Dateien (JavaScript, CSS, Bilder) bereitzustellen.

• Codeseite

  • Mit Pressflow kann Varnish zwischengespeicherte Seiten für anonyme Benutzer bereitstellen.
  • Reinigen Sie die Watchdog-Tabelle von Drupal. Jedes Mal, wenn ein Watchdog-Fehler protokolliert wird, werden CPU-Ressourcen auf dem Webserver und dem Datenbankserver verbraucht. Es erhöht auch die Ladezeit erheblich.
  • Implementieren Sie statische und persistente Cache- Strategien, bis das langsame Abfrageprotokoll fehlerfrei angezeigt wird.
  • Vermeiden Sie um jeden Preis PHP-Fehler, die in verschachtelten foreach-Schleifen auftreten.
  • Deinstallieren Sie nicht verwendete Module.
  • Aktivieren Sie die Zwischenspeicherung für Drupal-Kernblöcke und -Ansichten.

• Datenbank

  • Stellen Sie sicher, dass die Tabellen für eine schnellere Suche ordnungsgemäß indiziert sind.
  • Speichern Sie keine unnötigen Datensätze. Auf eine Datenbank mit 100 Knoten wird immer schneller zugegriffen als auf eine Datenbank mit 3 Millionen Knoten.

Ich würde auch diesen Lullabot-Podcast über die Art und Weise anhören, wie sie die Grammys.com-Website für eine Verkehrsexplosion im Laufe einer Woche eingerichtet haben. Es war eine ziemlich lehrreiche Erklärung.

http://www.lullabot.com/podcasts/podcast-92-grammycom

Es ist zwar sehr schwierig, Muster vorherzusagen, wenn Sie eine gute Vorstellung vom Verkehrsaufkommen haben. Laden Sie testen Sie Ihre Lösung. Es gibt eine Vielzahl verschiedener Optionen, und eine Menge kann erst vorhergesagt werden, wenn Sie über Live-Datenverkehr verfügen. Wenn Sie jedoch so viele Tests wie möglich ausführen, können Sie sicher sein, dass Ihr Setup Datenverkehr verarbeiten kann.

Das ganze Tuning auf der Welt wird nicht helfen, wenn Sie es nicht zuerst testen.

Dies war eine Präsentation im DC SF über die Vorgehensweise des Ökonomen. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online-using-grinder

Für stark frequentierte Websites sollten Sie mehrere Server und Load Balancer verwenden oder einfach CDN verwenden. Es ist auch sehr wichtig, so viel wie möglich zwischenzuspeichern, um die Belastung der Webserver zu minimieren.

Die Verwendung von Content Delivery Network ( CDN ) hilft dabei, die Ressourcen auf mehrere Domänen zu verteilen (Domain-Sharding), wodurch die Belastung des Webservers verringert wird.

Die Verwendung von CDN unterstützt das verteilte Caching und die Remote-Beschleunigung und verringert DDoS-Angriffe aufgrund mehrerer Endpunkte. Dies hilft bei der Sicherheit, da zwischengespeicherte Inhalte schwieriger auszunutzen sind.

Beispielanbieter: Fastly , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Hier noch ein paar Vorschläge:

• Verwenden Sie mit CDN Domänen ohne Cookies, damit statische Komponenten zwischengespeichert werden (z. B. sstatic.net ). Da einige Proxys es möglicherweise ablehnen, die mit Cookies angeforderten Komponenten zwischenzuspeichern.
• Wärmen Sie Ihre Caches auf, nachdem Sie die Caches geleert haben (mit wget, Cache Warmer , Drush ECL ).
• Verwenden Sie die Leistungsüberwachung (z. B. New Relic oder Yottaa, die für Drupal integriert sind).
• Verwenden Sie ein Überwachungstool für Ihre Website (z. B. Nagios).
• Installieren Sie das Modul zur Integration von Varnish und Varnish HTTP Accelerator und konfigurieren Sie es anschließend .
• Lack + Authcache: Aktivieren Sie diese Beispiel-VCL für die Authcache- Lack-Konfigurationsdatei.
• Betrachten Sie Pfund oder NGINX vor Lack. Sehen Sie: Warum Pfund vor Lack großartig ist .
• NGINX kann als Reverse-Proxy und Load-Balancer eingesetzt werden und kann daher Pound und Varnish ersetzen.
• Ziehen Sie eine kommerzielle Version von Varnish oder NGINX in Betracht, um Funktionen zu nutzen, die in der Open Source-Version "Community" nicht verfügbar sind.
• Erwägen Sie einen Hardwarelastausgleich / -caching, um Lack und Pfund zu ersetzen (z. B. BIG-IP F5 ).
• Verwenden Sie Tools wie abJMeter für TTFB sowie Last- und Stresstests für Ihre Webanwendung.

So kann Ihre Webarchitektur aus Anwendersicht aussehen:

1. Benutzer (lokales Browser-Caching).
2. NGINX oder Pound + Varnish (Load Balancer, Reverse Proxy als HTTP-Beschleuniger).
3. Apache (Webserver).
4. PHP-FPM (PHP FastCGI Process Manager).
5. MariaDB (Datenbank).

Überprüfen Sie für Drupal-Optimierungsvorschlag: Wie verbessern Sie Drupal-Leistung?

Aktivieren Sie zwei Erweiterungen:

• Zend OPcache
• Wincache

Ihre Leistung wird besser funktionieren.

Wenn Sie den Zend OPcache und den Wincache in Microsoft Azure optimieren möchten, erstellen Sie zunächst einen Ordnernamen ' ini' unter ' D:\home\site\'. Erstelle auch 2 Dateien, ' .user.ini' und ' settings.ini'

Fügen Sie jeder Datei die folgende Konfiguration hinzu:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Fügen Sie Ihrer Web-App außerdem eine App-Einstellung mit dem Schlüssel PHP_INI_SCAN_DIR und dem Wert hinzu d:\home\site\ini

Starten Sie nach dem Ändern von PHP_INI_SYSTEM Ihre Web-App neu. Weitere Informationen zur Twigging-Konfiguration finden Sie in der Microsoft-Dokumentation .

Nach der obigen Einstellung wird meine Drupal-Site (Drupal 8.3) innerhalb von 3 Sekunden geladen.

Sie können auch die Umverteilung der Last auf mehrere Server mithilfe einer DNS-basierten oder einer Software- / Hardware-Lastausgleichslösung untersuchen. Dies würde auch in Fehlertoleranz einbrennen.