Hallo an Alle, danke für den Thread. Schön, dass beim Thema Performance ein wenig Aufmerksamkeit aufkommt. Ich hatte in einem eigenen Thread das Thema aufgegriffen, bin aber auf keine Gegenliebe gestoßen 
Könntest du / hast du mal testweise den Spiegelartikel in Shopware 3.5.6 versucht? Rein vom Gefühl ist beim letzten Major Release einiges an Performance auf der Strecke geblieben - zwar sieht jetzt alles hübscher aus und es gibt ein paar kostenlose Plugins, die vorher gekostet haben, aber ehrlich gesagt ohne diese “Boni” gäbe es keinen Grund zum Wechsel. Shopware hat ja die DB von MyISAM auf InnoDB umgestellt und manchmal habe ich das Gefühl, der Code ist noch auf MyISAM optimiert Wenn du 1-2h entbehren kannst, wäre ein solcher Test sicher interessant. Schöne Grüße Ade
Habe keine Möglichkeit einen 3.5er Shop bei einem Hoster anzulegen um zu testen ob es da schneller geht. Natürlich könnte ich das lokal mit XAMMP machen aber das wäre ja kein repräsentatives Ergebnis. Laut einem befeundeten Programmierer, scheint es, das hier nicht die Datenbank die Abfrage steuert, sondern PHP. Ich bin nicht tief genug drin in der Programmier Materie um das nun vernünftig zu erklären. Aber soweit ich das verstanden habe wird die Abfrage/Übergabe an die Datenbank rein dem PHP überlassen und das der Grund für den langsamen Prozess ist. Zumindest geht bei jeder Anfarage im Shop egal ob Variantenartikel oder nicht die CPU Auslastung direkt auf 100%. Er sagt das wäre zumindest ein Zeichen, das PHP hier die Bremse ist. Wie gesagt, ich hann das nur zitieren, nicht bestätigen mangels Knowledge. Was aber definitiv zu sagen ist, so kann und will der Kunde damit nicht loslegen und überlegt für sich schon Alternativen die es zumindest wenn man seine Mitbewerber anschaut gibt. Leider sind die Aussagen was Performanceverbesserung angeht, auch wenig hoffnungsvoll. Noch so ein Ding sind Versandkosten, die Beschreibung in LABS zu Versandkosten je Artikel ist für 3. und funktioniert in 4.5 so nicht :-(. Ich weiß das dort keine offiziellen Lösungen stehen aber oirgendwie muss man ja Versandkosten pro Artikel vergeben können und sicherstellen das wenn meherer Artikel im Korb sind die Versandkosten auch entsprechend berechnet werden. Keine Idee ob der Fehler vor der Tastatur sitzt, aber langsam verzweifle ich mit Shopware. LG Ralph
Naja gut, man könnte natürlich 3.5.6 und 4.0.6 parallel lokal testen (dank der fertigen Evaluations-Versionen sogar sehr einfach) Dann wären die Bedigungen wieder gleich. Zumal es ja nicht auf Millisekunden ankommt. Sofern 3.5.6 in Frage käme, wäre mir das einen Versuch wert. Mir persönlich sogar schon aus Neugier Zu Versandkosten - hier auch nicht fündig geworden: http://wiki.shopware.de/Versandkosten_detail_811.html Schönen Abend Ade
Hallo, @Geschwindigkeit: bei meinen Tests sind in der Tat auch die Controller der limitierende Faktor, die Datenbank (SQL) ist nicht der Flaschenhals. Damit fällt der Datenbankserver auch zur Optimierung weg. Ein vernünftiger Server sollte aber Verbesserungen bringen. Nur sind die nicht für 50 Euro zu haben. Für sehr viele Varianten (>1000) ist das System auf den üblichen virtuellen Servern/Shared-Hosting-Paketen einfach nicht geeignet. Aber dafür ist Shopware sehr flexibel. Viele Grüße HTH
@ Versandkosten Natürlich habe ich ich mir die genannte Beschreibung zu Versandkosten angesehen. Auch diese Seite (http://wiki.shopware.de/Eigene-Bedingun … 2_475.html) und den dezugehörigen Beitrag zu eigene Versandkosten je Artikel. Aber leider funktioniert das nicht wie beschreiben. Ich habe mich an die Beschreibung gehalten, bei den Artikeln ein neues Attribut angelegt, und in den Versandkosten unter eigene Berechnung den entsprechenden Code wioe auf der Seite beschrieben eingetragen. Funktioniert bei mir nicht. Kann ja gut sein das ich da einen entscheidenden Fehler gemacht habe. Die Beschreibung ist für Version 3.5 der Shop läuft auf 4.0.6. Evtl. liegt es daran das ich das neue Attribut bei den Artikel-Freitexten gesetzt habe. Es sieht in dem Screenshot der Beschreibung so aus. Bei der Versandkostenberechnung nach Gewicht funktioniert Shopware einwandfrei. Evtl. hat sich das Thema Versandkosten je Artikel ja erledigt wenn ich das Flächenberechnungstool von Ottscho testen darf. Trotzdem Danke für die Hilfe hier im Forum. Gruß Ralph
So, nun melde ich mich auch mal zu Wort. Wenn jemand eine Testversion braucht, nur her damit. Daran soll es nicht scheitern. Einfach eine Email an mich schreiben. Aber mit der Performance des Shops bin ich auch mehr als unzufrieden. Ich habe einen Kunden, welche einen sehr guten Server bei Hetzer hat. Es geht um ca. 40t Artikel mit Varianten und Eigenschaften. (Im alten Shop 3.5 hatten wir auch noch tausende Unterkategorien, auf welche wir jetzt im neuen Shop verzichten) APC ist installiert. Das Surfen, Filtern, Artikel öffnen etc. erinnert mich an meine 56k Modem-Zeiten… Wird hier in der nächsten Zeit nichts getan, so kann man dies unter SW4 vergessen und muss auf dem alten 3.5 bleiben!
@ottscho Stimm ich dir zu 100% zu. Und das nicht erst ab Tausenden Artikeln, wie ich das in einem anderen Thread schon dargelegt habe. Der Unterschied ist bei mir bereits mit wenigen 100 Artikeln enorm - sowohl im Front- als auch Backend. Bedenkt man, dass neue Versionen für gewöhnlich bessere Performance bringen (und die 4er ja auch so beworben wurde, ist das doppelt ernüchternd) Es hat mich nur gewundert, dass kaum Resonanz kam. Also nahm ich an, der Fehler liegt bei mir.
Ja geworben wurde mit deutlich besserer Performance als der Mitbewerber Magento, das Ziel wurde aber bei weitem nicht erreicht. Und man ist auch sehr weit davon entfernt auch nur annähernd an deren Performance ranzukommen. Und die sind auch nicht schnell um es mal so zu sagen. Schade ist, das aus meiner Sicht hier der User / Benutzer bewusst in die Irre geführt wird. Auf der Shopware Convention wurde es komplett anders dargestellt, selbst ein befreundeter Magento Anbieter war zuerst begeistert, die Ernüchterung folgte aber ziemlich schnell. Es ist Schade denn die 3.5er Version hat mir gut gefallen und wie schon jemand geschieben hat, eigentlich sollte man annehmen das eine neue Version auch mit verbesserter Perfomance einher geht und nicht anders rum. Aber ggf. liest das ja einer der Verantwortlichen und nimmt das mal ala Anreiz hier ausdrücklich an der Performance Schraube zu drehen und den gemachten Versprechen auch nachzukommen.
Moin, ich trete ja so gerne nach, also mache ich das hier auch mal… Und das schreibe ich hier als meine ganz persönliche Meinung… Das Hauptproblem ist meiner Meinung nach in der generellen Architektur begründet. Sowohl datenbankseitig als auch von Seiten der Applikationsarchitektur her. Ich hatte persönlich mit Erscheinen der Version 4 auf einen vollständigen Rewrite der Kernarchitektur gehofft. Es wurde aber bereits auf dem Community Day schnell klar, dass dies zumindest in Version 4.0 nicht passieren wird, so dass man nun an Altlasten krankt, gleichzeitig Teile neu- oder umgeschrieben und obendrein neue Features hinzugebaut hat. Es wäre in meinen Augen ein wahres Kunststück gewesen, wenn das alles reibungslos funktioniert hätte…Mittlerweile scheint man ja zumindest mit der Version 4.0.6 halbwegs auf dem Weg zu sein, dass alles einigermaßen fehlerfrei läuft (kleine Bugs gibt’s ja immer), bleibt also „nur“ noch das leidige Thema mit der Performance. Version 3.5 hatte schon Probleme, in der aktuellen scheint sich das soweit noch verschärft zu haben. Vermutlich, ich hab’s nicht getestet, trägt das zusätzliche ORM Layer sein übrigens dazu bei. Es ist erstaunlich, wie performant die Server sein müssen, damit ein Shop mit nur einigen Tausend Artikeln überhaupt bedienbar ist. Dass das alles nur über umständliches und aufwendiges Caching, möglichst noch in der Enterprise Version mit Varnish, möglich sein soll, macht mich sehr sehr nachdenklich. Wie sieht’s denn dann überhaupt aus, wenn mal mehr als 50 Besucher gleichzeitig auf der Seite surfen?! oh je… Laut Wikipedia wird, mit Verweis auf offizielle Angaben, ab spätestens 35k Seitenaufrufen pro Tag eine Clusterversion empfohlen. Ein Shop mit zwei Webservern und einem Datenbankserver ergibt eine Kapazität von 300k Seitenaufrufen am Tag. Ich denke, dass sich das noch auf die v3.5 bezieht. Wenn ich mir durchlese, welche Verrenkungen (=Technologien, die dort zum Einsatz kommen) dort unernommen werden müssen, um dieses Ziel zu erreichen, dann muss ich leider ein wenig weinen. Wir können in technisch abgespeckter Konstellation (zwei Webserver, ein Datenbankserver, kein Varnish, kein Solr, ca. 100 Artikel mit teilweise mehrdimensionalen Varianten, mehrere Subshops, sowohl Sprachen als auch echte Frontends) einen theoretischen (=über den Tag gleichmäßig verteilten) Traffic von aktuell ca. 4 Mio Seitenaufrufen pro Tag bedienen. Unsere Peaks lagen bei 260k innerhalb von 2 Stunden. Und da wäre noch mehr rauszuholen… Das nur mal als Vergleichskennzahl. Selbst mit 1000 oder 10.000 Artikeln DARF es einfach nicht signifikant(!) langsamer werden, dafür gibt es einfach keine Rechtfertigung, außer einer schlechten Architektur, aber da muss man dann auch einfach mal seine Hausaufgaben machen. Ich bin wirklich traurig darüber, dass es in V4 augenscheinlich eher schlimmer als besser geworden ist. Wenn es wenigstens endlich eine annähernd vollständige, öffentliche zugängliche Testabdeckung gäbe, dann könnte man an der einen oder anderen Stelle versuchen etwas zu ändern, aber so habe ich persönlich nicht mal Lust mir einzelne Teilbereiche näher anzusehen.
Hallo zusammen, an der Performance wird natürlich weiter optimiert - vor allem mit Shopware 4.1.0 (http://wiki.shopware.de/_detail_1016.html) wird hier noch einiges passieren. Im Prinzip gibt es aber im Frontend nur eine wesentliche Änderung (Aus Performancesicht) zwischen 3.5 und 4.0 - die Art wie Varianten im Hintergrund verwaltet werden. Ab Shopware 4.0 sind das ja jeweils vollwertige Artikel und wenn man wie unter https://www.glasdesign-bus-shop.de/spie … licht?c=90 eine Breiten / Höhen-Auswahl auf dieser Basis verwalten will, generiert man ja je Artikel schnell 10.000 und mehr Sub-Artikel - das wird dann mit einem einfachen Hosting-Paket schwierig. Für solche Anwendungsfälle kann man besser das Modul Individuelle Optionen verwenden (Wird für Shopware 4 in Kürze bereitgestellt) - oder halt eine Spezial-Erweiterung, wie das Flächenberechnungsplugin von Ottscho. @Gripmedia Schick uns bitte einmal FTP + Datenbank + Backend-Zugangsdaten an entwicklung@shopware.de - dann würden wir einen Blick auf deinen Shop werfen, ob man da auf Basis des bestehenden Hostings noch was drehen kann.
Guten Tag Herr Schücker, es geht ja nicht darum, den Shop per se schlecht zu reden. Mir gefällt SW4 in fast allen Belangen besser, als SW3. Nur leider in einem nicht, und das ist die Performance. Und zwar abseits des Einzelfall-Problems hier. Ich denke persönlich, dass die Lösung über Varianten vorliegend eher ungeeignet ist. Allerdings beschränken sich die Performance-Unterschiede ja nicht nur auf die Varianten. Ich hatte meine Eindrücke (rein subjektiv aus Usersicht) bereits in einem anderen Thread beschrieben: post48098.html#p48098 Ich hatte sogar mal testweise die MyISAM Tabellen in SW 3.5.6 in InnoDB konvertieren lassen mit der Folge, dass alles ebenso langsam wurde, wie in SW4 - daher auch meine Annahme, dass hier der Hauptunterschied liege. Ich hoffe und würde mich freuen, wenn mit der Version 4.1 tatäschlich eine deutliche Verbesserung kommt, denn das hübscheste Aussehen und die tollsten Ajax Geschichten helfen nicht, wenn die Kunden beim Stöbern oder Bestellen abspringen, weil der Shop nicht performant genug ist. Schöne Grüße Ade
Hallo Ade, zu beachten ist in Shopware 3.5 wurde der Shop im Standard mit Cache betrieben. In Shopware 4 ist der Cache im Standard deaktiviert. Wenn in Shopware 4 der http Frontend Cache aktiviert wird, gewinnt der Shopware 4 Shop rapide an Leistung. Es muss halt aufgepasst werden was wie miteinander verglichen wird. In Shopware 4 ist vieles anders als in Shopware 3.5. Es wurden sehr viele neue Techniken eingesetzt. Diese werden nun noch besser auf einander abgestimmt. Mit Shopware 4.1 wird einiges an der Performance optimiert. Uns ist natürlich auch sehr wichtig, das eure Shops schnell sind. Habt also noch ein klein wenig Geduld. Gruß Patrick
Hi, danke für die Ausführungen. Man muss auf jedenfall genau aufpassen, wie man vergleicht - ich hatte mir bei meinen Vergleichen aber durchaus Mühe gegeben (beispielsweise fiel mir recht spät auf, dass SW3 jede “Seite” aus dem Bereich “Kunden haben sich ebenfalls angesehen” per Ajax nachlädt, wohingegen in SW4 alle Artikel vorgeladen werden - macht natürlich einen Unterschied) Der Cache war aber meiner Meinung nach auch in SW3 standardmäßig aus. In SW4 hatte der Cache bei mir im Kurzversuch leider keine spürbare Verbesserung gebracht - den Frontendcache (httpCache) hatte ich auch getestet. Warten wir also auf 4.1 und freuen uns über ein inzwischen Livebetriebtaugliches 4.0.6 Danke an der Stelle auch mal für eure Arbeit! Schöne Grüße Ade ps: fehlt in einer Smartphone und Tabletwelt eigentlich nur noch das klasse Mobile Plugin aus Version 3 (wobei CouchCommerce sicher auch ok ist)
Guten Morgen, es freut mich an dieser Stelle auch mal Lob zu lesen. Danke. Um einmal kurz abzuschweifen: Ein Mobile Plugin wird es nicht für Shopware 4 geben. Aktuell ist CouchCommerce eine sehr gute Lösung. Auf Dauer wird es aber auch ein Responsive Template geben. Grüße aus dem Münsterland Patrick
Guten Tag, Das ist ja schade. Das habe ich komplett falsch verstanden. Dabei hatte ich bei der Entscheidung zum Wechsel noch bewusst nach dem Mobile Plugin als Kriterium geschaut und die Informationen dahingehend verstanden, dass das Plugin in Q1 nachgereicht wird - dabei war das Responsive Template gemeint, was nachgereicht wird. Naja gut, muss man halt genauer lesen Aber danke für die Info! Dann schauen wir uns mal nach alternativen Lösungen um. Schöne Grüße Ade
Mit dem Flächenberechnungstool von Ottscho funktioniert das wunderbar. Danke an Herrn Ott für den Support und das Modul. LG Ralph
[quote=“gripmedia”]Mit dem Flächenberechnungstool von Ottscho funktioniert das wunderbar. Danke an Herrn Ott für den Support und das Modul. LG Ralph[/quote] Finde ich aber traurig, dass man sich erst noch ein Plugin kaufen muss, damit das besser funktioniert!
Hi Ralph, freut mich, dass es nun gescheit bei dir Funktioniert. Aber auch mit Shopware 4.0.7 sollte es mit deiner alten Lösung (Varianten Artikel) auch schon deutlich schneller gehen. An dieser Stelle wurde einiges optimiert. @Petra: Shopware ist eine Standardsoftware. Es wird sehr viel mit dem normalen Shop abgedeckt. Wenn man dann etwas spezielleres für seinen Shop haben möchte gibt es Möglichkeiten das System individuell anzupassen. Gerade deswegen ist Shopware doch so anpassbar. Gruß Patrick