Artikel ändern und speichern dauert lange

newimagine · Beitrag von **newimagine** » Mi 23. Mai 2007, 20:00

Hallo,
habe ein Problem, zu dem ich hier zwar schon so ein paar post gefunden habe, alle haben mir nicht wirklich weitergeholfen. Also:

Wenn ich im Backend einen Artikel im Editor offen habe und auf <Headline> oder <Text HTML> klicke, dann dauert es sehr lange bis dann endlich mal tiny oder der html-Editor öffnet. Das gleiche passiert auch wenn ich <Save> klicke. Nach einigem Stöbern bin ich drauf gestoßen, dass es von der Keywordgenerierung herrühren könnte. Das ganze scheint sich auch zu bestätigen, da die Suchfunktion im Frontend entsprechend langsam ist.

Habe mehrere 4.6.15-er (advanced rewrite von stese) Syteme auf einem Debian Apache2 php4 laufen. Bei einigen tritt das Problem auf bei anderen wieder nicht.

Es scheint in irgendeiner weise ein Problem mit der Datenbank zu sein, denn wenn ich ein sauberes System aufsetze (bei der Suchfunktion und Bearbeitung funktioniert) und eine Datenbank, bei der das Problem besteht drüberspiele ist das Problem das gleiche. ich finde aber auch nirgendwo hinweise in logs...

Weiß jemand Rat?
Ich bin auf jeden Fall etwas Rat-los...

Danke,
Chrisian

Beitrag von **emergence** » Do 24. Mai 2007, 06:53

mach doch nochmal bei der langsamen db ein upgrade....

entweder wurden die cronjobs nie ausgeführt (optimize table ...)
oder aus irgendwelchen gründen wurden, die tabellen indizies nicht gesetzt...

newimagine · Beitrag von **newimagine** » Do 24. Mai 2007, 07:48

Auch nach dem Upgrade das gleiche Problem. Ein optimize table hatte ich schon direkt im phpmyadmin vorgenommen. Hatte auch keine Auswirkung. Eigentlich sieht es mir so aus, als seinen die indizes der langsamen db genau so gesetzt wie bei der vermeindlich schnellen. - Wie müssten sie denn gesetzt sein?

Der Rest des Systems ist auch schnell. Nur dieses Inhalte ändern und die Suchfunktion. Gibt es noch einen anderen Ansatzpunkt außer der con_keywords?

Wie kann ich rausbekommen ob die Cronjobs ausgeführt werden?

gruß

Beitrag von **emergence** » Do 24. Mai 2007, 08:05

newimagine hat geschrieben:Auch nach dem Upgrade das gleiche Problem. Ein optimize table hatte ich schon direkt im phpmyadmin vorgenommen. Hatte auch keine Auswirkung.

schade...

newimagine hat geschrieben:Eigentlich sieht es mir so aus, als seinen die indizes der langsamen db genau so gesetzt wie bei der vermeindlich schnellen. - Wie müssten sie denn gesetzt sein?

siehe setup/data/indizies.sql

newimagine hat geschrieben:Der Rest des Systems ist auch schnell. Nur dieses Inhalte ändern und die Suchfunktion. Gibt es noch einen anderen Ansatzpunkt außer der con_keywords?

also nicht wirklich
du kannst ja versuchen die indizierung zu unterbinden...
includes.con_editcontent.php

Code: Alles auswählen

conMakeArticleIndex ($idartlang, $idart);

mal auskommentieren... wenn es dann noch gleich langsam bleibt ist es was anderes....

newimagine hat geschrieben:Wie kann ich rausbekommen ob die Cronjobs ausgeführt werden?

siehe cronjobs/*.jobs
sollten das dateidatum haben, wenn sie ausgeführt wurden...

newimagine · Beitrag von **newimagine** » Do 24. Mai 2007, 08:48

man man man...
wenn ich mit allem gerechnet hätte... (problem somit gefunden)
und zwar:

Ich habe auf meinen Systemen das bad-behavior für contenido laufen. Auf den Systemen, die langsam waren liefen noch eine alte Version des bad-behaviors. Also überall die neuen draufgespielt und es geht wieder...

Aber danke für die schnelle Hilfe und den Rat emergence...

Gruß,
Christian