Da habe ich zu langsam geschrieben 
Wenn es dann dort immer noch langsam sein sollte, weißt Du zumindest dass es am Shop liegt und nicht am Hosting
Dafür gibt es dann Profiling-Tools (z.B. Tideways), mit denen man den Flaschenhals in PHP und/oder MySQL finden kann. Bei einigen Hostern ist das auch schon integriert, so daß man es leicht starten kann. Spätestens, wenn man die Profiling-Ergebnisse befolgt, sollte sich eine spürbare Verbesserung der Ladezeiten ergeben.
Timme Hosting - schnelles nginx-Hosting
Hallo Malakiras,
hat sich dein Problem mit den langen Ladezeiten erledigt und wenn ja, wie?
Wir hatten (hoffe ich…) nämlich mit einer ähnlichen Konfiguration wie Du ein identisches Problem (Mittwald-Server L 9.0 etc., Shopware-Installation plus DashOne V2 - Template): Ladezeiten um die 10 Sekunden plus / minus 1 Sekunde! Mittwald konnte nichts finden, gab nur den Hinweis, dass dort etwas mit CSS und Java nicht stimmt.
Nach einigem hin und her ergab sich folgendes:
Bei uns waren schlicht und ergreifend Einstellungen im Bereich des Theme Managers von Theme Entwickler falsch gesetzt:
Im Backend unter Theme Manager -> Einstellungen die Compiler Funktion wie folgt setzen: CSS und JavaSkript komprimieren = Haken setzen, Compiler Caching deaktivieren = KEIN Haken setzen (muss also aktiv sein!).
Cache nochmal kplt. löschen und Themes neu kompilieren (weiß nicht, ob das zwingend muss) und jetzt sind die Ladezeiten bei max. 2 - 3 Sekunden!
Viele Grüße,
Thorsten
@bfp26789 das klingt aber immer noch nicht gerade gut. Bei uns sind die Ladezeiten zwischen 150 - 300 ms und selbst das ist nicht gut genug ! (ich wüsste noch genug Stellen wo wir die Performance noch optimieren könnten)
Hallo Malakiras,
hat sich dein Problem mit den langen Ladezeiten erledigt und wenn ja, wie?
Wir hatten (hoffe ich…) nämlich mit einer ähnlichen Konfiguration wie Du ein identisches Problem (Mittwald-Server L 9.0 etc., Shopware-Installation plus DashOne V2 - Template): Ladezeiten um die 10 Sekunden plus / minus 1 Sekunde! Mittwald konnte nichts finden, gab nur den Hinweis, dass dort etwas mit CSS und Java nicht stimmt.
Nach einigem hin und her ergab sich folgendes:
Bei uns waren schlicht und ergreifend Einstellungen im Bereich des Theme Managers von Theme Entwickler falsch gesetzt:
Im Backend unter Theme Manager -> Einstellungen die Compiler Funktion wie folgt setzen: CSS und JavaSkript komprimieren = Haken setzen, Compiler Caching deaktivieren = KEIN Haken setzen (muss also aktiv sein!).
Cache nochmal kplt. löschen und Themes neu kompilieren (weiß nicht, ob das zwingend muss) und jetzt sind die Ladezeiten bei max. 2 - 3 Sekunden!
Viele Grüße,
Thorsten
Hallo Thorsten, wir haben wirklich alles ausprobiert, auch das was du genannt hattest. Es hat alles nichts genutzt. Das Ende vom Lied war dann, dass wir unseren Hosting Partner gewechselt haben.
Seitdem wir bei AIXPRO sind, läuft alles super! Ladezeiten sind sehr gut, Support ist super und der Preis ist einfach top!
Beste Grüße
Cache nochmal kplt. löschen und Themes neu kompilieren (weiß nicht, ob das zwingend muss) und jetzt sind die Ladezeiten bei max. 2 - 3 Sekunden!
Viele Grüße,
Thorsten
Ist das die Gesamtladezeit oder die Time to first Byte (TTFB), über die Du redest? Eine TTFB von 2 - 3 Sekunden wäre katastrophal - bei gut optimierten Shops sind Werte um 40 ms kein Problem. Die Gesamtladezeit hängt natürlich davon ab, wieviele Ressourcen (Bilder, JavaScript, CSS, Fonts, etc.) geladen werden, wie groß sie sind, ob sie von externen Servern kommen, etc. Für die Usererfahrung ist natürlich auch noch ausschlaggebend, ob Ressourcen unbemerkt nachgeladen werden oder ob der User warten muß, bis alles geladen ist, damit sich die Seite aufbaut.
Timme Hosting - schnelles nginx-Hosting
1 „Gefällt mir“
Hallo malakiras,
welche PHP bzw. MySQL Version verwendest du auf deinem Hosting?
Deine Startseite hat einige Elemente der Einkaufswelten, richtig?
VG
md_dm
Ich war gerade mal drauf. Für mich sieht das völlig normal aus. Hat nur ein paar Sekunden gebraucht. Bei dem riesigen Code eigentlich gut.
Yepp, Malikaras hat auch den Hoster komplett gewechselt. Ich selbst bin bei Mittwald. Allerdings mit einem dedizierten Server… Der vServer hatte genau das gleiche Problem wie Malikaras beschrieben hat. Da ich eigentlich mit Mittwald zufrieden bin (Backend, Service, etc.) habe ich auf den dedizierten Server gewechselt. Ist natürlich weitaus teurer als die Pakete von Aixpro… Da muss man sich wirklich überlegen, ob man bei der Performance auch dorthin wechselt.
Wir waren auch mal bei Mittwald, genau 3 Tage 
den so inkompetente Mitarbeiter wie dort, habe ich noch nirgends erlebt. Die hatten es nicht mal geschaft den Testserver den Sie Neukunden mit SW anbieten, zum laufen zu kriegen. Was aber noch schlimmer war, die wussten selber nicht woran es lag. 
Würde ich hier den Support Verlauf posten, würden warscheinlich viele in Tränen ausbrechen. Nach 3 Tagen hatten wir dann die Schnauze voll, und sind zu AIXPRO gewechselt.
Bei AIXPRO sind wir nun fast ein Jahr und waren da auch sehr zufrieden, leider aber gibt es auch da in letzter Zeit ziemliche Performance Probleme. 
Grüße
Performance Probleme bei 0,5 Sekunden Seitenladezeit auf Shared Hosting ?
Performance Probleme bei 0,5 Sekunden Seitenladezeit auf Shared Hosting ?
Hallo,
das mag ja bei manchen Servern zutreffen, aber nicht nur wir hatten gravierende Probleme https://forum.shopware.com/discussion/41237/probleme-bei-aixpro-suchen-dringend-einen-neuen-hoster#latest 
Ok, laut Support Ticked habt Ihr ja den Verursacher mit seinem Script gesperrt, aber aus meiner Sicht habt Ihr euch da ganz schön lange Zeit gelassen, gut 2 Wochen hatten wir nicht nur Ausfälle sondern auch beschwerden weil die Seite nicht erreichbar war. Der Server läuft zwar nun besser, aber leider nicht mehr so wie wir es mal bei euch gewohnt waren.
Grüße
Wie @hth in dem anderen Beitrag bereits erwähnte und bereits mitgeteilt, lassen sich Systemressourcen bei Shared Hosting nicht fest zuweisen - d.h. es besteht immer ein Risiko, dass ein anderer Webspace oder Shop das System auslastet. Wir sind jedoch bei entsprechenden Vorfällen gezwungen, dem Verursacher eine angemessene Frist vor einer Sperrung einzuräumen. Dem entsprechenden User ist i.d.R. gar nicht bewusst, dass z.B. Shared Hosting für einen größeren Shop vollkommen unterdimensioniert ist oder welche System-Ressourcen ein Plugin, Cronjob oder Skript verursachen. Derjenige wäre jedoch auch nicht glücklich, wenn binnen Minuten der Webspace gesperrt wird - wir denken, nachvollziehbar.
Im beschriebenen Fall wurde der Skript deaktiviert - jedoch alsdann mehrfach - trotz Hinweise - seitens des Verursachers wieder aktiviert, was letztendlich zur Sperrung führte.
Eine genauere Erklärung zu den jeweiligen Hosting-Varianten mit allen Vor- und Nachteilen sind im Web zu finden, so z.B. unter
https://www.prestashop.com/blog/de/e-commerce-101-die-wahl-der-richtigen-hosting-loesung-fuer-ihren-online-shop/
Die richtige Server-Lösung für Ihren Webshop finden - Definitionen & Begriffe - PHP-Shops: Erfolgreich Online-Shops führen, Blog mit Tipps und Tricks
Ist durchgängig gleichbleibende Performance unabdingbar, sind Shared Hosting und einfache vServer die falsche Wahl.
Wie bereits erwähnt, hat Deine Seite durchgängig eine für Shared Hosting und in Hinblick auf die großen Banner schnelle Ladezeit von ~ 0,5 Sekunden. Darüber hinaus spielen auch andere Faktoren eine Rolle - siehe z.B. zuletzt die DDoS Attacke auf DynDNS, die Paypal und Co. zum erliegen gebracht hat, was letztlich zu 503 Fehlern im Checkout führte: https://forum.shopware.com/discussion/comment/176077/#Comment_176077
Wie @hth in dem anderen Beitrag bereits erwähnte und bereits mitgeteilt, lassen sich Systemressourcen bei Shared Hosting nicht fest zuweisen - d.h. es besteht immer ein Risiko, dass ein anderer Webspace oder Shop das System auslastet. Wir sind jedoch bei entsprechenden Vorfällen gezwungen, dem Verursacher eine angemessene Frist vor einer Sperrung einzuräumen. Dem entsprechenden User ist i.d.R. gar nicht bewusst, dass z.B. Shared Hosting für einen größeren Shop vollkommen unterdimensioniert ist oder welche System-Ressourcen ein Plugin, Cronjob oder Skript verursachen. Derjenige wäre jedoch auch nicht glücklich, wenn binnen Minuten der Webspace gesperrt wird - wir denken, nachvollziehbar.
Im beschriebenen Fall wurde der Skript deaktiviert - jedoch alsdann mehrfach - trotz Hinweise - seitens des Verursachers wieder aktiviert, was letztendlich zur Sperrung führte.
Eine genauere Erklärung zu den jeweiligen Hosting-Varianten mit allen Vor- und Nachteilen sind im Web zu finden, so z.B. unter
http://t3n.de/news/hosting-ratgeber-t3n-580128/
https://www.prestashop.com/blog/de/e-commerce-101-die-wahl-der-richtigen-hosting-loesung-fuer-ihren-online-shop/
http://www.php-shops.de/begriffserklaerungen-definitionen/technik/hosting-online-shop-server/Ist durchgängig gleichbleibende Performance unabdingbar, sind Shared Hosting und einfache vServer die falsche Wahl.
Wie bereits erwähnt, hat Deine Seite durchgängig eine für Shared Hosting und in Hinblick auf die großen Banner schnelle Ladezeit von ~ 0,5 Sekunden. Darüber hinaus spielen auch andere Faktoren eine Rolle - siehe z.B. zuletzt die DDoS Attacke auf DynDNS, die Paypal und Co. zum erliegen gebracht hat, was letztlich zu 503 Fehlern im Checkout führte: https://forum.shopware.com/discussion/comment/176077/#Comment_176077
Hallo,
ich glaube wir müssen hier nicht noch einmal alles öffentlich lang und breit treten wo wir uns doch vor kurzen schon mal darüber unterhalten haben. Wir sind keine Anfänger, hosten seit ca. 11 Jahren bei hetzner, plus eigener Root mit mehreren Seiten. Haben in den letzten 15 Jahren in denen wir Seiten hosten einiges an Erfahrung gesammelt.
Das es hin wieder zu Problemen kommen kann ist normal, aber nicht MEHRMALS jeden TAG, den das sollte auch bei einen Hosting nicht passieren. Es lief ja lange Zeit sehr gut, aber in letzter Zeit haben wir leider des öfteren Performance Probleme, und das ist leider nun mal fakt. Da wir nun schon lange unseren Shop bei euch hosten, und wir immer zufrieden waren, sind wir nicht gleich zu einen anderen Anbieter gewechselt, sondern auf Besserung gehofft.
Seit der Sperre läuft der Server wieder um einiges besser…schauen wir mal.
Grüße
Hmmm, kann ich so über Mittwald nicht behaupten. Es gab vor 2 Jahren noch auf meinem damaligen vServer eine DDOS Attacke, die den Server bzw. kompletten Shop zum Versagen gebracht hat. Mittwald hat sich sogar mit einem Karton Wein entschuldigt. Das hatte ich so noch nie erlebt und auch die Leute am Telefon sind sehr nett und hilfsbereit. Man kann natürlich auch mal Pech haben und einen “Neuen” Mitarbeiter erwischen. Ansonsten hatte ich stets das Gefühl, dass Sie wissen, was Sie tun. Bin ja auch selbst vom Fach…