Jump to content

5000 Multistores - Performance... unnötige Queries?


Fate

Recommended Posts

Hallo,

 

ich beschäftige mich seit 2 Tagen mit Prestashop und muss sagen, bis jetzt bin ich schlichtweg begeistert.

 

Um unsere Anforderungen im Bereich Multistores zu testen habe ich 5000 Stores angelegt. Presta schafft diese Menge relativ problemlos wie es scheint (Magento brach schon nach weniger als 1000 Stores zusammen). Der Aufbau des Multistore tree dauert etwas aber das ist sicher von mir optimierbar/austauschbar.

 

Wo es aber hakt und was mir nicht gefällt ist die Verwaltung der Produkte:

 

Das Laden eines Produktes ist kein Problem, das geht sekundenschnell. Will ich aber den Produktnamen für alle Stores ändern, dauert es ca. 1,5 Minuten bis es gespeichert ist (lokaler Laptop, da dauert natürlich alles etwas länger, aber...).

 

Ich habe mir mal alle Queries mitloggen lassen und siehe da, irgendwie gibt es viel zu viele davon. Das Logfile ist nach dem Speichern von einem Produkt für 5000 Stores fast 20MB groß. Insgesamt hat das Logfile ca. 130000 Zeilen.

 

Enthalten sind Queries wie z. B.:

 

UPDATE `ps_product_lang` SET `id_product` = '1',`id_lang` = '1',`id_shop` = '1941' WHERE id_product = 1 AND id_lang = 1 AND id_shop = 1941

 

Und das einige tausend Male.

 

Zudem kommen viele Queries doppelt vor, sehr viele Einzelabfragen ala

 

SELECT COUNT(*) FROM ps_product_lang WHERE id_product = 1 AND id_lang = 5 AND id_shop = 4253 LIMIT 1

 

oder

 

SELECT id_product FROM ps_product_shop WHERE id_product = 1 AND id_shop = 580 LIMIT 1

 

Hat sich zufällig schon jemand damit herumschlagen müssen?

 

Ansonsten werde ich den Teil zum Speichern eines Produktes wohl umschreiben müssen denn wenn ich den Haken für "ALLE PRODUKTE UPDATEN" setze ist es im Prinzip nur ein einziger Query pro Sprache der ausgeführt werden muss. Selbst wenn ein Produkt noch nicht in allen Stores vorhanden ist reicht doch ein INSERT IN DUPLICATE KEY UPDATE.

 

Und beim Abfragen der Produktdatenbank muss doch auch nicht pro Store ein Query ausgeführt werden sondern eher nur einer pro Sprache, wenn überhaupt?!

 

Ich würde mich über hilfreiche Anregungen freuen.

 

Mit freundlichem Gruß,

 

André

Link to comment
Share on other sites

Also eines Vorab. Die DB-queries wurden für Version 1.4.9 und die offiziellen 1.5. Versionen soeben optimiert. Hast du da bottle-necks gefunden, dann poste das bitte im bug-tracker. Hier wird dir kaum einer helfen können. Es ist ein User-Forum und kein Experten Forum. Multishop-Funktion ist halt eben nicht sooo toll wie man sich das erwartet. Ich bin von so etwas schon lange abgekommen, da ich schweres Bußgeld in Sachen SEO zahlen musste. Wer Multishop unbedingt braucht soll es nutzen, aber nicht meckern wenn man a) von den Sumas bestraft wird und b ) die Datenbank, die ja immer größer wird es irgendwann nicht mehr schafft alles abzuarbeiten.

 

Ich warnte schon über ein Jahr über dieses Problem, auf Grund sehr schlechter Erfahrungen von vergangenen Zeiten.

Link to comment
Share on other sites

Ok danke schonmal für die Antwort!

 

Wie würdest du denn einen Multishop lösen? Mehrere getrennte Installationen und dann die Datenbank synchron halten? Bei sowas macht mir der Warenbestand immer Sorgen, denn wir arbeiten mit Kleinstmengen die sich alle teilen. Das kann natürlich ein Konzeptfehler sein aber lassen wir das mal so stehen. Ich glaube die Echtzeitsynchronisation von 5000 Shops nimmt genauso viel Hardware in Anspruch wie ein System mit 5000 Shops wo keine Sync notwendig ist.

 

Ich lasse mich aber gerne belehren!

Link to comment
Share on other sites

Ehrlich gesagt ? Ich habe meine Shops alle wieder getrennt. Eigenes Projekt, eigene Datenbank. Ich verwalte die Shops mit Presta Store Manager, jeden einzeln.

Das ganze Multishop war ein Chaos pur, denn man muss ja wegen SEO alles getrennt halten, sonst holt man sich Penalties. Langsame Shops werden detto bestraft, man sinkt in den Positionen. Ich bin wirklich von Multishop enttäuscht und auskuriert.

 

Weiters sind kleinere Projekte einfacher zu handhaben bei Importe, usw. Man verliert nur unnötig Zeit bis man den Import genauso hat, dass auch nur die Produkte aktualisiert werden.

 

Ich habe aber auch keine 5.000 Shops, sondern 5 eigene Projekte (also nicht nur Shops, sondern Anzeigenmarkt, Blog, Shop und angebundenes Kassensystem). Das reicht wenn man die Schose selbst schaukeln will. Und nein 5.000 Shops benötigen nicht soviel Serverkapazität wie eine Riesen zentrale Stelle die stetig Abfragen bearbeiten muss.

 

Teilst du das geklügelt auf ein Netzwerk mit balance load auf, dann wird jeder Shop gleichmäßig schnell arbeiten. Was ja bei einer Riesen-DB nicht möglich ist. Hier kannst du nur Prioritäten setzen, mehr nicht. UND ein großer Nachteil hat das ganze auch noch. Was ist, wenn mit dieser Riesen-DB was ist ? Dann gute Nacht... Es hat sich für mich nicht bewährt. Die Nachteile waren mehr, als die Vorteile.

Link to comment
Share on other sites

Ok danke für deine Antworten!

 

Über die geteilten Systeme denke ich weiter nach, sicherer ist das auf jeden Fall. Bis wir 5000 Shops haben vergehen auch noch einige Prestaversionen, bis dahin kann ich mir in Ruhe was überlegen wegen der Sync.

Link to comment
Share on other sites

  • 4 weeks later...

Hallo,

ich denke den Sinn von Multishop muss man wirklich von Fall zu Fall entscheiden. Ich habe gerade 2 PS Shops laufen. Damit ich die Kundendaten in beiden Shops abgleichen kann, benutze ich SQL Views.

 

create view ps_customer as select * from c1jxxx_n.ps_customer

create view ps_customer_group as select * from c1xxxx.ps_customer_group

create view ps_address as select * from c1xxx.ps_address

 

Die Haken, ein Update ist somit nicht ohne weiteres möglich.

Ich muss mich um 2 PS Installationen kümmern. Im Kleinen mag das ja noch gehen aber nervt jetzt schon gewaltig. Bugs beheben, Modifikationen usw. muss ich immer an mehreren Installationen vornehmen. Ich denke der Punkt wo so etwas keinen Sinn mehr macht ist schnell erreicht.

Das SEO Thema habe ich schon im englischen Forum hin und her diskutiert. Duplicate Content usw . usf. Ich muss den praktischen Beweis noch erbringen aber ich denke für internationale Suchmaschinenoptimierung ist es so gut wie unabdingbar das man mit einer Multishop, optimalerweise, Multidomain Lösung arbeitet um sich vernünftig platzieren zu können. Ich begrüße das Feature absolut bin aber auch der Meinung, dass das z.Z. vielleicht noch nicht so voll Production ready ist. Da hakt es doch noch an einigen Details. Mittlerweile hab ich das so grob verstanden wie die neuen Stock Management Systeme arbeiten aber mir scheint, dass einige Teile scheinbar noch mit der heißen Nadel gestrickt sind.

Ich hoffe mal das wird noch besser in Zukunft.

Alles Beste, Trip

Link to comment
Share on other sites

Multishop macht nur Sinn, wenn man einen großen Shop in viele kleine Themenbezogen aufteilt mit einem Kundenstamm, und somit die beste SEO-Performance damit erzielt. Problem jedoch dabei ist, dass die Größe der Datenbank nach wie vor bleibt und einen speziellen Server benötigt um alle Queries auch schnell verarbeiten zu können, was dann Einfluss in die Performance von allen Shops problematische Auswirkung haben kann.

 

Ich präferenziere lieber mehrere Datenbanken, getrennt von einer großen. Wenn die große DB knallt, dann ist man blockiert in allen Shops.

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...