wir haben unseren ersten Shop entwicklelt, der komplett auf Varianten setzt. Wir sind bis dato auch recht zufrieden, auch wenn man von Haus aus anscheinend nicht alle Varianten auf einmal aktivieren konnte. (Oder haben wir nur den Button nicht gefunden? ) Jetzt stehen wir vor dem Problem, dass bei einigen Artikeln, die zwischen 200-300 Varianten haben, die Performance bereits drastisch einbricht und wir Antwortenzeiten zwischen 9-11 Sekunden haben:
Execution time :9.4293
Memory usage: 43.314 MB (peak: 49.567 MB)
System memory usage: 47.75 MB (peak: 54.5 MB)
cl=details
Wir haben diesen Shop auf einem Privat-plus Webspace von all-inkl.com laufen. Das dies keine optimale Lösung ist, ist uns bewusst. Meint ihr, mit dem Umzug auf einen managed Server wie diesen hier: http://all-inkl.com/server/server_l könnte man diese Probleme beheben? Oder liegt das an den Varianten als solche und der Umzug auf einen “eigenen” Server würde die Geschwindigkeit nur marginal steigern?
vielen Dank für die schnelle Antwort.
Das Modul haben wir bereits im Einsatz, das bringt uns ca. 3-4 Sekunden.
Trotzdem verbleiben noch zwischen 9-11 Sekunden.
Die Frage ist ja ob der Umzug auf einen Managed Server die Performance spürbar beeinflussen würde und ob jemand damit bereits Erfahrungen gemacht hat, denn dies ist ja auch eine Kostenfrage.
Der Support von All-inkl.com war wie immer sehr nett, meinte allerdings, er könne dazu keine Aussage machen, da (logischerweise) zu viele Faktoren mit hineinspielen.
das Problem bei der Sache der Varianten ist, dass sehr viel Quellcode vom Server produziert wird, bei einer Variante von 4 * 10 * 6, bläht sich hier der Code, den der Server an den Client liefern muss auf ca. 80.000 Zeilen auf, was dann in etwa 2 MB entspricht. Summa summarum ist das ein Wert, der absolut unhaltbar ist.
Es gibt hier meiner Meinung nach für diese ettlichen Varianten nur einen Lösungsansatz, der recht vielversprechend ist. Nämlich eine Kombination aus JSON + AJAX, sprich bei jeder Detailansicht zieht sich ein PHP-Script sämtliche benötigten Varianten / Produktinfos, encoded das als JSON Objekt und dann wirds via JavaScript in die DOM geparsed. Bei einer großen Anzahl Varianten geht das sogar innerhalb einer Sekunde, wenns überhaupt so lange dauert.
Nachteil der ganzen Geschichte ist halt, dass ohne JavaScript überhaupt nichts mehr funktioniert, was mich persönlich jetzt nicht stört, aber da scheiden sich ja bekanntlich die Geister.
Wenn ich das mal zusammenfassen darf bedeutet das also:
Die Performanceproblematik hängt zu einem großen Teil nicht mit dem Webserver zusammen, sondern ist durch die Programmierung bedingt.
Das heisst, der Umzug auf einen eigenen Server würde uns nur sehr bedingt weiterhelfen?
Auf einer lokalen Testumgebung reduziert sich die Ladezeit um 50 Prozent, liegt damit allerdings immer noch bei ca. 6 Sekunden.
Ich wäre über alle Tipps zur Verbesserung dankbar.
PS: Das Modul haben wir bereits im Einsatz.
yepp, genauso isses, wobei der Webserver natürlich nie so schnell sein wird, wie ein lokaler Host.
Wenn der Server natürlich schnell genüg ist, machst Du da schon noch einiges an Performance wett.
Ansonsten ist die Sache natürlich sehr von der Programmierung abhängig und das normale Variantensystem ist der absolute performance Supergau, da hilft wirklich nur, sich ein Modul bzw. Script zu schreiben, welches sämtliche Produktinfos in ein JSON Objekt tütet, sind dann Ladezeiten bei einem schnellen Server von unter einer Sekunde. Bei 2 Dimensionalen Artikeln sogar noch wesentlich schneller, kommt eben darauf an, wie schnell der Server das JSON/Textfile generiert und an den Client liefert.
yepp, genauso isses, wobei der Webserver natürlich nie so schnell sein wird, wie ein lokaler Host.[/QUOTE]
Es gibt ne Menge Webserver die deutlich schneller als der Großteil lokaler Rechner sein dürften.
BTT: Das “Problem” Varianten ist wirklich nicht einfach zu lösen. Was vertreibt Ihr denn für Artikel die 200 Varianten benötigen? Evtl. würde hier ein anderen Denkansatz Sinn ergeben.
nur um euch auf dem Laufenden zu halten.
Nachdem wir die ganze Sache nun auf unseren eigenen Server umgezogen haben, ist die Performance um 2/3 schechter als zuvor, lediglich die Ladezeiten sind konstanter geeworden. Um das mal in Zahlen auszudrücken. Wir hatten bei einem Artikel 10 Sekunden Ladezeit, nach dem Umzug sind daraus ca. 17 Sekunden geworden. Nach Rücksprache mit dem Support versicherte man uns, dass dieser genau die gleiche Hardwarekonfiguration hat wie der, auf dem unser Shared Angebot vorher lief?
Wie kann das denn sein?
Muss man noch etwas an der Softwarekonfiguration ändern, Vorschläge?
es führt leider kein Weg daran vorbei, die Variantentechnologie von Oxid komplett mit einer anderen Lösung zu umschiffen. Sprich, hier komme ich wieder auf die JSON Möglichkeit zu sprechen, mit dieser auch umfangreiche Artikelstrukturen rasend schnell abzubilden sind.
Wenn Ihr die orginal Varianten Templates verwendet, sehe ich hier keine große Möglichkeit, die Seite unter 10 Sekunden Ladezeit zu bringen.
Bei einem gut konfigurierten Server sollte die Variantengeschichte via JSON innerhalb einer Sekunde laden.
Coarsy, wie holst du denn die Info über die Varianten? Das json bei der Übertragung schnell ist, ist klar. Die 10 Sekunden aus dem ersten Post sind aber auf dem Server gemessen und daher unabhängig von der Übertragungstechnik. Ich verwende ein Modul, bei dem die Varianten nur einzeln per Reload übertragen werden, trotzdem wird die Ladezeit um so länger, je mehr Varianten vorhanden sind (selbst deaktivierte Varianten kosten Performance).
ich hole mir die Infos natürlich direkt aus der Datenbank, mittels einem PHP Script, welches mir die JSON Objekte zurückliefert. Bei sehr vielen Varianten hat man bei den Originaltemplates wie oben erwähnt das Problem, dass sich der HTML Code unwahrscheinlich aufbläht und man dann ca. 80.000 Zeilen > 2 MB an den Client schicken muss.