Jump to content
  • 0

[GELÖST] Zeitweise miserable Performance


henner2605

Question

Hallo,

 

ich hoffe hier kann mir jemand helfen. Vorab die Eckdaten meines Shops:

 

Provider: all-inkl.com, Businesspaket

PS Version: 1.6.1.6

Serverdaten Linux #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64

Version der Server-Software Apache

PHP-Version 5.5.38-nmm3

Speichergrenze 512M

max_execution_time 30

MySQL-Version 5.7.15-nmm5-log

MySQL-Engine InnoDB

MySQL driver: DbPDO

Aktuell verwendetes Template: default-bootstrap

Installierte Zusatzmodule: Bigfooter, Invoice payment, order edit, überpfrüfte Nutzerregistrierung deluxe, Onlineshop mit speziellen Zugang, Custom fields, private CMS-Seiten.

Anpassungen: Social Media Module deaktiviert, Übersetzungen angepasst

Artikelanzahl: ca. 940

Registrierte Kunden 140 (die einzigen die überhaupt Zugriff haben)

 

Der Shop ist ausschliesslich für registrierte Kunden nutzbar, also Wiederverkäufer. Von daher die geringe Kundenanzahl.

 

Mein Problem ist, das mein Shop zeitweise nur noch sehr langsam Seiten aufbaut, bzw. teilweise auch gar nicht mehr und ich dann eine Fehler 500 Meldung erhalte. Zeitweise bedeutet es geschieht eben nur manchmal für ca. eine Stunde und danach ist wieder gut, der Shop rennt.

 

Den Cache habe ich nun bereits mehrfach geleert und auch verschiedene Einstellungen probiert - keine Abhilfe.

Habe verschiedne Tabellen (Connections etc.) der DB gellert - keine Abhilfe.

Habe Teile der Statistiken deaktiviert - keine Abhilfe.

 

Ich habe nun mehrfach Kontakt mit meinem Provider gehabt. Beim ersten mal wurden meine Webseiten auf einen neuen Server umgezogen. Bei der 2. Reklamation wurden die Dienste des Servers neu gestartet.

 

Das alles hat keine Abhilfe gebracht. Man sagt mir nun es würde an dem Script liegen.
So ganz glauben mag ich es nicht, da es sicher unzählige gut funktionierende Shops gibt und der Fehler ja nur sporadisch auftritt.

 

All-inkl.com hat mir nun zwei Logfiles auf den Server gelegt, welche diese langsamen Seitenaufbauten aufgezeichnet haben.

Allerdings reichen meine Kenntnisse bei weitem nicht um daraus schlau zu werden. Ich habe sie angehängt.

 

Und genau deswegen schreibe ich hier. Kann mir jemand helfen?

 

lg

 

Hendrik

 

Edit: Serverdaten ergänzt

php-fpm_slow.txt

slowqueries.txt

Edited by henner2605 (see edit history)
Link to comment
Share on other sites

24 answers to this question

Recommended Posts

  • 0

Im Prinzip nicht.

Mein privater Webspace liegt ebenfalls bei all-inkl.com.

Und wenn, müsste ich ja irgendwie einen Server aufsetzen (was ja glaub unter Windows geht) der doch die exakt gleichen Einstellungen hat, oder?

Und auch dafür genügen meine Kenntnisse nicht.

Bin eher so der Anwender und passe nur Sachen sehr vorsichtig an, weil ich an sich keinen Plan hab.

Edited by henner2605 (see edit history)
Link to comment
Share on other sites

  • 0

Was mir auffällt, ist die geringe max_execution_time von 30 Sekunden, das ist eines "Business"-Pakets unwürdig, wenn da nicht mehr geht, würde ich den Provider wechseln. Generell scheint mir die Unregelmäßigkeit der Geschwindigkeit für Probleme beim Provider zu sprechen und nicht für ein Problem mit deiner Prestashop-Installation.

Link to comment
Share on other sites

  • 0

Erst mal Danke für Eure Antworten :-)

 

Momentan sagt all-inkl.com es liegt am Script. rictools, und da schliesse ich mich der Meinung an, sagt es liegt am Provider.

 

Hier mal noch eine Antwort von all-inkl.com zum Problem:

 

 

Ich habe den Server soeben einmal geprüft und musste feststellen, dass die einzigen Zugriffe auf dem Server auf Ihre Domain abzielten. Folgende POST-Abfragen waren in großer Menge in den Apachestatus zu sehen:

doeka.info:80/suche?rand=1505724857935
doeka.info:80/suche?rand=1505724856856
doeka.info:80/suche?rand=1505724857319

 

 

In Ihrem Fall laufen die einzelnen Aufrufe auf Ihre Domain doeka.info etliche Sekunden.

Durch die lange Laufzeit belegen diese Aufrufe die zur Verfügung stehenden PHP-FPM-Slots, somit sind keine weiteren Aufrufe auf die Domain möglich. In der Folge stauen sich die Anfragen auf und der Server überlastet.

Die PHP-FPM-Slots sind pro Account limitiert. Wenn es mehrere oft frequentierte Domains im Account gibt, sollten diese daher am besten jeweils in einen eigenen Unteraccount verlagert werden

Mit den o.g. Daten (140 Kunden, 930 Artikel) sollen übermäßig viele Anfragen (die einzigen Zugriffe auf den Server) an den Server geschickt worden sein? Mal ne blöde Frage, wie viele Anfragen verkraftet denn so ein Server por Sekunde oder auch Minute? Wie hoch ist die Wahrscheinlichkeit, dass meine 140 Kunden so viele Anfragen relativ gleichzeitig absenden? Ich denke wenn mal 10 Kunden gleichzeitig auf den Shop zugreifen ist es verdammt viel. Gesehen habe ich eine solch hohe Anzahl im Backend noch nie, in der Übersicht - Online Besucher der letzten 30 Minuten.

 

Besonders ärgerlich ist ja, egal was ich wo ändere, ich kann niemals sagen ob es Abhilfe gebracht oder nicht, da ja die Probleme nur temporär auftauchen.

 

Die Domain habe ich bereits von Anfang an in einem eigenem Unteraccount.

 

Die max_execution_time, wieviel habt Ihr denn und bei welchem Provider?

 

Provider würde ich nur extrem ungern wechseln, weil noch mehr Domains und auch der gesamte Mailverkehr drüber läuft, das haben wir noch nicht zentral im eigenen Haus - nächstes Jahr vielleicht. Und ansonsten bin ich ja auch mit all-inkl.com nicht unzufrieden.

Link to comment
Share on other sites

  • 0

Ich habe gerade mal die drei Seiten hier getestet, Eure Shops und meinen. Aktuell belege ich einen guten zweiten Platz beim Seitenaufbau :-)

 

Um etwas weiter zu testen lege ich nächste Woche mal eine Kopie des Shops auf meinen privaten Webspace.

Da ich wahrscheinlich selbst die meissten Zugriffe auf den Server generiere, klicke ich eben langsamer um die Schritte nachvollziehen zu können.

 

Wenn dann die Kopie schneller reagiert, sollte es ja am aktuellen Server liegen, richtig? Oder sehe ich das falsch?

Link to comment
Share on other sites

  • 0

Ich würde das Suchfeld für nicht eingeloggte Besucher deaktivieren, hat ja sowieso keine Funktion. Die Suche kann durchaus von Bots ausgelöst worden sein.

 

Auf der Website von all-inkl. finde ich keine Info über die PHP-Beschränkungen, ich würde die max_execution_time mal ansprechen, da müßte bei diesem Tarif deutlich mehr drin sein (vielleicht mußt du aber auch nur die php.info entsprechend konfigurieren).

Link to comment
Share on other sites

  • 0

Suchfeld deaktiviert, sah auch nicht schön aus und war wenig sinnvoll, gebe ich zu :-)

Bots füllen Felder aus?

 

Lt. Logs generiere ich mit Abstand die meissten Anfragen - die zielen nämlich aufs Backend. Google, Bing & Co. sehe ich nur 11 Anfragen (lfd. September)

In der Stundenstatistik habe ich ein paar Einträge mit mit 4000 - 7000 Anfragen - nehme an, das sind die die zum Versagen führen. Frage ist, wie habe ich die generiert. So schnell kann ich nicht klicken.

Link to comment
Share on other sites

  • 0

 

max_execution_time integer

Legt die maximale Zeit in Sekunden fest, die ein Skript laufen darf, bevor der Parser die Ausführung stoppt. Diese Einstellung hilft zu verhindern, dass schlampig geschriebene Skripte Ihren Server lahmlegen. Der Standardwert für diese Einstellung ist 30 Sekunden. Wird PHP von der Kommandozeile ausgeführt so ist der Vorgabewert 0.

 

Quelle: php.net

 

Ich kann mir nicht wirklich vorstellen, das all-inkl daran was ändern wird.

Link to comment
Share on other sites

  • 0

1. Ist die Shop Domain doeka.info ? Ich frage, weil ich im Getümmel dieses Threads etwas unsicher bin und diese Info auch so nicht im Eingangpost steht.

Wenn ja: Man kommt ja momentan nur zu Login - Seite. Kann ja sein, dass das so gewollt ist. Mich schreckt es ab und testen kann man so halt nicht, ohne ein Konto anzulegen.

 

2. Die Datenbank-Logs zeigen schon ein wenig gutes Bild. Da hat es massenhaft Queries mit Antwortzeiten jenseits von gut und böse. Bist Du sicher, dass Du alle Indizes in der DB hast, die dort sein müssen ?

 

3. Was mich in den Logs stutzig macht: Da werden offenbar die Smarty Caches in der DB gespeichert ??? Würde ich ganz schnell mal im Backoffice => Erweitert => Leistung ändern auf Filesystem. Hier ein Beispiel eines solchen DB-Statements:

DELETE FROM mw36u_smarty_cache WHERE name = "2985093c63bcf92c58461a70ed8cc955c050c3a2" AND (cache_id  = "blocksearch-top|15|15|1" OR cache_id LIKE "blocksearch-top|15|15|1|%");

4. PS 1.6. ist eigentlich sehr performant, vor allem im Vergleich zu 1.5. Aber meine ewige Aussage: Nicht wenige Drittmodule sind in Sachen Performance leider nicht so gut. Wenn es nach wie vor so langsam läuft, würde ich erstmal alle Drittmodule auf einen Schlag testhalber deinstallieren und nochmal testen. Ist die Antwortzeit dann besser, kann man eingrenzen, an welchem Modul es liegt.

Edited by Scully (see edit history)
Link to comment
Share on other sites

  • 0

Der Shop soll halt nur für bestehende Großhandelskunden sein und offenbar auch keine neuen Kunden werben.

 

Eine max_execution_time von 30 sec ist heute das absolute Minimum bei 1 Euro-Hostingpaketen, bei 1&1 gibt es nichts mehr unter 60 sec. Vor zwei, drei Jahren war das allerdings noch anders, deshalb sind die Werte bei älteren Verträgen mitunter deutlich niedriger als bei aktuellen Verträgen.

 

Ach ja, und natürlich füllen Bots auch Formulare aus, sie posten Putin-freundliche Beiträge bei Facebook, verbreiten Spam in Foren oder chatten mit liebeshungrigen Männern, die noch nicht einmal merken, daß sie sich mit einem Computerprogramm unterhalten ...

  • Thanks 1
Link to comment
Share on other sites

  • 0

 

Ist die Shop Domain doeka.info ?

Ja, das ist korrekt.

Der Shop ist quasi ein Katalog und neue Bestellmöglichkeit für unsere bestehenden Kunden. Neukundengewinnung ist damit nicht gewünscht, von daher auch die entsprechenden Module zur Registrierung/Sperrung.

 

 

Bist Du sicher, dass Du alle Indizes in der DB hast, die dort sein müssen

Die Frage verstehe ich leider nicht, fehlt mir Fachwissen. Ich habe aber händisch an der DB nichts geändert.

Habe verschiedne Tabellen (Connections etc.) der DB geleert - keine Abhilfe.

 

 

Was mich in den Logs stutzig macht: Da werden offenbar die Smarty Caches in der DB gespeichert ???

Das habe ich wohl mal umgestellt um verschiedene Einstellungen des Cache zu testen. Habs wieder rückgängig gemacht. Danke für den Hinweis.

 

 

PS 1.6. ist eigentlich sehr performant

Ist sie ja auch, bei mir macht die Version nur ab und an mal ne Pause, ist ja kein dauerhafter Zustand - genau das ist ja das fiese daran.

 

 

Ach ja, und natürlich füllen Bots auch Formulare aus, ...chatten mit liebeshungrigen Männern, die noch nicht einmal merken, daß sie sich mit einem Computerprogramm unterhalten ...

Verdammt, das sind gar keine echten Frauen? :wub: (Sorry, ich musste das kommentieren :) )

 

Mein Vorhaben fürs Wochende die Shopinstallation auf einen anderen Server zu kopieren habe ich zeitlich nicht geschafft.

Allerdings habe ich noch einige Module deaktiviert die ich nicht brauche, insbesondere Statistiken.

 

 

Nicht wenige Drittmodule sind in Sachen Performance leider nicht so gut. Wenn es nach wie vor so langsam läuft, würde ich erstmal alle Drittmodule auf einen Schlag testhalber deinstallieren und nochmal testen. Ist die Antwortzeit dann besser, kann man eingrenzen, an welchem Modul es liegt.

Die installierten Zusatzmodule laufen alle von Anfang an, die Probleme ergaben sich erst wesentlich später.

Der Shop ist "offiziell" seit Juni 2016, die Probleme jetzt seit ca. 3-4 Monaten.

Das einzige Modul welches nicht wirklich funktioniert bzw. auch erst später installiert wurde, ist "order edit" von Silbersaiten, das spinnt tatsächlich. Da komme ich nicht immer in die Editfunktion der Bestellung, sondern auf die Bestellübersichtsseite. Das Modul kann ich mal deaktivieren bzw. deinstallieren, brauch ich auch nicht so oft. Allerdings ist das ein reines Backendmodul.

Link to comment
Share on other sites

  • 0

Wenn Dein Shop nur ab und an langsam ist, dann liegt das Problem am ehesten bei Deinem Hosting-Anbieter. Die Datenbank-Logs zeigen ja eindrücklich, woe die Zeit "verbraten" wird, nämlich mit Datenbank-Queries. Diese sollten höchst ausnahmsweise mal 2-3 Sekunden erreichen, 5 bis 10 Sekunden ist jedoch ausserhalb des erwartbaren.

 

Wenn Du ein shared Hosting hast, können solche Performance-Bottlenecks unter Umständen auch durch ganz andere Kunden Deines Hosting-Anbieters verursacht werden.

Shared = mehrere (oder viele) Kunden teilen sich einen Server. Wenn da wer grosse Turnübungen macht, bist Du eben auch mitbetroffen.

Link to comment
Share on other sites

  • 0

Ja, ist ein shared server. Wie oben beschrieben, all-inkl.com Business "Max. Kunden je Server: 30"

Gut, das bedeutet gar nichts, wenn jeder dieser Kunden auf allen 10 Inklusivdomains jeweils eine Webseite hat, sind das schon 300. Am besten noch jeweils gut besuchte Shops oder Chats oder was auch immer. Und zusätzliche Domains gehen ja auch noch.

Jedoch wurde mein Hauptaccount (natürlich inkl. der Unteraccounts) nach meiner ersten Reklamation bereits auf einen anderen Server verschoben. Darüber hinaus schrieb all-inkl.com:

 

...dass die einzigen Zugriffe auf dem Server auf Ihre Domain abzielten

 

Somit war ich wohl derjenige der die Turnübungen gemacht hat :)

 

Ich sehe mir gerade die Datenbank an und hätte mal zwei Fragen dazu:

 

1. Die DB ist rund 15 MB groß, passt das?

 

2. Bei fasst allen Tabellen steht in dem Feld Kollation "utf8_general_ci", bei einigen jedoch "latin1_swedish_ci"
In der Zusammenfassung auch wieder "latin1_swedish_ci" (das Frontend ist auschliesslich auf deutsch).

Bei Typ steht fast immer "InnoDB" bei einigen "MyISAM.

Hat das vielleicht irgendwas zu bedeuten?

Zum Typ habe ich gerade was bei phpperformance.de gelesen, verstehe aber nur Bahnhof

Hat das irgendwas zu bedeuten, wirkt sich das aus?

 

Darüber hinaus, wenn ich all-inkl.com bitten würde die max_execution_time zu erhöhen, würde das denn etwas bringen?

 

Und dann war da noch die Nachricht von all-inkl.com

 

3. aktiveren oder installieren Sie eine Cache-Funktion/Plugin. Prüfen Sie ob diese auch zuverlässig arbeit und alle nötigen Schreibrechte besetzt. Lassen Sie den Cache einmal neu erstellen, wenn bereits ein solchen Plugin aktiv ist

Bitte was ist damit gemeint?

So etwas?

https://addons.prestashop.com/de/performance/7939-page-cache-ultimate.html

Link to comment
Share on other sites

  • 0

Nun, wenn nach ca. 30 Sekunden der Fehler 500 kommt, dann ist die max_execution_time (maximale Scriptlaufzeit) abgelaufen. Inwieweit da die Datenbankperformance eine Rolle spielt, weiß ich nicht (kann aber gut sein, daß das Script auf die Antwort der Datenbank warten muß), die Datenbank wird aber durch eine höhere max_execution_time nicht schneller.

 

Heutzutage sind Datenbanken oft auf SSDs abgelegt und wohl generell nicht auf dem gleichen Server wie die Dateien, da kennen sich andere hier aber besser aus.

 

 

 

Die Frage verstehe ich leider nicht, fehlt mir Fachwissen. Ich habe aber händisch an der DB nichts geändert.
Habe verschiedne Tabellen (Connections etc.) der DB geleert - keine Abhilfe.

Irgendwie verstehe ich das nicht, einerseits schreibst du, du habest nichts an der Datenbank geändert (händisch, ist das im Gegensatz zu was auch immer gemeint?), andererseits du habest verschiedene Tabellen der Datenbank geleert. Operationen an der Datenbank - auch mit einem Modul - können zu Inkonsistenzen und damit zu verschiedenen Problemen und wohl auch zu Verzögerungen führen.

Link to comment
Share on other sites

  • 0

Ja, ist ein shared server. Wie oben beschrieben, all-inkl.com Business "Max. Kunden je Server: 30"

Shared taugt halt selten für einen Onlineshop.

 

Gut, das bedeutet gar nichts, wenn jeder dieser Kunden auf allen 10 Inklusivdomains jeweils eine Webseite hat, sind das schon 300.

Genau aus diesem Grund.

 

1. Die DB ist rund 15 MB groß, passt das?

15 MB ist nix. Das müsste eigentlich komplett in den Memory Buffer der DB passen. Wir haben Kunden mit Datenbanken im GB - Bereich. Aber nicht auf einem shared Host. Oder in anderen Worten: auf einem unserer Server gäbe es mit dieser Datenbankgrösse nichts, was länger als 0.1 Sekunden dauern würde, was die Datenbank betrifft.

 

2. Bei fasst allen Tabellen steht in dem Feld Kollation "utf8_general_ci", bei einigen jedoch "latin1_swedish_ci"

In der Zusammenfassung auch wieder "latin1_swedish_ci" (das Frontend ist auschliesslich auf deutsch).

Ist bestenfalls eine Unschönheit. Hat aber null mit Performance zu tun.

 

Bei Typ steht fast immer "InnoDB" bei einigen "MyISAM.

Hat das vielleicht irgendwas zu bedeuten?

Das ist weniger gut. InnoDB und MyISAM nutzen unterschiedliche Speicherbereiche (Memory). D.h. die Optimierung von Buffers wird dadurch erschwert. Kann die Datenbank auf jeden Fall langsamer machen, aber auch nur z.B. 30 oder 50%. Aber sicher nicht von 1 Sekunde auf 8 Sekunden.

 

Darüber hinaus, wenn ich all-inkl.com bitten würde die max_execution_time zu erhöhen, würde das denn etwas bringen?

 

Hat Null mit Performance zu tun. Gewisse PrestaShop Funktionen wie das Neuerstellen von Bildern brauchen mehr Zeit als die 30 Sekunden. Um einen Abbruch zu verhindern, setzt man dafür die max exec time hoch. Die DB wird davon nicht schneller.

Edited by Scully (see edit history)
Link to comment
Share on other sites

  • 0
3. aktiveren oder installieren Sie eine Cache-Funktion/Plugin. Prüfen Sie ob diese auch zuverlässig arbeit und alle nötigen Schreibrechte besetzt. Lassen Sie den Cache einmal neu erstellen, wenn bereits ein solchen Plugin aktiv ist

 

PrestaShop hat einen Smary Cache. Unter Voreinstellungen => Leistung.

Diese sollte man aktivieren. Speicherort = Filesystem. Neu Compilieren bei Änderungen.

 

Ansonsten: Diesen Fred mal genauer lesen, da steht viel drin:

 

https://www.prestashop.com/forums/topic/623701-performance-wie-man-prestashop-beine-macht/

  • Thanks 1
Link to comment
Share on other sites

  • 0

Ich möchte mich ganz herzlich für Eure Unterstützung bedanken.

 

"Performance - Wie man Prestashop Beine macht" habe ich nun teils abgearbeitet, wobei ich bei "Cache" - letzter Punkt unter Leistung schon erstaunt war, dass dieser deaktiviert werden soll. Dachte immer Cache sei was Gutes.

Darüber hinaus habe ich nun sämtliche Module welche ich nicht benötige deinstalliert. Statistiken, Social media usw.

Aktuell läuft mein Shop richtig geil, es gibt kaum noch spürbare Verzögerungen vom Klick bis zur fertig geladenen Seite. Die Mutter aller Shops, Amazon (denke der ist für viele großes Vorbild), ist ne lahme Krücke dagegen :-)

Ich hoffe es bleibt so, ansonsten habe ich mich wohl wirklich mit all-inkl.com zu streiten.

 

 

Irgendwie verstehe ich das nicht, einerseits schreibst du, du habest nichts an der Datenbank geändert (händisch, ist das im Gegensatz zu was auch immer gemeint?), andererseits du habest verschiedene Tabellen der Datenbank geleert. Operationen an der Datenbank - auch mit einem Modul - können zu Inkonsistenzen und damit zu verschiedenen Problemen und wohl auch zu Verzögerungen führen.

Damit meinte ich, nichts über phpMyAdmin gefummelt zu haben. Die Leerung erfolgte über ein Modul.

 

Bleibt noch eine Frage, wenn Ihr mir die vielleicht noch beantworten könntet, dann seid Ihr mich (zu diesem Thema) los :-)

 

Auf dem Server liegt ein Verzeichnis "Cache". Darin befinden sich bei mir aktuell 1210 Unterverzeichnisse und 3828 Dateien.

Das nervt schon alleine beim Download für´s Backup. Kann ich da noch was gefahrlos löschen?

 

Nochmals, ganz herzlichen Dank!

Link to comment
Share on other sites

  • 0

 

Auf dem Server liegt ein Verzeichnis "Cache". Darin befinden sich bei mir aktuell 1210 Unterverzeichnisse und 3828 Dateien.

Das nervt schon alleine beim Download für´s Backup. Kann ich da noch was gefahrlos löschen?

 

In den Ordnern /cache/smarty/cache und /cache/smarty/compile  kannst du alles - ausser die index.php - löschen.

 

Grüsse

Whiley

  • Thanks 1
Link to comment
Share on other sites

  • 0
"Performance - Wie man Prestashop Beine macht" habe ich nun teils abgearbeitet, wobei ich bei "Cache" - letzter Punkt unter Leistung schon erstaunt war, dass dieser deaktiviert werden soll. Dachte immer Cache sei was Gutes

PrestaShop nutzt verschiedene Levels von Cache. Das letzte Setting ist so eine Art 2nd Level Cache. Der funktioniert in der Regel auf Basis Filesysteme nicht wirklich gut, so dass etwas schneller würde. Die anderen Konfigurationsmöglichkeiten (memcached, APX, XCacher) stehen sodann auf einem shared Host kaum je zur Verfügung.

 

Aber:

All diesen Einstellungen ist eines gemeinsam: Wenn die Datenbank ab und zu 5 bis 10 Sekunden Gedenkpause macht, nützen die allesamt relativ wenig. Jeder Zugriff, ob mit oder Ohne Cache führt zu gewissen Datenbankabfragen, z.B. für Kundendaten, Warenkorb etc. Darum wäre der wichtigste Ansatz, die Aussetzer der Datenbank in den Griff zu bekommen. Und dass wird auf einem shared Host wohl sehr schwierig werden.

Link to comment
Share on other sites

  • 0

Hallo,

ich möchte mich noch einmal gemeldet haben haben.

Nachdem mein Shop weider einige Zeit ganz gut lief, verfiel er dann mal wieder in einen etwa einstündigen Sekundenschlaf.
Daraufhin habe ich mich dann abermals an all-inkl.com gewendet und auf dieses Forum und Eure Antworten verwiesen. Eine kleine Drohung von wegen Providerwechsel habe ich dann auch ausgesprochen. Wäre wirklich das letzte Mittel meinerseits gewesen, aber was hilfts wenn der Shop nicht nutzbar ist bzw. mit solchen Ladezeiten die Kunden abschreckt.

Die Reaktion war ein erneuter Umzug auf einen anderen Server und seitdem rennt mein Shop (und natürlich auch alle anderen Seiten) wie ungescheit. Richtig schön flüssig, macht wieder Laune. Also wars doch der schei... Server.

Einzig die Seiten sehen manchmal etwas seltsam aus, wenn sie sich aufbauen. Erst kommt der Inhalt und danach baut sich das Template auf, so als wenn ich gerade den Cache geleert habe. Das dauert ab und an mal nen Sekündchen, stört aber nicht wirklich - nur wenn man, so wie ich, drauf achtet :rolleyes:

Also, nochmals vielen Dank für den Support (und jetzt suche ich weiter wie man das Thema als "gelöst" markiert - hierzu nehme ich gerne Hilfe von Mods an)

Link to comment
Share on other sites

  • 0
8 minutes ago, henner2605 said:

Also, nochmals vielen Dank für den Support (und jetzt suche ich weiter wie man das Thema als "gelöst" markiert - hierzu nehme ich gerne Hilfe von Mods an)

 

Schaust du unten in meiner Signatur

 

Grüsse
Whiley

  • Thanks 1
Link to comment
Share on other sites

  • 0

Das ab und zu nur der Inhalt geladen wird und dann dein Template ist völlig normal. Läuft immer so ab aber je nachdem wie schnell deine Internetleitung gerade ist oder auch der Server auf dem die Seite liegt, bekommst du diesen Ablauf auch zu Gesicht.

Der Inhalt ist meistens direkt in den Dateien vorhanden. Das Template setzt sich aus mehreren Dateien zusammen wie einer CSS usw.

Hast du Seiten die live generiert werden wie beim Prestashop, kommt das ganze noch deutlicher zum Vorschein. Aber wie gesagt, ist völlig normal. Liegt meistens an der eigenen Internetleitung oder an der Power des genutzten Gerätes.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...