Seite 1 von 2
Contenido Speichern oder Aufruf des WYSIWYG Editors
Verfasst: Do 10. Nov 2005, 14:02
von siota
Ich habe, um zumindest keine Altlasten aus dem Verzeichnis der Version 4.4.5 zu haben, die 4.6.2 in ein neues Verzeichnis entpackt. Dann die alten Tabellen in eine leere Datenbank importiert und ein Upgrade gemacht. So weit lief alles bestens.
Bei etwas komplexeren Seiten (2 spaltige Tabelle mit 10 Zeilen, Seite insgesamt 16kb) dauert das speichern oder das Öffnen der Seite im Editor ne halbe Ewigkeit. Auch wenn ich nur einen CMS_HTMLHEAD Container bearbeiten will. Ich vermute deshalb , dass das Problem beim Speichern entsteht.
Woran mag es liegen?
php Version.: 4.4.1 / 4.4.0-3
mysql 3.23.58 / 4.0.24
gestestet auf 2 Systemen
Danke schonmal, auch für die viele Arbeit an der neuen Version !!
Verfasst: Do 10. Nov 2005, 16:26
von MediaMuchacho
ich hab das selbe Problem, ich denke das liegt an den umfangreichen Möglichkeiten die der Editor zur Verfügung stellt. Das muss jedes mal geladen werden und benötigt entsprechend Ladezeit... just my 2 cents
Verfasst: Do 10. Nov 2005, 16:44
von siota
Ich bin etwas weitergekommen, die betreffende Seite generiert etwa 4300 Abfragen beim Speichern und legt 580 Einträge in der Tabelle keywords an.
Ruhe ist erst wenn ich die Funktion createkeywords in der Datei class.search.php abschalte. Welcher Teil dieser Funktion die hohe Zahl an Abfragen generiert kann ich allerdings noch nicht erkennen. Die Zugriffe auf den keywords Tabelle sind es nicht, die habe ich abgestellt.
Verfasst: Do 10. Nov 2005, 17:30
von siota
Da habe ich mich wohl verannt
Es war natürlich die Funktion savekeywords und dort der Aufruf db->nextid. Kann man das nicht einfach abschalten und der Tabelle nen autoincrement verpassen? Übersehe ich da etwas?
Verfasst: Do 10. Nov 2005, 17:50
von HighFidelity
Im Thread "JavaScript-Fehler artObj (Verzweifelung)" verzweifle ich vielleicht an einem ähnlichen Thema. Drum hatte ich sofort das mit "createkeywords" ausprobiert, erfolglos. Demhingegen scheint "savekeywords" erfolgreich! Hurra, danke, ein Ansatz. Ich dachte schon, alles wäre irgendwie meine Dummheit...
Grüße,
Thorsten
Verfasst: Do 10. Nov 2005, 17:50
von timo
wenn du es probieren möchtest gerne
aber sämtliche Funktionen arbeiten mit der Sequenztabelle - d.h. du müsstest ALLE SQL-Statements in Contenido anpassen => unfug...
Verfasst: Do 10. Nov 2005, 17:56
von siota
Das mit dem autoincrement meinte ich nur für die Tabelle keywords, das müsste doch gehen
Dann kann ich mir zumindest beim anlegen der keywords den Aufruf der Funktion nextid sparen. Womit wird eigentlich das Array stopwords befüllt, habe da leider nichts zu finden können.
Danke und Gruß
Simon
Verfasst: Do 10. Nov 2005, 17:57
von HighFidelity
@timo, dieses Problem macht Contenido aber zumindest in meinem Fall ziemlich unbenutzbar, deswegen, gibt es eine Alternative? Was für Seiteneffekte treten auf, wenn das erstmal deaktiviert wird in meinem System? Ich verwende ein recht altes Volltextsuche-Modul bisher (Volltextsuche v1.11)...
Grüße,
Thorsten
Verfasst: Fr 11. Nov 2005, 07:00
von HighFidelity
Hallo,
also ich denke etwas drüber nach, leider fehlt mir der Überblick im System, ich habe mich damit kaum beschäftigt bisher. Die Frage ist, welche Seiteneffekte hat es, als Workaround in der class.search.php einfach erstmal das "start indexing the article" funktional auszukommentieren (Zeilen 213 bis 230). Die ganze Datei ist ja eine "API to search in the index structure", und im Vergleich zu Version 4.4.x (von der ich upgedated habe), ist das offenbar neu, oder? Das würde genannten Workaround für mich erstmal machbar erscheinen lassen.
So auf die Schnelle sehe ich im Code keinen Grund für den immensen Performance-Verlust beim Laden. Beim Speichern wird für jedes neue Keyword ein INSERT abgefeuert, sowas skaliert doch irgendwie schlecht und ist auch problematisch, wenn die Datenbankanbindung etwas suboptimal ist.
Weitere Frage, wenn derart indexiert wird, wurde der Index beim Update denn auch initial aufgebaut mit bestehenden Inhalten? Wieder flüchtiger Blick, da wird ein "Standardmodul" eingebunden bei Neuinstallation?
Eigentlich würde man sich wünschen, dass eine Indexierung im Hintergrund verläuft, wie lange der Server mit sich selbst beschäftigt ist, das interessiert den Nutzer ja weniger und wenn der Suchindex etwas hinterherhinkt, das fällt auch niemandem auf.
Grüße,
Thorsten
Verfasst: Fr 11. Nov 2005, 09:26
von siota
Guten Morgen,
Ich habe nun für das Feld keyword einen Index angelegt, in der Funktion createkeyword nur Wörter ab 3 Buchstaben aufgenommen und den Aufruf der Funktion nextid deaktiviert. Für meine Zwecke läuft es so.
Jetzt muss nur noch das Array stopwords gefüllt werden.
Verfasst: Sa 12. Nov 2005, 11:20
von emergence
ich verschieb das mal nach bugs...
das muss man sich genauer an sehen...
4000 queries sind eindeutig zu viele abfragen...
Verfasst: Sa 12. Nov 2005, 12:33
von emergence
okay folgendes hab ich mal gefunden was in meinen augen unsinnig ist...
functions.con.php
in
function conSaveContentEntry
findet sich
Code: Alles auswählen
# generate index of article content
$oIndex = new Index($db);
$aOptions = array("img", "link", "linktarget", "swf"); // cms types to be excluded from indexing
# indexing an article depends on the complete content with all content types, i.e it can not by differentiated by specific content types.
# Therefore one must fetch the complete content arrray.
$aContent = conGetContentFromArticle($idartlang);
$sql = "SELECT idart FROM ".$cfg["tab"]["art_lang"]." WHERE idartlang = ".$idartlang." AND idlang = ".$lang." ";
$db->query($sql);
if ($db->next_record())
{
$oIndex->start($db->f('idart'), $aContent, 'auto', $aOptions);
}
ist zwar recht nett und schön aber ein absoluter blödsinn...
begründung:
diese funktion wird von
include.con_editcontent.php aufgerufen und zwar in einer for each schleife
Code: Alles auswählen
foreach($data as $value){
....
conSaveContentEntry($value[0], "CMS_".$value[1], $value[2], $value[3]);
....
}
für jeden content type wird einmal conSaveContentEntry aufgerufen
und dort werden aus dem artikel nochmals alle content typen selektiert und in der keywords liste ergänzt...
wenn ich sagen wir mal 15 content typen im template habe wird die keyword generierung 15 mal komplett aufgerufen...
da kann ich mir durchaus vorstellen das die sql abfragen anzahl explodieren wird...
es ist ja noch kein problem wenn in jedem CMS_HTML oder was auch immer wenig text vorhanden ist, aber sobald dort mal etwas wie 1500-2000 wörter zu finden sind, krachts gewaltig...
mein lösungsvorschlag:
den part mit
# generate index of article content
in eine eigene funktion auslagern die als parameter nur idartlang und lang ??(beim query wieso ?? idartlang ist ja eindeutig)
und in der include.con_editcontent.php nach der foreach schleife
einmal diese indizierung vornimmt...
das sollte das ganze doch um etliches beschleunigen...
nur damit man weiss von welchen relationen ich da eigentlich rede
kommentiere ich die keyword eintragung komplett aus, benötigt die speicherung/öffnen des editors nicht mehr 5 minuten sondern 5 sekunden... (die suchfunktion kann man dann halt nicht mehr verwenden..)
korrigiert man den ablauf wird das in etwas daumen x pi 20 sekunden benötigen....
Verfasst: Sa 31. Dez 2005, 14:45
von #ayshe
Hm, kann das mal jemand komplett als Code posten - also die bereinigte functions.con.php?
Verfasst: Sa 31. Dez 2005, 16:02
von HerrB
Da ist noch nix, emergence hat nur den Lösungsweg aufgezeigt - es gibt aber noch keine Umsetzung.
Gruß
HerrB
Verfasst: Sa 31. Dez 2005, 23:43
von stese
ok habe es mal umgesetzt:
datei function.con.php öffnen und function conSaveContentEntry suchen.
folgenden part entfernen:
Code: Alles auswählen
# generate index of article content
$oIndex = new Index($db);
$aOptions = array("img", "link", "linktarget", "swf"); // cms types to be excluded from indexing
# indexing an article depends on the complete content with all content types, i.e it can not by differentiated by specific content types.
# Therefore one must fetch the complete content arrray.
$aContent = conGetContentFromArticle($idartlang);
$sql = "SELECT idart FROM ".$cfg["tab"]["art_lang"]." WHERE idartlang = ".$idartlang." AND idlang = ".$lang." ";
$db->query($sql);
if ($db->next_record())
{
$oIndex->start($db->f('idart'), $aContent, 'auto', $aOptions);
}
unter dieser funktion muss eine neue funktion eingefügt werden:
Code: Alles auswählen
/**
* generate index of article content
*
* added by stese
* removed from function conSaveContentEntry before
* Touch the article to update last modified date
*
* @see conSaveContentEntry
* @param integer $idart
*/
function conMakeArticleIndex ( $idart ) {
global $db, $auth, $cfg, $cfgClient, $client, $lang, $_cecRegistry;
# generate index of article content
$oIndex = new Index($db);
$aOptions = array("img", "link", "linktarget", "swf"); // cms types to be excluded from indexing
# indexing an article depends on the complete content with all content types, i.e it can not by differentiated by specific content types.
# Therefore one must fetch the complete content arrray.
$sql = "SELECT idartlang FROM ".$cfg["tab"]["art_lang"]." WHERE idart = ".$idart." AND idlang = ".$lang." ";
$db->query($sql);
if ($db->next_record())
{
$aContent = conGetContentFromArticle($db->f('idartlang'));
$oIndex->start($idart, $aContent, 'auto', $aOptions);
}
}
datei include.con_editcontent.php öffnen und nach der foreach in zeile 46 folgenden aufruf einfügen:
sollte klappen.