Ich habe eine D7-Site mit einem Minelli-Unterthema zusammengestellt. Unterwegs habe ich viel mit verschiedenen Themen, verschiedenen Modulen experimentiert. Irgendwo auf dem Weg habe ich ein merkwürdiges Leistungsproblem entwickelt, und jetzt weiß ich nicht wirklich, welches Thema / Modul / Konfiguration es verursacht hat.

Das Problem ist, dass es beim ersten Besuch der Website ungefähr 15 Sekunden dauert, bis die erste Seite angezeigt wird. Ich kann mich dann auf der Website bewegen und sie reagiert sehr schnell. Wenn ich es ungefähr eine Stunde stehen lasse und dann darauf zurückkomme, ist die erste Anfrage wieder sehr langsam.

Ich habe den Cache geleert, damit das nicht das Problem sein sollte. Außerdem habe ich Themen und Module deaktiviert, die ich nicht verwende. Ich habe den Standort auf eine neue Infrastruktur verlegt, aber das Problem ist aufgetreten!

Wohin gehe ich als nächstes?

Es gibt drei Dinge, die ich prüfen würde.

Erstens sollten Sie sicherstellen, dass APC aktiviert ist, über genügend Arbeitsspeicher und eine lange TTL verfügt, wenn Sie sich auf einer Produktionssite befinden und keine PHP-Dateien bearbeiten (Sie könnten einen Tag einplanen oder nie ablaufen, wenn Sie möchten). Sie können auch Einstellungen vornehmen apc.stat=0. Die APC-Dokumente enthalten alle Informationen, die Sie zum Einstellen der TTL benötigen. Um die Größe des Speichers zu bestimmen, sollten Sie die Datei apc.php an einen geschützten Ort legen und die Speicherauslastung und die Abwanderungsstatistik überwachen. Stellen Sie den APC-Speicher so ein, dass Ihre Fehlerrate sehr niedrig ist. Die anfängliche Verlangsamung kann darauf zurückzuführen sein, dass die APC voll ist und sich entleert (IIRC, APC gibt den gesamten Cache aus, wenn er voll ist, anstatt LRU oder fortgeschrittenere Cache-Strategien zu verwenden).

Stellen Sie zweitens sicher, dass Sie MySQL richtig eingestellt haben. Sie können mysqltuner verwenden , um Ihre Puffergrößen anzupassen. Ihre anfängliche Verlangsamung kann darauf zurückzuführen sein, dass Tabellen vom Datenträger geladen wurden und / oder dass der Abfrage-Cache nicht funktioniert. Obwohl mysqltuner nicht perfekt ist, bringt es Sie in die richtige Richtung.

Drittens stellen Sie sicher, dass Sie eine echte Drupal-Cron- Strategie haben. Persönlich würde ich automagic cron unter "admin / config / system / cron" deaktivieren und eine crontab einrichten, die jede Nacht ausgeführt wird. Sie können auch Elysia Cron ausprobieren, wenn Sie wirklich eine genauere Kontrolle über die Dinge benötigen. Auf diese Weise können Sie die erforderlichen Aufgaben so oft ausführen, wie Sie möchten, während die normalen Aufgaben über Nacht ausgeführt werden. Ihre anfängliche Langsamkeit könnte durch stündliche Cron-Runs verursacht werden. Sie können dies bestätigen, indem Sie sich ansehen, wann cron auf "admin / reports / dblog" ausgeführt wird, und versuchen, mit Ihrer Langsamkeit übereinzustimmen.

Ivanhoe123 hat wahrscheinlich recht: Drupal 7 wird mit standardmäßig aktiviertem 'poor mans cron' ausgeliefert. Kurz gesagt bedeutet dies, dass (gelegentlich) cron ausgeführt wird, bevor Drupal die Seite rendert, wodurch alles verzögert wird.

Versuchen Sie immer, einen echten Cron-Job an Produktionsstandorten zu verwenden. Weitere technische Details finden Sie unter http://drupal.org/cron oder wenden Sie sich an Ihr Hosting-Unternehmen.

Um es zu deaktivieren, gehe zu admin / config / system / cron und wähle 'Nie'.

Das Devel- Modul bietet Datenbankprotokollierung, um zu prüfen, ob Sie lange laufende Abfragen haben.

Wenn dies nicht hilft, nehmen Sie entweder XHProf oder XDebug und finden Sie den Schuldcode . XHProf (ein Profiler) zeichnet Ihnen eine schöne Übersicht über alle Funktionen, die auf dem Server ausgeführt werden, und zeigt Ihnen, welche die meiste Ausführungszeit in Anspruch nehmen. Wenn XDebug (ein Debugger) dagegen mit einer IDE wie Eclipse ( siehe Video ) konfiguriert ist , können Sie alle Funktionen, die LIVE ausgeführt werden, genauer untersuchen. Der Profiler gibt Ihnen eine Vorstellung davon, was gerade ausgeführt wird. während der Debugger Ihnen zeigt, warum es ausgeführt wird.

Nur aus dem Geschmack der Frage denke ich sofort an drei (3) Dinge

• MySQL Storage Engine / CPU
• Datenbank-Caching
• Tischverriegelung

MySQL-Speicher-Engine

Wenn Sie keine FULLTEXT-Suche / -Indizierung verwenden, empfehle ich Ihnen dringend, alle Ihre MyISAM-Daten in InnoDB zu konvertieren. MyISAM ist nicht dafür ausgelegt, mehrere CPUs und mehrere Kerne zu nutzen. InnoDB wurde für die Verwendung mehrerer CPUs sowie für das Lesen / Schreiben von Hyperthreading erheblich verbessert.

Hier sind einige Beiträge, die ich dazu in DBA StackExchange und auf dieser Site im Hinblick auf die Optimierung von MySQL für InnoDB Performance verfasst habe

• Sep 20, 2011: Multi-Cores und MySQL-Performance
• Sep 12, 2011: Es ist möglich, dass MySQL mehr als einen Kern verwendet
• Jun 07, 2011: Wie konvertiere ich eine Datenbank von MyISAM nach InnoDB?
• May 26, 2011: Informationen zur Leistung von Datenbanken mit einem Thread im Vergleich zu Datenbanken mit mehreren Threads
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/was-würde-die-optimale-mysql-konfiguration-für-a-drupal-7-site/2367#2367 sein

Datenbank-Caching

Ein weiteres starkes Argument für die Konvertierung aller MyISAM-Daten in InnoDB ist, wie MySQL Daten / Indizes zwischenspeichert. Die MyISAM Storage Engine speichert nur Indizes zwischen. InnoDB speichert Daten und Indizes zwischen . In Anbetracht dessen können Sie genügend Speicher für den InnoDB-Pufferpool zuweisen, um einen der folgenden Speicherbereiche aufzunehmen (je nachdem, welcher kleiner ist).

• Alle InnoDB-Daten und -Indizes (Ideal, wenn Sie auch für das Betriebssystem genügend RAM haben; spätere Verzögerungen werden vermieden)
• 75% des installierten RAM (falls Sie mehr InnoDB-Daten / -Indizes als RAM haben; minimiert Verzögerungen)

Wenn Sie MySQL 5.1 verwenden, können Sie innodb_max_dirty_pages_pct = 0 setzen. Dies erhöht die Datenträger-E / A geringfügig, aber der InnoDB-Pufferpool wird so gelöscht, dass alte Daten- und Indexseiten ohne Datenträger-E / A-Schwankungen rotieren können. Das InnoDB Plugin von MySQL 5.5 und MySQL 5.1 benötigt diese Anpassung nicht, da es einen besseren Standard-Buffer-Pool-Flush-Mechanismus hat.

Wenn die Verwendung von InnoDB nicht in Frage kommt, müssen Sie möglicherweise memcached oder lackieren. Auf diese Weise kann der Entwickler bestimmen, wie lange zwischengespeicherte Daten im Server-RAM gespeichert werden. Dies erfordert natürlich eine Entwicklungsverbesserung, um Ihre Anwendung memcached / lackbewusst zu machen.

Tischverriegelung

• InnoDB führt Sperren auf Zeilenebene durch, wodurch Transaktionen und nicht blockierende Lesevorgänge möglich sind .
• MyISAM führt nur eine vollständige Tabellensperrung für jedes INSERT, UPDATE und DELETE durch .

Epilog

Sie können eine anfängliche Verzögerung nach einem MySQL-Neustart nicht vermeiden. Sobald Sie MySQL mit den oben genannten Vorschlägen / Informationen verbessern, sollten Sie jedoch keine weiteren Verzögerungen mehr feststellen.

Ich würde Tools wie YSlow oder Firebug usw. verwenden, um genau zu bestimmen, was passiert, wenn Sie die Seite laden und wenn Sie die Seite unmittelbar danach laden. Überprüfen Sie, ob es sich um ein Caching-Problem handelt, und überprüfen Sie außerdem, wie es funktioniert, wenn Sie als anonymer Benutzer und dann als authentifizierter Benutzer auf die Seite zugreifen. Vergleichen Sie dies mit Ihren Leistungseinstellungen in Drupal.

Wenn es sich nicht um ein Caching-Problem handelt, verwenden Sie das Abfrageprotokoll von Devel sowie die MySQL-Protokolle, um zu sehen, was in der Datenbank geschieht. Wenn Sie Opcode oder ähnliche leistungssteigernde Caches auf dem Server haben, versuchen Sie darüber hinaus, einige Nummern zu deaktivieren und wieder zu aktivieren.

Klingt wie der Cron läuft.

Überprüfen Sie Ihre Einstellungen hier: admin / config / system / cron

Aus diesem Grund hätte ich Drupal für mein letztes Projekt fast fallen lassen.

Es muss mich aber mehr als einen Grund geben. Ich habe noch keine Lösung gefunden, die bei jedem Auftreten dieses Problems funktioniert.

Syslog und Ubuntu / Debain

Das erste Mal, dass ich die intermittierende Ladezeit von 15 Sekunden durchlief, war das Ausführen von Drupal auf (dedizierten, nicht gemeinsam genutzten) Debian / Ubuntu-basierten Systemen. Das Deaktivieren des Syslog-Moduls war die Lösung für mich.

Wie @BetaRide sagte, ist die Verwendung von xDebug oder einem anderen PHP-Profiler extrem aufschlussreich.

Immer noch ein Problem - eine Problemumgehung

Bei meinen anderen Installationen bin ich immer noch ratlos.

Dieses Problem macht sich auf meinem Entwicklungsserver und bei der Installation von Drupal mit geringem Datenverkehr stärker bemerkbar.

Als Workaround habe ich einen Cron-Job eingerichtet, um die Homepage der Site alle 60 Sekunden und das Cron-Skript von Drupal alle 300 Sekunden zu laden. Das ist natürlich nicht optimal, aber ich würde eher die 15 Sekunden Ladezeit als einen menschlichen Besucher erleben.

Viele Leute meinen, dieses Problem könnte mit dem Blockieren synchroner Hintergrundprozesse zusammenhängen , insbesondere mit schweren Cron-Jobs .

Wenn dies zutrifft, gibt es ein großes Paar von Modulen, die von gielfeldt * in der aktiven Entwicklung sind und dieses Problem möglicherweise beheben oder zumindest Hinweise geben und den Site- Erstellern dabei helfen, bestimmte Schuldige in ihren Fällen zu diagnostizieren und zu behandeln. Beide ersetzen blockierende synchrone Prozesse durch nicht blockierende asynchrone HTTP- oder HTTP-Befehle, und beide bieten relevante Berichte, die störende Prozesse identifizieren können:

• Hintergrundprozess und seine gebündelten Module ermöglichen die asynchrone Verarbeitung der Drupal-Hintergrundprozesswarteschlange, sodass sie nicht blockiert werden. Dies könnte das Problem beenden. Mit dem Apache Server-Modul für Hintergrundprozesse in der neuesten Version gibt es auch einen grundlegenden, aber verbesserten UI-Bericht mit Funktionen zum Überwachen, Entsperren und Überprüfen der Startzeiten und des Fortschritts dieser Prozesse. Dies könnte den Problemprozess identifizieren.
• Ultimate Cron baut auf dem Hintergrundprozess auf, damit von Crons ausgelöste Aufgaben ihre eigenen separaten asynchronen Module haben, von denen jedes in einer Benutzeroberfläche überwacht und gestoppt werden kann. Es ist nicht nur eine hervorragende Lösung, um leistungsstarke Aufgaben von regelmäßigen Bereinigungen mit geringem Aufwand zu trennen, sondern bietet Ihnen auch einen Bericht mit nützlichen Informationen, z. usw. Dies könnte auch das Blockieren von und / oder Identifizieren von Problemprozessen beseitigen.

Beide sind sowieso sehr nützliche Module; Für dieses Problem können sie verwendet werden, um die (sehr plausibel klingende) Theorie zu testen, dass die Blockierungen durch synchrone Blockierungsprozesse oder Cron-Läufe verursacht werden. Möglicherweise könnten sie das Problem lösen, indem sie diese nicht synchron, sondern asynchron ausführen, und sie könnten möglicherweise Hinweise darauf geben, welche spezifischen Prozesse den Stillstand verursacht haben. (Seien Sie gewarnt, dass ihre Dokumentation noch in Arbeit ist ...

Wenn sie jedoch nicht so konfiguriert werden können, dass sie helfen, bedeutet dies, dass das Problem mehr ist als nur synchrone Hintergrundprozesse. FWIW, ich hatte noch nie ein bestimmtes Problem auf einer Site, seitdem diese Module ordnungsgemäß funktionieren (noch - berühren Sie Holz) -, aber ich habe es auf meinen Sites zuvor sowie auf Live-Drupal-Sites in freier Wildbahn gesehen.

Beachten Sie auch die anderen Plug-in-Module, die sich derzeit in der Entwicklung befinden - z. B. in komplexen Fällen mit hoher Intensität, kann Ultimate Cron Queue Scaler , der eine schwellenbasierte Drosselung ermöglicht, dazu beitragen, cron-bezogene Leistungsprobleme zu reduzieren.

* keine Zugehörigkeit, ich bin nur ein sehr beeindruckter Benutzer ihrer Arbeit

Da dies mich wieder trifft, habe ich begonnen, das Problem zu untersuchen. Das kann ich definitiv bestätigen

1. Ein Aufruf von, drupal_cron_run()ausgelöst durch den Cron of Core von Poorman, verlängert die Anforderungszeit auf meinem Dev-Rechner um ~ 5 Sekunden. Dies kann getestet werden, indem die Tests um den Aufruf von drupal_cron_run()in modules/system/system.modulein auskommentiert werdensystem_run_automated_cron()
2. Das Löschen aller Caches verlängert die Anforderungszeit auf meinem Entwicklungscomputer um ~ 2 Sekunden. Dies kann getestet werden, indem Sie a drush cc allausführen und die Seite erneut laden.

Dies bedeutet, dass das Setzen von cron auf never und das Hinzufügen eines Aufrufs an cron über crontab die Situation erheblich verbessert. Wenn Sie einige häufig verwendete Seiten direkt nach dem Auffüllen des Caches aufrufen, wird die Benutzererfahrung erneut verbessert.

Ich bin mir jedoch nicht sicher, was das Caching angeht. Ich habe die Standard-Cache-Einstellungen für diese Site nicht geändert. Ich denke, dass Drupal von Zeit zu Zeit alle Caches neu erstellt, möglicherweise ausgelöst durch Cron, aber ich bin nicht sicher, wie das gemacht wird. Aber eine Verzögerung von 7s ist so ziemlich das, was ich sehe, wenn ich nach einigen Stunden auf die Seite gehe.

Probleme wie dieses können Sie verrückt machen, und wenn ich in ähnlichen Situationen war, hilft es herauszufinden, was das Problem verursacht, und es dann als anonymer und angemeldeter Benutzer zu testen. (Zwiebelschicht-Methode)

Sie erwähnen, dass Sie das Problem bemerken, nachdem Sie mit ein paar Themen gespielt und Ihre eigenen benutzerdefinierten Codes erstellt haben. Ich weiß nicht, wie komplex Ihre Website ist und welche Logik dahinter steckt, aber die folgenden Schritte helfen Ihnen, das Problem zu finden:

1. Erstellen Sie auf Ihrem Server einen Ordner oder ein anderes Konto (dies könnte besser sein), in dem Sie eine saubere Drupal-Installation mit derselben Version durchführen, die Sie auf Ihrer Site verwenden. Dann, ohne ein Modul oder Thema hinzuzufügen, testen Sie die Zeit, die die Site benötigt, um auf die erste Anfrage und die folgende Anfrage zu antworten. Wenn alles gut funktioniert, können Sie Probleme mit der Serverkonfiguration ignorieren. Wenn das Verhalten mit dem aktuellen übereinstimmt, liegt entweder ein Konfigurationsfehler mit dem Webserver oder der Datenbank vor.

2. Wenn die Ergebnisse von Schritt 1 gut sind und der Server schnell reagiert und die folgenden Anforderungen genauso schnell sind, installieren Sie nur das Design von Ihrer aktuellen Site auf der Site für die Neuinstallation und testen Sie es erneut. Wenn immer noch alles schnell reagiert, ist Ihr Thema nicht das Problem und Sie sollten mit Schritt 3 fortfahren, da Sie sonst mit dem Debuggen Ihres Themas beginnen müssen * 1.

3. Wenn die Site nach den Tests in Schritt 2 immer noch schnell beginnt, die Module in Ihrer aktuellen Site zu übernehmen, und stellen Sie sicher, dass Sie die Antwortzeit testen, nachdem Sie jedes Modul hinzugefügt und aktiviert haben * 2.

4. Wenn die Site nach dem Hinzufügen des Themas und der Module immer noch schnell reagiert, fügen Sie die Konfiguration hinzu, erstellen Sie Inhaltstypen, importieren Sie Ansichten, Setup-Menüs usw. Vergessen Sie nicht, die Site-Antwort nach jedem Hinzufügen zu testen.

5. Setup und Konfiguration fertig und die Site immer noch schnell, nun bringen Sie die Daten vorbei. Importieren Sie Knoten, Taxonomiebegriffe, Kommentare usw. Ich weiß, dass ich wie eine kaputte Aufzeichnung klingen muss, aber testen Sie immer, nachdem Sie jeden Schritt ausgeführt haben.

* 1 Testen von Themen: Dieser Vorgang kann in einem überaus ausgearbeiteten Thema schwierig sein. Hier einige Hinweise:

1. Wenn Sie eine Verknüpfung zu einer externen js- oder css-Bibliothek herstellen, versuchen Sie, eine lokale Kopie derselben zu verwenden.

2. Suchen Sie in Ihrer template.php-Datei nach Funktionen, die längere oder endlose Schleifen aufweisen können, sowie nach Vorverarbeitungsfunktionen und / oder Hook-Designfunktionen.

3. Überprüfen Sie andere Vorlagendateien (page.tpl.php usw.) und suchen Sie nach PHP-Rohdaten für Arrays und Objekte.

4. Wenn Sie "Ansichten" und Ansichten-Vorlagendateien verwenden, überprüfen Sie dies ebenfalls.

5. Überprüfen Sie immer die Pfade, optimieren Sie Bilder, Js und CSS-Dateien. Manchmal können js-Dateien eine große Höhe haben, wenn mehrere Code-Schnipsel in einer einzigen Datei verwendet werden.

* 2 Testen von Modulen: Das Testen von Modulen ist ein wenig anders, da die Verwendung umfangreicher Manipulationen mit PHP zulässig ist. Hier sind einige Hinweise:

1. Community-unterstützte Module (CCK, Views usw.) haben Probleme in der Warteschlange auf drupal.org. Prüfen Sie, ob ein Problem vorliegt und ob möglicherweise ein Patch vorhanden ist, mit dem das Problem behoben werden kann.

2. Eigenes kundenspezifisch codiertes Modul, wenn Sie es codiert haben, müssen Sie es reparieren, richtig ?. Überprüfen Sie Ihre Codierung und die Verwendung der Funktionen anhand von api.drupal.org. Möglicherweise verwenden Sie eine Overkilling-Funktion anstelle eines Hakens.

3. Benutzerdefiniertes Internet-Shared-Code-Modul, wie in Schritt 2 beschrieben. Diesmal können Sie sich jedoch auch an den ursprünglichen Modulschreiber wenden und ihn über das Problem informieren.

4. Wenn es sich bei Ihrer Site um ein Upgrade handelt (D5 -> D6 -> D7), überprüfen Sie die Migrations- oder Upgrade-Skripts (normalerweise in der Datei module.install). Möglicherweise benötigen Sie einen zusätzlichen "Index" für die neue Tabellenkonfiguration, um die langsame SQL-Abfrage X zu beschleunigen .

5. Wenn Sie das Gefühl haben, eine Tunnelvision für das Problem zu haben, treten Sie für eine Weile aus und führen Sie eine andere Aktivität aus, die völlig unabhängig ist. Kommen Sie später wieder, um das Problem erneut zu untersuchen.

6. Wenn Sie das Problem auf einen Codeabschnitt pingen, sich aber keine Gedanken darüber machen können, wie das Problem behoben werden kann, erklären Sie einer Person, die keine Ahnung hat, wie sie programmieren soll oder wie Drupal funktioniert und arbeitet, was in diesem Abschnitt zu tun ist bereit zu überraschen.

Hinweis: Seien Sie nicht beunruhigt, wenn nach der Neuerstellung Ihrer Website alle Funktionen wie ein Zauber funktionieren, der zu den besten Funktionen von Computern gehört.

Stellen Sie sicher, dass Sie keine Module gelöscht haben, ohne sie zu deinstallieren. Dies führt zu einer Verzögerung, da Drupal versucht, die Dateien zu finden, diese jedoch nicht mehr vorhanden sind.

Löschen Sie Referenzen in der Variablentabelle, wenn die Module nicht mehr vorhanden sind.

Ein Web-APM wie newrelic ist das beste Tool, um Leistungsprobleme aufzuspüren. Ich hatte Sites, die ein oder zwei Codezeilen aufriefen, die Wackeleffekte hatten, unnötige Arrays zu seltsamen Zeiten geladen haben und andere Dinge taten, die ziemlich unsichtbar waren, bis wir sie mit einem APM aufgespürt hatten.

Jemand hat erwähnt, dass GoDaddy langsam sein wird. Viele Cloud-basierte Hosting-Unternehmen werden diese anfängliche Verzögerung auch haben, weil Dienste wie AWS sie haben. Es ist billiger, Server automatisch deklassieren zu lassen, und diese Server benötigen ein oder zwei Sekunden, um "aufgeweckt" zu werden.

Zum Beispiel hat Pagodabox 3-4 Sekunden für das erste Byte, bis der Server glücklich wach ist. Pagodabox hat in der Tat Geld verdient, um den Server wach zu halten. Sie können also extra bezahlen, um Ihre Site zu "caffienieren".

Ein CDN kann Ihnen auch weiterhelfen. Ihr Web- / DB-Server wird nicht mit zwischengespeicherten Seiten oder Bildern geladen. Ein gutes Tutorial finden Sie hier: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

Und ... WebPageTest macht mich glücklich. http://www.webpagetest.org/ Ladezeiten weltweit und mit verschiedenen Webbrowsern kostenlos vergleichen. Verwenden Sie diese Option, um reale Ergebnisse für alle Änderungen zu erhalten, die Sie vornehmen.

Das Problem könnte überall sein.

1. Stellen Sie sicher, dass Sie für kein Thema oder Modul den Debug-Modus aktiviert haben. In vielen Designs gibt es beispielsweise die Option, die Designregistrierung neu zu generieren.
2. Wenn Sie auf Shared Hosting wie Godaddy laufen, ist die erste Anforderung von 15 Sekunden normal.
3. Konvertieren Sie Ihre Website oder Startseite mit dem Drush CTools-Exportmodul in eine Codebasis . Dadurch wird jeglicher Datenbankaufruf beseitigt und Ihre Site wird vollständig von PHP ausgeführt.
4. Wenn Sie weiterhin Probleme haben, verwenden Sie die Entwicklereinstellungen, indem Sie query logund page timerOptionen unter aktivieren admin/config/development/devel. Sehen Sie, welche der beiden Methoden mehr Zeit benötigt, um die gesamte Seite zu generieren.
5. Starten Sie Ihren Server neu, wenn nichts funktioniert.
6. Im schlimmsten Fall installieren Sie XHProf, um zu sehen, wo etwas schief läuft.

So habe ich das Problem für meine Installation behoben. Es ist keine echte Lösung, da ich die genaue Ursache des Problems nicht finden konnte (falls es eine gibt), aber es ist eine gute Lösung

1) Aggregiertes CSS (Cache-Einstellungen). Dies reduzierte die Latenz um die Hälfte

2) Setzen Sie cron auf never (und führen Sie es extern aus) - Hinweis: Ich habe versucht, cron zu starten, während es bereits ausgeführt wird. Ich denke, es wurde versucht, Cron bei jedem Start zu starten, aber da dies fehlschlug, wurde auf der Cron-Seite nicht der letzte Versuch, sondern der letzte Erfolg erwähnt.

3) Richten Sie einen Cron-Job ein, der alle 30 Minuten die Homepage mit Lynx aufruft

All dies auf einem gemeinsam genutzten Hosting-Server. Es ist nicht optimal, aber es funktioniert

Ich würde vorschlagen, einen Front-End-Cache entsprechend dem Boost-Modul (vorausgesetzt, Sie verwenden Shared Hosting) oder Varnish zu verwenden. Dies funktioniert am besten, wenn Ihre Site-Zugriffe in erster Linie anonym sind und der Seiteninhalt größtenteils nicht dynamisch ist (dh die Seiten ändern sich nicht viel).

Diese Lösungen speichern die gerenderten Seiten beim ersten Zugriff und liefern dann den vorgerenderten HTML-Code, anstatt den vollständigen Drupal-Bootstrap-, Seitenerstellungs- und Theming-Prozess zu durchlaufen. Dies spart viel Zeit, insbesondere auf stark frequentierten Websites, aber auch auf Websites wie Ihnen Beschreiben Sie, welche "schlafen gehen" und zu lange dauern, um aufzuwachen.

Der einzige wirkliche Nachteil ist, dass Sie (zumindest für Boost) den Cache leeren müssen, wenn sich der Inhalt der Site ändert. Wenn Sie sicherstellen möchten, dass die Site vollständig mit dem aktuellen Inhalt zwischengespeichert ist, können Sie drush cc all ausführen und dann regelmäßig über cron die gesamte Site abrufen.