Bei uns ist die OXSEO knapp über 500mb groß (ja genau MEGABYTE).
Wir können halt leider in einem laufenden Shop nicht zu viel testen, müssen jedoch bald die oxseo ausmisten.
Normalerweise müsste doch die oxseo neu generiert werden nachdem man jede einzelne Kategorie besucht hat (ausser die statischen Links)?
Nein, die oxseo speichert ja nicht nur die aktuell gültigen URL´s sondern auch URL´s, die mal genutzt wurden und nun per redirect auf die neue Adresse zeigen. etc.
Das bei einem produktivem Shop anzufassen ist heikel.
Solange keine db-Anfrage für nicht mehr existierende Artikel auf die oxseo losgelassen werden, dürfte es auch keine Performanceproblem geben. So zumindest meine Einsätzung.
[QUOTE=ChristophH;52108]Nein, die oxseo speichert ja nicht nur die aktuell gültigen URL´s sondern auch URL´s, die mal genutzt wurden und nun per redirect auf die neue Adresse zeigen. etc. [/QUOTE]
Die sind in der oxseohistory, die oxseo sollte nur aktuelle Links beinhalten, außer “static” sollten die Einträge imho automatisch neu generiert werden.
Also ich habe jetzt mal die TAG Geschichte aus dem Shop genommen … es bringt nicht viel und die Performance leidet unglaublich darunter. Spätestens wenn man pro Artikel noch 10-20 Tags unterbringt geht die Shop-Leistung ziemlich in die Knie, wenn jemand auf die Tag-Cloud klickt. Ein Search-Bot kann da ganz schnell zum DOS angriff werden. Deshalb hab ich jetzt mal in einem Shop alle TAGS in OXARTEXTENDS gelöscht und aus der OXSEO alle Einträge mit OXTYPE = dynamic gelöscht. Und siehe da, die OXSEO ist von 280MB auf 53MB geschrumpft. Die Shop-Performance ist auch deutlich erhöht.
Es funktioniert … der redirect ist gemacht und der Server ist wieder super schnell. Bei 15000 Artikeln und ca. 20 Stichworten pro Artikel war das mit der oxseo echt so ne Sache. Und wehe jemand hat auf die Tags geklickt, wenn das ne Suchmaschine gemacht hat, war erst einmal DOS angesagt. Aber nun ist alles im Griff. Alle OXTYPE=dynamic haben wir gelöscht und los gehts. Somit bekommen auch die anderen Seiten bei google einen höheren Stellenwert, da nicht mehr so viele Seiten mit gleichem Inhalt vorhanden sind.
Sebastian, kannst Du das nochmals übersichtlich zusammenfassen, was Du nun im einzelnen gemacht hast?
Das könnte auch anderen Oxid´lern zukünftig helfen. Oder es geht sogar der eine oder andere Aspekt in die Entwicklung ein!
Sebastian, kannst Du das nochmals übersichtlich zusammenfassen, was Du nun im einzelnen gemacht hast?
Das könnte auch anderen OXID´lern zukünftig helfen. Oder es geht sogar der eine oder andere Aspekt in die Entwicklung ein!
Ja das würde mich auch Interressieren wie Du das genau gemacht hast bitte.
Das Problem:
Der Shop eines Kunden wurde immer langsamer. Nach Überprüfung habe ich gesehen, dass die OXSEO ca. 600MB hat und der MySQL Daemon ständig unter Last ist, auch wenn nur wenige Anfragen kommen. Ausserdem war der Shop regelmässig für ca. 1min nicht erreichbar, v.a. wenn Suchmaschinen auf der Site waren.
Die Verdacht:
Wir haben für ein gutes Tagging die Produkte jeweils mit ca. 20 Schlagworten versehen, automatisiert. Jedes dieser Tags hat aber in der OXSEO einen eigenen EIntrag bekommen. Ausserdem war die Tag-Cloud bei 15000 Artikeln sooooo langsam, dass man sie eh nicht mehr nutzen konnte. Die schlechte Performance konnte nur am Tagging liegen.
Die Lösung:
mit 2 Befehlen wurden erst die Tags, und dann die Einträge in der OXSEO gelöscht.
// Erst die Schlagworte aus den Artikeln löschen
update oxartextends set OXTAGS = '', OXTAGS_1 = '', OXTAGS_2 = '', OXTAGS_3 = '', OXTAGS_4 = '';
// Dann die Einträge in der OXSEO
delete from oxseo where OXTYPE='dynamic';
// Um jetzt eine Weiterleitung von /tag/* nach www.domain.de in der .htaccess zu machen, dann landen die Leute wenigstens auf der Startseite.
redirectMatch 301 ^/tag/(.*) http://www.domain.de
// Und wer einen performanten Server hat, kann gleich noch DatenKompression für Textbasierte Dateien in der .htaccess einschalten, spart Traffic und macht Slots auf dem Server schneller frei...
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/x-js
Davor sollten die Infos aber mal von jemandem der wirklich in der Materie steck reviewed werden. Auch ob die Querys vollständig sind und keine Daten-Leichen übrigbleiben.
Aber ansonsten schreib ich das gerne ins Wiki…
Also unsere ServerLast ist spürbar geringer … und ich denke auf google hats sogar noch nen positiven Effekt…
Besteht dieses Problem auch weiterhin mit der aktuellsten CE Version (4.7.x)?
Aktuell arbeiten wir noch mit CE 4.5.0, da ein Update sehr viel Arbeit macht.
Wir haben massive Performance-Probleme mit OXID, vermutlich wegen der Tags in Zusammenhang mit OXSEO.