Kategorieprobleme in der 4.8.12 ungelöst

[kummer]

das problem mit den kategorien, die plötzlich ihren bezug nicht mehr haben, ist offenbar in der 4.8.12 noch nicht gelöst. nur so als info. es wird praktisch alle betreffen früher oder später. ist nicht zu reproduzieren und tritt plötzlich auf, wenn in die kategorien editiert werden. dabei verschwinden kategorien, die in der artikelansicht aber noch zu sehen sind. löschen ist nicht möglich. das einzige, was hilft, ist entweder ein dump oder von hand alles wieder gerade biegen. übrigens eine sehr mühsame arbeit.

in der aktuellen version würde ich mindestens empfehlen, keine kategorien zu verschieben. oder dann vorher noch gleich einen dump ziehen.

[Oldperl]

Hallo kummer,

das ist so nicht richtig, ein Restaurieren der Kategorien ist beim Auftreten des beschriebenen Fehlers ohne größeren Aufwand möglich (http://forum.contenido.org/viewtopic.ph ... 59#p131959).
An einem Patch um die Kategorien wieder zu restaurieren arbeite ich bereits, warte nur noch auf mehr Infos zu Mehrmandantensystemen.
Da der Fehler nur sporadisch auftritt, ist ein Fix dafür nicht ohne weiteres zu prüfen.

Falls du diesen Fehler reproduzieren kannst, wäre eine Information dazu hilfreich.

Gruß aus Franken

Ortwin

[kummer]

danke ortwin. ich hoffe, das hilft wirklich. ist eine sehr unangenehme und für kunden sehr beunruhigende erscheinung.

[Dodger77]

So, ich habe mir das mal ein wenig angesehen: Kleiner Testfall mit gut 370 Kategorien. Die Anzeige unter "Content -> Kategorie" erzeugt schon ca. 1200 Queries und ca. 200 DB-Connects. Bei der Anlage einer neuen Kategorie geht die Anzahl an Queries auf über 2700 hoch, davon sind 370 INSERTs. Da dürfte doch Optimierungspotenzial drin sein.

[kummer]

das ist fraglos. theoretisch müsste sich so eine operation mit 3 queries und nur einer verbindung lösen lassen... für die verschiebung. die anzeige geht mit einem einzigen query.

bei den zahlen, die du da nennst, wundert mich die geschwindigkeit. da müsste man eigentlich annehmen, es müsste viel langsamer sein.

[idea-tec]

also 1 Verbindung sehe ich ja noch ein, dass diese reicht.
aber eine kategorie umhängen/verschieben, wenn dann sogar noch welche unten drunter hängen, also level betroffen sind, da reichen 3 queries nicht.
gut, man MUSS es nicht in einer Schleife durchnudeln, man kann das teilweise mit sicherheit auch konsolidiert ändern, aber die reihenfolgen, also durchnummerierte werte lassen sich so nun einmal nicht in einem rutsch ändern.

eigene erfahrung:
- Das Problem sind nicht die Queries, die sind sogar durchdacht und gut gemacht (auch wenn man noch das eine oder andere verbessern kann)
- Das Problem steckt auch in der Leistung und der konfiguration des Servers und MySQL

ich besitze mehrere Installationen mit mehr als 1.000 und sogar mehr als 2.000 Kategorien => Ich hatte noch nie Probleme
- Allerdinsg betreibe ich die Seiten auch nicht bei nem billighoster sondern auf eigenen servern mit entsprechender Leistung und konfiguration

[kummer]

aber eine kategorie umhängen/verschieben, wenn dann sogar noch welche unten drunter hängen, also level betroffen sind, da reichen 3 queries nicht.

ich will dir das jetzt nicht genauer ausführen, karsten. dazu fehlt mir die zeit (es ist schon fast feierabend). da musst du halt selber etwas recherchieren oder nachdenken. drei reichen bei nested sets und mit der aktuellen organisation braucht es fünf (herkömlich) und drei (wer ein bisschen herausforderung sucht). die anzahl untergeordneter kategorien spielt dabei keine rolle. dabei kann die kategorie von egal welcher position auf eine beliebige andere position verschoben werden. um sie, wie beim verschieben bei contenido üblich, nur eine position nach oben zu schieben, benötigt sogar nur einen query. aber das ganze hat dann kaum mehr einen einfluss auf die performance. 5 wären für mich auch schon ok.

Das Problem sind nicht die Queries, die sind sogar durchdacht und gut gemacht.

hmm, da will ich nun niemandem zu nahe treten. aber das erd ist im bereich der kategorien (nicht nur dort, aber da besonders) nicht richtig normalisiert. die ultimativ leistungsmindernde darstellung der hierarchie und vor allem der reihenfolge der kategorien tun das ihre. die rückreferenzierung der folgenden auf die vorhergehende kategorie runden den wahnsinn ab. das müsste mal man gelegentlich ändern. aber auch bei der aktuellen organisation reicht für die anzeige eine abfrage und für eine verschiebungsoperation braucht es halt fünf (resp. 3 oder 1) und bei anwendung von nested sets drei. dann braucht es noch eine für die con_cat_tree, die jedoch - wie bereits ausgeführt - völlig unnötig ist.

die leistung des webservers und der datenbank spielen logischerweise eine rolle, wie bereits bemerkt. neben dem umstand, dass hier kein leistungsproblem vorliegt - das wirst du dann vielleicht auch nocht feststellen -, ist halb so schnell immer halb so schnell, egal wie schnell der server tickt. und wir sprechen hier nicht von ein bisschen langsamer, sondern von extremer leistungseinbusse.

[idea-tec]

Und wieso stellst du deine so fundierten Kenntnisse dem Allgemeinwohl der Community NICHT zur Verfügung?

[Dodger77]

So, ich habe mir das mal ein wenig angesehen: Kleiner Testfall mit gut 370 Kategorien. Die Anzeige unter "Content -> Kategorie" erzeugt schon ca. 1200 Queries und ca. 200 DB-Connects.

Nochmal angeschaut. Das ist natürlich davon abhängig, wie viele Kategorien gerade aufgeklappt sind. Wenn alle 370 aufgeklappt sind, komme ich auf ca. 3700 und über 750 Connects. Ich finde, da muss man ran. Auf meinem lokalen XAMPP geht die CPU-Auslastung mal eben auf 60% hoch und braucht über 2 Sekunden.

[Oldperl]

http://forum.contenido.org/viewtopic.php?f=63&t=23940

Gruß aus Franken

Ortwin

[kummer]

Und wieso stellst du deine so fundierten Kenntnisse dem Allgemeinwohl der Community NICHT zur Verfügung?

das habe ich gemacht und mache es ja immer wieder. schade nur, dass nichts in contenido integriert wird, wenn es nicht aus der richtigen ecke stammt. etwas zu tun ist das eine; eine schulung zu machen führt indessen dann schon etwas weit.

[kummer]

http://forum.contenido.org/viewtopic.php?f=63&t=23940

Gruß aus Franken

Ortwin

hallo ortwin

danke für den patch. das löst das problem allerdings nur vordergründig. verstehe mich bitte nicht falsch, ortwin. ich bin sehr dankbar für den patch. aber wie der name halt sagt, handelt es sich dabei immer nur um ein pflaster. an dieser stelle ist ein pflaster besser als nichts; allerdings müsste man hier eher mit einer prothese ran, als nur mit einem verband. die ursache für die probleme bleiben nämlich erhalten.

[Oldperl]

Hallo Andreas,

sei froh das du nur ein Plaster brauchst und keine Prothese. Und wenn du mit den Lösungen nicht konform gehst, so steht es dir frei andere Lösungen anzuwenden. Und ich habe auch kein Problem mit konstruktiver Kritik. Nur was du da im Moment machst, hat damit nichts zu tun, sondern offensichtlich mehr mit Frustbewältigung.

Gruß aus Franken

Ortwin

[kummer]

ach ortwin, ich sage doch nur, was längst sichtbar ist. ich habe ja nichts gegen deinen patch und bin wie gesagt froh darüber, da es ihn braucht. besser wäre, wenn man ihn nicht brauchen würde. einige tausend queries für gar nichts abzusetzen, ist einfach schlecht. man müsste sich dem problem einfach irgendeinmal richtig annehmen. in den vergangenen ca. 20 versionen von contenido wurde bloss einfach hie und da gepatched. das geht auf dauer nicht gut.

by the way: das ist konstruktiv, vorausgesetzt du verstehst darunter auch, dass man aufzeigt, wo das problem liegt.

Und: Der Hinweis auf die 'richtige Ecke' ist schon richtig. Ich habe eine Lösung geposted, die jedoch aus unterschiedlichsten gründen immer wieder abgelehnt worden ist. Die Argumentation reicht dabei von 'entspricht nicht den Coding Standards' bis 'Integration muss an sehr vielen Stellen erfolgen und ist kompliziert' (für einen umgeschriebenen Code, der mit einer Zeile hat eingebunden werden können). Bei anderen Dingen habe ich einen Umweg über jemanden nehmen müssen, der als vertrauenswürdiger angesehen wird, damit die Integration erfolgt ist. Sowas hilft dem Code dann halt wenig. Die zahlreichen Abfragen werden weiterhin ein Problem darstellen, welches gelöst werden muss, wenn man Contenido nachhaltig entwickeln will. Patchen wird das Problem nicht auf Dauer lösen können.

[emergence]

hmm... mir fehlt mittlerweile die zeit(oder auch lust) hier im forum support zu geben...

aber bei jedem problem muss zuerst die ursache exakt identifiziert werden...
d.h fakten sammeln und sich überlegen wie diese zustande kommen

hier kommen mehrere sachen zusammen...

viele queries(zb x tausend) kann nicht die ursache für verdrehte werte in der con_cat sein... und das ist ein fakt...

scheinbar tritt fehlerhaftes verhalten der con_cat nur bei mehr mandanten oder mehrsprach systemen auf...

bei zuvielen queries kann es sein das die ausführung abgebrochen wird und somit nicht alle einträge in der con_cat_tree existieren...
ein hinweis auf die nested sets ist hier ein möglicher lösungsweg aber zu kompliziert für jeden externen das zu implementieren...
ein externer wird das nur reinbauen wenn auch ein nutzen für ihn vorhanden ist...
auch ein fakt...

eine aussage wie

in der aktuellen version würde ich mindestens empfehlen, keine kategorien zu verschieben.

finde ich ehrlich gesagt unpassend, da einfach die fakten fehlen, dass wirklich als behauptung so stehen zu lassen...

Patchen wird das Problem nicht auf Dauer lösen können.

jedes system wird über kurz oder lang patches benötigen... kein system ist fehlerfrei...
oder willst du bei jedem fehler von grund auf alles neu schreiben um die fehler zu beheben ?

frustbewältigung hin oder her
ein gegenseitiges treten in die weichteile wird die probleme nicht lösen...

ich würde vorschlagen das sich einer um das problem annimmt und das ganze entsprechend analysiert / implementiert und fixt...
da dies ein haufen arbeit ist kann dies nur über eine finanzierte sache laufen... und ich rede hier nicht von peanuts...
ich kann hier gerne mal meine dienste kostenpflichtig anbieten.. und ich wette ich würde es hinbekommen das alle glücklich sind...
wäre nicht die erste sache die ich fixen würde...

so long...