it-swarm.com.de

Universelles Problem: erste Anfrage nach ~ 25 Sekunden Inaktivität immer langsamer (~ 1 Sekunde) als nachfolgende Anfragen (~ 1/10sec)

Das ist mir aufgefallen, seit ich mit WordPress arbeite. Dies ist ein universelles Problem in dem Sinne, dass es keine Rolle spielt, ob sich die WP -Installation auf meinem gemeinsam genutzten Hosting-Konto befindet (ich habe jedoch keine anderen Anbieter ausprobiert) oder auf einem lokalen LAMP-Setup.

Brandneues, sauberes WordPress mit 1 Post, 1 Seite und defauktem Theme - oder altem WP mit Hunderten von Posts, einem heftigen Theme und Tonnen von Plugins ... macht keinen Unterschied.

Derzeit wird an einer rasant schnellen lokalen virtuellen Maschine gearbeitet (i7-3930k mit einer schnellen SSD, CentOS 6.2, Softaculous, Standard-Apache und MySQL, sonst läuft nichts auf der Box) und das Szenario sieht folgendermaßen aus:

  1. Erstmaliges Laden von Front- oder Backendseiten: ca. 1 Sekunde Verzögerung.
  2. Anschließendes Laden derselben oder einer anderen Seite (Front- oder Backend) innerhalb von ~ 25 Sekunden: praktisch sofortige Reaktion.
  3. 25 Sekunden warten, neu laden, die 1-Sekunden-Verzögerung ist wieder da

Dieses 25-Sekunden-Intervall ist ungefähr die beste Messung, die ich im Rahmen meiner Geduld machen konnte, aber es hat eine ziemlich gute Genauigkeit und Wiederholbarkeit.

Weitere Beobachtungen:

  • Unterschiedliche Installationen auf derselben LAMPE sind voneinander "isoliert", d. H. Das Laden eines Standorts und das sofortige Laden eines anderen führt nicht dazu, dass dieser schnell geladen wird.
  • Meine aktuelle "Lösung" besteht darin, einen Tab mit einer Dummy-Seite zu öffnen, die sich alle 20 Sekunden neu lädt

Hat jemand anderes dieses Problem bemerkt? Was könnte es sein? Gerne stelle ich Ihnen alle Details zur Verfügung, die Sie bei der Suche nach diesem Problem unterstützen. Danke euch allen!

1
Flix

Hier sind einige mögliche Gründe für Langsamkeit, ohne auf Ihre Box zu schauen, um genau zu sehen, was los ist:

Mögliche Ursachen

Apache

Apache istnormalerweiseso konfiguriert, dass immer ein einzelner httpd-Prozess im Hintergrund läuft. Wenn eine Anfrage über die Leitung eingeht, wird ein neuer httpd-Prozess gestartet, um die Anfrage zu bearbeiten. Sobald die Anforderung geschlossen ist, bleibt der neue httpd-Prozess eine Weile in der Warteschleife und der Master-Prozess leitet zusätzliche Anforderungen an ihn weiter, falls er vorhanden ist.

Nach einer bestimmten Zeit der Inaktivität wird der untergeordnete Prozess heruntergefahren. Dies bedeutet, dass der Master-Prozess den Speicher neu zuordnen und einen neuen Prozess starten muss, wenn die nächste Anforderung eingeht.

Ich verwende Begriffe wie "eine Weile" und "bestimmte Zeit", da dies alles konfigurierbare Optionen für Ihren Server sind. Mit der Direktive StartServers können Sie die Anzahl der untergeordneten Prozesse verwalten, die herumstehen. Möglicherweise möchten Sie auch die Anweisungen MinSpareThreads und MaxSpareThreads prüfen, da sie die "Anzahl der inaktiven Threads für die Verarbeitung von Anforderungsspitzen" verwalten.

Weitere Details zu diesen Richtlinien finden Sie im Handbuch .

PHP

Ähnlich wie Apache kann PHP auf verschiedene Arten konfiguriert werden, je nachdem, wie Sie es auf Ihrem Server installieren. Die beiden beliebtesten für Apache sind als CGI-Skript und als Apache-Modul.

Als CGI-Skript wird PHP als separater Prozess ausgeführt. Wie bei Apache sitzen normalerweise ein oder zwei Instanzen herum, um Anforderungen zu bearbeiten. Nach einer gewissen Zeit der Inaktivität werden sie jedoch deaktiviert, um Speicherplatz in Ihrem System freizugeben.

Als Apache-Modul wird PHP in Apache selbst kompiliert. Wenn Sie also eine freie Instanz von httpd haben, haben Sieaucheinen PHP -Handler eingerichtet . Wie ich oben im Apache-System beschrieben habe, verschwinden diese zusätzlichen Instanzen, es sei denn, Sie haben Apache so konfiguriert, dass sie aktiv bleiben.

Es gibt einige weitere Informationen zu mod_php vs PHP als CGI hier .

MySQL

Das größte Problem hierbei ist jedoch MySQL. Wie die meisten anderen Datenbanken speichert MySQL seine Daten auf der Festplatte, speichert jedoch die Ergebnisse von Abfragen in einem speicherinternen Cache, um die Suche etwas zu beschleunigen. Was Sie wahrscheinlich sehen, ist das Ergebnis der Entscheidung von MySQL, dass Sie nach etwa 25 Sekunden verschwunden sind und die Daten nicht mehr benötigen.

Das Zwischenspeichern grundlegender Abfragen ist für Websites mit hohem Datenaufkommen unglaublich effizient, selbst wenn der Server eine SSD für die Datenpersistenz verwendet, da die Ergebnisse und Daten im Speicher bleiben und keine tatsächlichen Suchvorgänge durchgeführt werden müssen, um auf Anforderungen zu antworten. Leider tritt wahrscheinlich ein Problem auf, bei dem der Cache veraltet ist (oder ein intern konfigurierter Timeout-Schwellenwert erreicht wird) und nachfolgende Anforderungen die Daten erneut aus dem Dateisystem abrufen müssen.

Weitere Informationen zum Abfrage-Cache finden Sie in der MySQL-Dokumentation .

Minderung

Serverkonfiguration

Wenn Sie kein Systemadministrator sind, würde ich empfehlen, einen Vertrag für ein paar Stunden abzuschließen, um einen Blick auf Ihre Box- und Tweak-Einstellungen zu werfen. Das Installieren neuer Stacks von der Stange ist normalerweise für alle Benutzer in Ordnung (und das Laden einer Seite auf einem nicht zwischengespeicherten Vanilla-Server ist nichts, wofür man sich schämen muss). Standardkonfigurationen sind jedoch nicht als ein Szenario zu verstehen, das allen Anforderungen gerecht wird. Wenn Sie einen Experten zur Hand haben, der Ihren Stack so konfiguriert, dass Ihre Hardware optimal genutzt wird, ist das Geld gut angelegt.

Front-End-Caching

Wenn sich Ihre Seiten nicht ändern, können Sie die gerenderten Seiten in einem Front-End-Cache speichern und schnell bereitstellen. Batcache verwendet beispielsweise Memcached auf dem Server, um gerenderte Seiten zu speichern in-memory. Dies bedeutet, dass nachfolgende Anforderungen den vollständig vorbereiteten Beitrag aus Memcached holen, anstatt auf WordPress zu warten Rufen Sie die Daten erneut aus der Datenbank ab und bauen Sie die Dinge wieder für Sie auf.

WP Super Cache wird etwas Ähnliches tun, aber stattdessen die gerenderte Seite als statische HTML-Datei speichern, damit die Besucher diese erfassen, anstatt WordPress etwas analysieren zu lassen. Der Engpass beim Laden von Seiten ergibt sich dann aus der Geschwindigkeit Ihrer SSD + der von Ihrem Host bereitgestellten Bandbreite.

6
EAMann