Lange Page-Ladezeiten bei Shared Hosting

Was für ein Webhosting ist das? Prestashop ist schon ein ordentlicher Brocken.

Mit Prestashop kenne ich mich absolut nicht aus, aber hast du bei Nextcloud die gängigen Cache- und PHP-Optimierungen vorgenommen? Da konnte ich bei mir eine deutliche Performance-Verbesserung feststellen. Ansonsten ist es hier wohl ein gängiges Problem, dass SQL-Anfragen durch die vom Webhosting gesonderten Server eine hohe Laufzeit haben.

Ich tippe eher auf I/O Probleme, open_basedir und den prinzipiell guten OPCache, aus dem die zahlreichen PHP-Dateien halt irgendwann auch mal wieder rausfliegen, wenn sie ewig nicht gebraucht werden. Weil unendlich groß ist der halt auch nicht, schon gar nicht im Shared Hosting. So dauert der erste Aufruf halt umso länger, je länger der letzte Aufruf her ist. Einfach mal einen Tag nicht aufrufen, dann sieht man, wie schnell PHP hier ohne OPCache wäre. Man könnte natürlich auch regelmäßig per cron einen Seitenzugriff machen . Bei Prestashop muss man nur mal die Suchmaschinen bemühen, da überbieten sich die Nutzer mit Empfehlungen der gängigsten Cache-Module.

Hallo, gibt es hier eine Lösung, ich habe mit Prestashop genau das selbe Problem. Der erste Aufruf in der Früh dauert teilweise über 30 Sekunden.

LG, Tom

Quote from carlfriedrich

ich habe auf meinem Shared Hosting bei netcup zwei Services laufen: Nextcloud und Prestashop. Bei beiden stelle ich immer wieder sehr lange Page-Ladezeiten fest, und zwar insbesondere, wenn ich die jeweilige Seite ein paar Stunden lang nicht aufgerufen habe. Beim zweiten Laden ist dann meist alles normal.

Es gibt ein Workaround, den ich seit einigen Monaten so selber erfolgreich auch auf meine Webseiten so anwende.

Wenn man zufälligerweise einen Server-Monitoring-Dienst, wie z.B. den vom Anbieter serverg****24.de verwendet, der auch in der Lage ist, auf der betroffenen Webseite nach einer bestimmten vorhandenen Textzeile im Header und auch auf der Webseite selber zu suchen, und dieser Dienst alle 5 Minuten nach dieser Textzeile sucht, ist dieses Problem beseitigt, da dieser Dienst die Webseite so aufsucht, wie es auch ein normaler Nutzer tun würde.

Quote from andreas.

Es gibt ein Workaround, den ich seit einigen Monaten so selber erfolgreich auch auf meine Webseiten so anwende.

Wenn man zufälligerweise einen Server-Monitoring-Dienst, wie z.B. den vom Anbieter serverg****24.de verwendet, der auch in der Lage ist, auf der betroffenen Webseite nach einer bestimmten vorhandenen Textzeile im Header und auch auf der Webseite selber zu suchen, und dieser Dienst alle 5 Minuten nach dieser Textzeile sucht, ist dieses Problem beseitigt, da dieser Dienst die Webseite so aufsucht, wie es auch ein normaler Nutzer tun würde.

Also ist der Workaround im Grunde, dass ein externer Dienst den Cache des Hostings warmhält?

Hmmm... könnte man dafür dann nicht einfach auch einen eigenen Cronjob direkt vom Webserver aus laufen lassen? Beispielsweise ein curl-Script?

Führt dann natürlich kein Javascript etc aus, aber reicht das schon? Anderenfalls ein Python-Script mit Scrapy, BeautifulSoup o.ä.

Aber dennoch unschön, dass ein solcher Workaround überhaupt nötig ist.

Quote from DerRené

Hmmm... könnte man dafür dann nicht einfach auch einen eigenen Cronjob direkt vom Webserver aus laufen lassen? Beispielsweise ein curl-Script?

Führt dann natürlich kein Javascript etc aus, aber reicht das schon? Anderenfalls ein Python-Script mit Scrapy, BeautifulSoup o.ä.

Aber dennoch unschön, dass ein solcher Workaround überhaupt nötig ist.

Javascript und sonstige Assets sind kein Problem. Der "Problemcache" ist eben der OPcache. Man kann förmlich zusehen, wie die Ladezeit immer länger wird, wenn einige Zeit kein Request stattfindet, der dafür sorgt, dass das verwendete PHP inklusive Framework wie Symfony etc geladen und interpretiert wird. Je länger kein Zugriff, desto mehr benötigte PHP-Skripte fliegen aus dem OPcache. Dann nehmen wir noch die trotz SSD nicht so besonders berühmte IO-Geschwindigkeit dazu, den Bremsfallschirm open_basedir, der dafür sorgt, dass der realpath cache disabled ist und schon wird das Laden des CMS/Shopsoftware/Nextcloud, bestehend aus ziemlich vielen Skripten, eine sehr laaaaangsame Angelegenheit.

Wie lange dauert es bis der Cache wieder leer ist? Dh bei einer Website die regelmäßig frequentiert wird fällt das dann gar nicht auf?

Quote from youbenick

Wie lange dauert es bis der Cache wieder leer ist? Dh bei einer Website die regelmäßig frequentiert wird fällt das dann gar nicht auf?

Nein, das fällt bei einer stark frequentierten Website überhaupt nicht auf. Je nachdem was sonst noch so auf den OPcache zugreift dauert es jedenfalls zumindest Stunden ohne Zugriff, bevor der Seitenaufbau dadurch auffallend verzögert wird. Nach einem Tag oder mehr sind es dann aber je nach Webhosting Verzögerungen bis gerade in den hier genannten Zeitbereich von 30 Sekunden. Auch das kann natürlich varrieren, je nachdem wie lange deine konkrete Anwendung eben benötigt, wenn sie praktisch von Null auf geladen werden muss, also wenn keine nennenswerten Reste mehr davon im Cache sind. Je fetter die Anwandung, desto länger kann es dauern.

Quote from carlfriedrich

ich habe auf meinem Shared Hosting bei netcup zwei Services laufen: Nextcloud und Prestashop. Bei beiden stelle ich immer wieder sehr lange Page-Ladezeiten fest, und zwar insbesondere, wenn ich die jeweilige Seite ein paar Stunden lang nicht aufgerufen habe. Beim zweiten Laden ist dann meist alles normal.

Beispiel: Heute morgen habe ich mein Prestashop-Backend aufgerufen. Es hat geschlagene 50 Sekunden gedauert, bis die Login-Page angezeigt wurde, und weitere 18 Sekunden vom Eingeben der Login-Daten bis zum Backend. Beim Klick auf "Bestellungen" musste ich noch einmal 42 Sekunden warten, bis die Liste meiner Bestellungen zu sehen war.

Wenn ich mich danach auslogge und alles noch einmal genau so mache, dann erscheint jede der Seiten in 1-2 Sekunden.

Wenn Einnahmen über Prestashop laufen, kann ich dringend einen (managed) vServer empfehlen. Ein Root-Server ist wahrscheinlich zu viel. Selbst mit Online-Shop, Nextcloud und diversen Diensten dümpelt mein Epic-2Core-Server mit 2-3% Auslastung vor sich her Ich war vorher bei einem anderen Anbieter, dort hat ein leeres Woocommerce auch bis zu 10 Sekunden gebraucht.

Auch Ladezeiten von über 1 Sekunden (HTML) sind nachteilig, da Google diese kaum besuchen und indexieren wird.

Nextcloud lädt bei mir im ms-Bereich, die reine HTML-Seite von Woocommerce lädt in ca. 300-500ms (Gesamtübersicht ,100 Produkte), einzelne Produktseiten beim zweiten Aufruf dauern ca. 100ms, beim ersten Mal ca. 500ms. Presta selbst verwende ich nicht.

Externe Datenbanken machen Seiten jedoch extrem langsam. Ein Dashboard für die Verwaltung von externen Forschungsdaten (Azure, MS-SQL) lädt auch 2,5 Sekunden, was ich schon als nervig empfinde Da lässt sich nicht viel machen, außer SQL-Code optimieren (Potential gibt es, aber ich glaube nicht, dass mein Arbeitgeber mich dafür bezahlen würde. Hauptsache es läuft ).

Cronjobs bringen nicht viel, meine persönliche Erfahrung. Insbesondere da der Arbeitsspeicher pro Kunde aus technischen Gründen limitiert wird, können meist nicht alle Produktseiten im RAM gespeichert bleiben, erst recht keine komplettes Backend. (zumindest meine Erfahrung beim vorherigen Anbieter, habe mit Sharedhosting bei Netcup keine Erfahrung).

Quote from condor

Wenn Einnahmen über Prestashop laufen, kann ich dringend einen (managed) vServer empfehlen. Ein Root-Server ist wahrscheinlich zu viel. Selbst mit Online-Shop, Nextcloud und diversen Diensten dümpelt mein Epic-2Core-Server mit 2-3% Auslastung vor sich her Ich war vorher bei einem anderen Anbieter, dort hat ein leeres Woocommerce auch bis zu 10 Sekunden gebraucht.

Auch Ladezeiten von über 1 Sekunden (HTML) sind nachteilig, da Google diese kaum besuchen und indexieren wird.

Nextcloud lädt bei mir im ms-Bereich, die reine HTML-Seite von Woocommerce lädt in ca. 300-500ms (Gesamtübersicht ,100 Produkte), einzelne Produktseiten beim zweiten Aufruf dauern ca. 100ms, beim ersten Mal ca. 500ms. Presta selbst verwende ich nicht.

Externe Datenbanken machen Seiten jedoch extrem langsam. Ein Dashboard für die Verwaltung von externen Forschungsdaten (Azure, MS-SQL) lädt auch 2,5 Sekunden, was ich schon als nervig empfinde Da lässt sich nicht viel machen, außer SQL-Code optimieren (Potential gibt es, aber ich glaube nicht, dass mein Arbeitgeber mich dafür bezahlen würde. Hauptsache es läuft ).

Cronjobs bringen nicht viel, meine persönliche Erfahrung. Insbesondere da der Arbeitsspeicher pro Kunde aus technischen Gründen limitiert wird, können meist nicht alle Produktseiten im RAM gespeichert bleiben, erst recht keine komplettes Backend. (zumindest meine Erfahrung beim vorherigen Anbieter, habe mit Sharedhosting bei Netcup keine Erfahrung).

Display More

Die Seiten müssen ja nicht im RAM gespeichert werden, Festplatte tuts dafür eigentlich auch. Einen Cache wird ja Wordpress hoffentlich zustande bringen. Und falls nicht, wird halt das Shopsystem notgedrungen einen mitbringen (müssen!).

Quote from tab

Die Seiten müssen ja nicht im RAM gespeichert werden, Festplatte tuts dafür eigentlich auch. Einen Cache wird ja Wordpress hoffentlich zustande bringen. Und falls nicht, wird halt das Shopsystem notgedrungen einen mitbringen (müssen!).

Das mag bei SharedHosting stimmen, meines Wissens werden Dateien von nginx/apache gerne im RAM gelagert, sofern dieser nicht voll ist. Bei einem Root-Server wird dies häufiger der Fall sein als bei Sharedhosting.

Aber letztlich kann ich für Online-Shops keine Sharedhosting empfehlen. Wenn man seine monatlichen Einnahmen im vierstelligen Bereich online umsetzt, sind die paar Euro es wert. Teilweise reicht da ein einziger Kunde mehr im Monat, um diese Zusatzkosten auszugleichen. Und wenn die Produkte besser von Google gefunden werden, dann war es das Geld wert.

Würde der gleiche Effekt beim Webhosting 2000 Produkt auftreten? Hier sind 4GB Ram garantiert, würde das helfen oder wäre hier gleiches zu beobachten?

Quote from youbenick

Würde der gleiche Effekt beim Webhosting 2000 Produkt auftreten? Hier sind 4GB Ram garantiert, würde das helfen oder wäre hier gleiches zu beobachten?

Die Frage ist, wo die 4GB garantiert werden. In der Regel würde man (ich) davon ausgehen, dass das gemietete Konto diesen Speicherbereich für eigene Scripts/Prozesse allokieren kann. Sofern der Webserver aber nicht unter vollständiger eigener Kontrolle läuft (wie bei einem VPS/RS, also ein oder mehrere individuelle Webserver-Instanzen pro Kunde), sondern nur vom Host aus auf den gemieteten Plattenplatz/RAM-Bereich zugreift, stellt sich die Frage, wie der Cache des Webservers dimensioniert ist, welcher immer zuerst kontaktiert und typischerweise in Abhängigkeit von Zugriffszeitpunkten/-häufigkeiten – aus Sicht der Webserver-Instanz, d.h. bezogen auf alle bedienten Kunden – befüllt/geleert wird.

Die Produktbeschreibungen enthalten meines Wissens keinerlei Aussagen über eine Cache-Garantie (=zusätzlich benötigter Speicher, insbesondere aber angepasstes Cache-Verhalten, sofern sich mehrere Kunden den-/dieselben Webserver teilen).

Quote from youbenick

Würde der gleiche Effekt beim Webhosting 2000 Produkt auftreten? Hier sind 4GB Ram garantiert, würde das helfen oder wäre hier gleiches zu beobachten?

Es tritt auch beim Webhosting 8000 auf. Ich habe jetzt keine Vergleichstests dafür gefahren, aber auch beim Webhosting 8000 sind so lange Wartezeiten möglich.

Quote from carlfriedrich

Aber um das trotzdem nochmal kurz durchzudenken: Was wäre denn eure konkrete Empfehlung für einen PrestaShop mit nur wenig Traffic im Monat? Reicht da der günstigste Tarif (VPS 200 G8) mit 1 Core und 2 GB RAM? Die Caching-Probleme wären damit gegenüber dem Shared Hosting ja zumindest weg, oder? Und wie hoch ist eurer Erfahrung nach der Wartungsaufwand mit einem vServer?

Wenn der Shop im Webhosting zu langsam ist, wird auch ein VPS 200 hier nicht reichen. Hier würde es vermutlich eher ein Server aus der RS Reihe werden müssen (ab RS 1000 G9).

Der Aufwand lässt sich schwer abschätzen. Hier kommt es ganz darauf an wieviel Vorwissen schon vorhanden ist. Für den einen ist das ein Kinderspiel, weil er das sowieso ständig macht, für den anderen ein Mammut-Projekt. Wenn man in der Serveradministration noch wenig bis gar keine Ahnung hat bzw. das vorher noch nie gemacht hat, wird es recht aufwändig. Da würde ich ehrlich gesagt auch nicht mit einem produktiven Shop anfangen. Da gibt es zu viele Stolpersteine. Auch juristisch kann das sehr schnell problematisch werden, falls etwas schief läuft und Kundendaten abfließen.

Da sich die Frage überhaupt stellt, befürchte ich, dass bisher wenig Vorkenntnisse vorhanden sind. Falls es aber doch ein eigener vServer werden soll, würde ich folgende Möglichkeiten vorschlagen:

1. Erarbeite dir das nötige Wissen in einer lokalen Testumgebung (z.B. mit Hilfe von VirtualBox). Hier kann man ohne Bedenken einfach mal verschiedene Server aufsetzen und das Szenario durchspielen. Hier wird man dann sehr schnell merken, ob man das mit einem richtigen Server im Internet so durchziehen möchte.

2. Suche dir jemanden (vielleicht im Bekanntenkreis), der für dich das macht oder dich dabei unterstützt.

Wenn es um das reine Wissen geht, können wir hier im Forum natürlich auch gerne unterstützen. Mach das aber bitte unbedingt erst einmal lokal in einer Testumgebung. Das kostet dich nichts - außer etwas Zeit.