Die MySQL-Datenbank wurde ab Version 4.5 mit oxv_ … Tabellen auf die doppelte Anzahl aufgebläht und die gesamte Shop-Software hat über das 4-fache zugenommen. Zur Einführung wurden optimierter Code, bessere Performance usw, propagiert. Im Vergleich zu 4.x kann ich das alles nicht bestätigen.
Ich finde auch keine Antwort bzw. positive Resonanz darauf, welchen positiven Sinn und Zweck das wirklich hat - nur Azur als Ausrede.
Wer ist davon beigeistert oder kann das bitte mal sachlich klarstellen?
ob Du es glaubst oder nicht - dadurch, dass diese oxv_… “Tabellen”, also die Views geschaffen wurden, hat sich die Performance deutlich verbessert
Normalerweise werden ja bei einer Datenbankabfrage (Query) verschiedenste Relationen, Bedingungen, Werte und Berechnungen abgefragt und durchgeführt, das Ergebnis wird dann zurückgeliefert und im Template dargestellt oder anderweitig verwendet.
Die Views kürzen dies ab, da häufige Abfragen quasi bereits fertig ausgeführt zwischengespeichert bereitgestellt werden. Sie stellen also quasi den Cache der Datenbank dar, bzw. genauer eigentlich den Cache für Abfrageergebnisse.
Damit wird erreicht, dass nicht jede Anfrage neue Queries auslöst, die stupide jede Abfrage neu durchkauen und bereits vorhandene und unveränderte Datenlagen neu berechnen, was logischerweise den Server belastet.
In Lieschen Müllers Shop für Omas Häkelarbeit wird dies nicht ins Gewicht fallen, wohl aber bei gut frequentierten Shops mit vielen Besuchern, vor allem bei Hochlast-Zeiten, wenn viele User gleichzeitig im Shop sind.
http://www.payer.de/dbaufbau/dbauf01.html#1.5.3.
Zur Größe der Software - 70% des Volumens sind die Demodaten, dort vor allem die Bilder. Der größte Sprung war zwischen 4.4.8 und 4.5.0 von knapp 30MB auf über 70MB - und zwar bedingt dadurch, dass mit Azure ein weiteres Templateset mit komplett eigenen Demodaten und eigenen Bildern dazu gekommen ist.
[QUOTE=Earlybird;89626]Die MySQL-Datenbank wurde ab Version 4.5 mit oxv_ … Tabellen auf die doppelte Anzahl aufgebläht und die gesamte Shop-Software hat über das 4-fache zugenommen.[/QUOTE]
Die DB-Views sind nur gespeicherte Abfragen auf Tabellen, und beinhalten selbst keine Daten, blähen also die DB nur scheinbar auf. Die Größe der DB selbst hat sich kaum geändert. Ebenso bei der Shopsoftware: die Größe der Software ist ungefähr gleich geblieben, aber die neuen Beispieldaten haben mehr und größere Bilder, daher ist das Installationspaket größer geworden.
@Ray,
Danke für Deine ausführliche Darstellung.
Wie gesagt kann ich die propagierte Performance-Verbesserung (30%) zumindest im Vergleich von 4.4.8 zur späteren Versionen 4.5 ff. überhaupt nicht nachvollziehen und niemand konnte mir dazu wirklich bessere Werte bestätigen.
Gibt es denn überhaupt keinen Oxid Quality Report mehr zu Info?
In den oxv_ Tabellen erkenne bei bei 4.60 Test keinen Cache. Leg mal einen neuen Artikel an und schau in den den oxv-oxarticles Tabellen nach. Dort stehen dann die selben Daten wie in der alten oxarticles. Die oxv_ sind gegenüber den alten ox Tabellen nur zusätzlich nach Sprachen (soweit zutreffend) aufgeteilt und haben damit einzeln gesehen jeweils etwas weniger Colums - ob diese Struktur aber insgesamt auf aktuellen Servern und bei mehrfach redunanter Datenvorhaltung einen entscheidenden Vorteil bringt erachte ich als sehr zweifelhaft.
Das Thema Performance und Cache hatten wurde ja schon im Thread http://forum.oxid-esales.com/showthread.php?t=13437 diskutiert.
Für mich liegen die Performance Probleme ganz woanders: Die Kategorien brauchen mit wachsender Anzahl zuviel Ladezeit: 80% mit ca.1300 Kategorien.
Naja, in der Übergangsphase bis zur 5.0 ist das wohl alles nur ein Komprimiss - “hat … Zukunft”.
[QUOTE=Earlybird;89638]
@Leofonic,
In den oxv_ Tabellen erkenne bei bei 4.60 Test keinen Cache. Leg mal einen neuen Artikel an und schau in den den oxv-oxarticles Tabellen nach. Dort stehen dann die selben Daten wie in der alten oxarticles. Die oxv_ sind gegenüber den alten ox Tabellen nur zusätzlich nach Sprachen (soweit zutreffend) aufgeteilt und haben damit einzeln gesehen jeweils etwas weniger Colums - ob diese Struktur aber insgesamt auf aktuellen Servern und bei mehrfach redunanter Datenvorhaltung einen entscheidenden Vorteil bringt erachte ich als sehr zweifelhaft.
[/QUOTE]
Hab ja nicht gesagt dass das Perfomance bringt ;). Aber es bläht die DB auch nicht auf, weil in den Views keine echten Daten drinstehen, sondern nur Abfragen auf bestehende Tabellen. Also in oxv_oxarticles_de siehst du eigentlich nur die Daten aus oxarticles, oxv_oxarticles_de selbst hat keine Daten. Damit sind dann beliebig viele Sprachen möglich, was vorher nicht ging.
[QUOTE=Earlybird;89638]
Für mich liegen die Performance Probleme ganz woanders: Die Kategorien brauchen mit wachsender Anzahl zuviel Ladezeit: 80% mit ca.1300 Kategorien.
[/QUOTE]
Genau das ist bei 4.5.0 verbessert worden, hier kommt auch der 30%-Wert her denke ich: http://wiki.oxidforge.org/Downloads/4.5.0#Important_information_for_developers bei “Category list performance update”.
@Ray,
Danke für Deine Mühe. Was ich unter Sicht (Datenbank) – Wikipedia u.a. finde ist ja nicht gerade ein gutes Argument für Views:
“Ein Nachteil von Sichten kann sein, dass die Komplexität der dahinter liegenden Abfrage unterschätzt wird. Der Aufruf einer Sicht kann zu sehr aufwändigen Abfragen führen und der unbedachte Einsatz solcher dann zu erheblichen Performanceproblemen.”
Danach ist der Zweck von Views in OXID klar, aber kein schlagendes Argument.
"Improvements in handling multiple languages:
… e.g. (languages from 8th to 15th) … each language has its own DB view for each DB table … there will also be views, joining all language set tables e.g. oxv_oxarticles …
Wieviel Shops brauchen soviele Sprachen (mehr als 3) - vielleicht 0,x % ?
Von Performance Verbesserung ist da auch nicht die Rede, sondern in einem Punkt wird “langsamer” erwähnt:
“These views are basically large joins on OXID, which are slower, but contain whole object as one dataset - usually used for exporting data, and not in eShop frontend.”
Schlussfolgerung: Darauf kann ich verzichten - es gibt wichtigeres.
Danke nochmal für die Hilfe zu einer schnellen Klärung.
Hallo,
[QUOTE=Earlybird;89753]Was ich unter http://de.wikipedia.org/wiki/Sicht_(Datenbank) u.a. finde ist ja nicht gerade ein gutes Argument für Views:[/QUOTE]
Doch, denn hier steht lediglich, dass man bei der Programmierung aufpassen muss. Wenn man das Wort “Performanceprobleme” liest, heißt es nicht augenscheinlich, dass es Performanceprobleme gibt. Auch wenn die Wikipedia in schwarz auf weiß auf dem Bildschirm erscheint 
[QUOTE=Earlybird;89753]1. Danke für die Klarstellung und den Hinweis in oxidforge:
Danach ist der Zweck von Views in Oxid klar, aber kein schlagendes Argument.
Wieviel Shops brauchen soviele Sprachen (mehr als 3) - vielleicht 0,x % ?
Von Performance Verbesserung ist da auch nicht die Rede, sondern in einem Punkt wird “langsamer” erwähnt:[/QUOTE]
Nein. In einem Wort wird langsamer (slower) erwähnt. Hast Du Dir schonmal den ganzen Satz durchgelesen?
[QUOTE=Earlybird;89753]2. Die von Oxid angegebene 30% Performance Verbesserung kann bisher von niemandem bestätigt werden, sondern “kein Unterschied”.[/QUOTE]
Du hast Recht: Die gestylten Quality Reports stehen seit einiger Zeit aus. Ich kann Dir aber versichern, dass wir regelmässig mit syseleven dran sind, zusammen hocken und feststellen, dass wir die Performance stetig verbessern konnten. Natürlich ist Performance auch immer abhängig vom jeweiligen Projekt und man kann nur bestimmte Ranges beurteilen. Deshalb reden wir bei Performance-Gewinn um 30% auch meist von Hochlastszenarien für grosse Shops. Mit 2K Artikeln ohne Varianten, einer Sprache und zehn Bestellungen pro Tag dürfte das kaum spürbar sein
Gruß
Marco,
Ja, ich habe alles zweimal durchgelesen aber leider nichts wirklich wichtiges oder positves an den Oxid-Views gefunden nur die negativen Punkte waren auffällig. Deshalb ja die Frage nach Sinn und Zweck. Jetzt halte ich die Views für unnötig oder altenglisch ausgedrückt ist diesesThema letztendlich “much ado about nothing”.
Kannst Du nach so langer Zeit nicht mal einen aktuellen Syseleven Report in irgendeiner formlosen Art zur Verfügung stellen?
Nachtrag:
Ich sehe gerade noch Du hast auf “OXID Super Cache: Mehr Power für den Shop” verlinkt. Das bringt aber nicht wirklich einen Super-Performance-Schub. Habe dagegen Continum Freiburg verglichen, Referenz-Shop Voltus = sehr gut.
Hallo Earlybird (wie auch immer Du das morgen früh schaffen willst :-)),
[QUOTE=Earlybird;89762]Ja, ich habe alles zweimal durchgelesen aber leider nichts wirklich wichtiges oder positves an den Oxid-Views gefunden nur die negativen Punkte waren auffällig. Deshalb ja die Frage nach Sinn und Zweck. Jetzt halte ich die Views für unnötig oder altenglisch ausgedrückt ist diesesThema letztendlich “much ado about nothing”.[/QUOTE]
Die Datenbank-Views über MySQL stellen in diesem Fall eine gute und praktikable Alternative zu normalisierten Datenbanken dar und das betrifft nicht nur die Sprachverwaltung. Voraussetzung ist, dass sauber programmiert wird.
[QUOTE=Earlybird;89762]Kannst Du nach so langer Zeit nicht mal einen aktuellen Syseleven Report in irgendeiner formlosen Art zur Verfügung stellen?[/QUOTE]
Das möchte ich gern, jedoch geht formlos in dem Fall leider nicht. Bitte gedulde Dich noch etwas, der nächste Quality Report kommt bestimmt und ich bin sicher derjenige, der zu gegebenem Anlass am lautesten schreien wird 
Gruß
Marco, ganz einfach:
jetzt ist doch schon early in the morning. Nur die Oxid Forum Uhr zeigt das nicht korrekt an und sollte doch endlich mal auf unsere lokale Zeit eingestellt werden -wenigstens für German users.
Danke nochmal.
[QUOTE=Earlybird;89765]MNur die Oxid Forum Uhr zeigt das nicht korrekt an und sollte doch endlich mal auf unsere lokale Zeit eingestellt werden -wenigstens für German users.
[/QUOTE]
…hmmm, bei mir geht die richtig - geh mal ins Kontrollzentrum zu Deinen Einstellungen und schau nach, ob Du Dir die korrekte Zeitzone ausgewählt und die automatische Sommerzeiterkennung eingeschaltet hast:
http://forum.oxid-esales.com/profile.php?do=editoptions
Danke jetzt passt’s und ich hoffe es bleibt so.