Kategorie - Funktionen im Backend sehr langsam

[fordor]

Hallo Leute,

wir setzen Contenido für unser zweisprachiges Firmenintranet ein und haben z. Zt. ca. 980 Artikel online.

Diese Seiten werden von 28 Bereichs-Redakteuren betreut.
Leider ist das Backend bei unseren Redakteuren, insbesondere in den "Kategorie-Funktionen" sehr langsam.
Dies liegt vermutlich an den eingeschränkten Berechtigungsprofilen der Benutzer.
Alle Administratoren haben diese Geschwindigkeitsprobleme nicht.

Gibt es da schon Abhilfe, Updates bzw. Bug-Fixes?
Über Eure Posts würde ich mich freuen.


Systemumgebung:
Contenido 4.6.8 / Fedora Linux / PHP 4.4.2 / MySQL 5.0.21

[emergence]

nein dafür gibts nicht wirklich was...

hängt aber nicht mit der artikel anzahl sondern anzahl der kategorien zusammen...

...wenn viele einzelne berechtigungen kontrolliert werden müssen, kann ich mir durchaus vorstellen, dass das system ausgebremst wird...

[fordor]

Da gebe ich Dir recht mit der Anzahl an Kategorien.
Aber leider muss ich Berechtigungen vergeben.

Es können nicht alle Benutzer Admins sein.
Dann gibts ein Chaos WIKI bei uns.

Was schlägst Du vor?

[emergence]

ähm, ideen/vorschläge habe ich da nicht wirklich...

vielleicht wird es schneller wenn die benutzer nicht alle kategorien auf einmal aufmachen, sondern sich einzeln bis zu ihren bereich die kategorien öffnen... (ist jetzt nur ne annahme...)

ich hab zwar mal an einem neuen system gearbeitet, um den bereich dort zu beschleunigen, aber das ist weit davon entfernt fertig/freigegeben zu werden...

[xmurrix]

Hallo zusammen,

hatte mal in der Version 4.4.4, die Generierung der Kategorienseite durch Änderungen an der "include.str_overview.php" etwas beschleunigen können. Denke, das lässt sich bestimmt auch auf die 4.6.8 portieren.

Grüße
xmurrix

[MyAccount]

ähm, ideen/vorschläge habe ich da nicht wirklich...

vielleicht wird es schneller wenn die benutzer nicht alle kategorien auf einmal aufmachen, sondern sich einzeln bis zu ihren bereich die kategorien öffnen... (ist jetzt nur ne annahme...)

ich hab zwar mal an einem neuen system gearbeitet, um den bereich dort zu beschleunigen, aber das ist weit davon entfernt fertig/freigegeben zu werden...

Hi emergence,

hat er keine Chance, wenn er das hartverdrahtet? Also für bestimmte Redakteure diese Rechteüberprüfung rausnimmt und über manuelles SQL-Tuning gleich die Anzeige im Backend auf die Kats beschränkt?!

[emergence]

ähm hartverdrahtet ?

versteh ich nicht ganz...

[xmurrix]

ähm hartverdrahtet ?

versteh ich nicht ganz...

Hallo emergence,

er meint wohl sowas wie

Code: Alles auswählen

if ($auth->auth['uname'] == 'redakteur_xy') {
...
}

damit kann man bestimmt viel rausholen, als mit

Code: Alles auswählen

if ($perm->have_perm_area_action($my_area, $my_action)) {
...
}

Solche hart codierten Sachen bringen aber Probleme bei der zukünftigen Wartung von Code...

Was man aber machen kann, ist die Menge an 'html' Code bei der Ausgabe zu reduzieren. Da kommt einiges an Output, wenn man viele Kategorien hat, und alle geöffnet sind. Das entlastet den Interpreter und den HTTP-Server.
Zudem können einige Codebereiche in der "include.str_overview.php" optimiert werden.

Die Performance wird sich bei 2-stelliger Kategorieanzahl wohl zw. 10% - 15% einpendeln, ab 100 oder mehr Kategorien ist mit deutlicher Geschwindigkeitszunahme zu rechnen.

Ich werde mich mal der Sache annehmen, vielleicht schaffe ich es, bis heute Abend eine optimierte Version zu erstellen, schaumermal...

Gruß
xmurrix

[emergence]

Solche hart codierten Sachen bringen aber Probleme bei der zukünftigen Wartung von Code...

dem kann ich nur zustimmen... ist ein wahnsinnsaufwand das so zu handhaben...

[emergence]

ich hab jetzt nur mal kurz den code angesehen..

da gibts mehrere passagen ala

Code: Alles auswählen

            ///////// "Kategorie umbenennen" Button
            if($perm->have_perm_area_action($tmp_area, "str_renamecat") || $perm->have_perm_area_action_item($tmp_area, "str_renamecat", $value->id)) {
                    $tpl->set('d', 'RENAMEBUTTON', "<a class=action href=\"".$sess->url("main.php?area=$area&action=str_renamecat&frame=$frame&idcat=".$value->id)."#renamethis\"><img src=\"".$cfg["path"]["images"]."but_rename.gif\" border=\"0\" title=\"".i18n("Rename category")."\" alt=\"".i18n("Rename category")."\"></a>");
            }else{
                    $tpl->set('d', 'RENAMEBUTTON', '&nbsp;');
            }

anstelle der ersten zeile könnte man auch

Code: Alles auswählen

            if($perm->have_perm_area_action_item($tmp_area, "str_renamecat", $value->id)) {

verwenden... (hat den selben effekt, da zu allererst innerhalb der methode have_perm_area_action abgefragt wird...)

bringt vielleicht ne kleine beschleunigung...

[xmurrix]

ich hab jetzt nur mal kurz den code angesehen..

da gibts mehrere passagen ala

Code: Alles auswählen

            ///////// "Kategorie umbenennen" Button
            if($perm->have_perm_area_action($tmp_area, "str_renamecat") || $perm->have_perm_area_action_item($tmp_area, "str_renamecat", $value->id)) {
                    $tpl->set('d', 'RENAMEBUTTON', "<a class=action href="".$sess->url("main.php?area=$area&action=str_renamecat&frame=$frame&idcat=".$value->id)."#renamethis"><img src="".$cfg["path"]["images"]."but_rename.gif" border="0" title="".i18n("Rename category")."" alt="".i18n("Rename category").""></a>");
            }else{
                    $tpl->set('d', 'RENAMEBUTTON', '&nbsp;');
            }

anstelle der ersten zeile könnte man auch

Code: Alles auswählen

            if($perm->have_perm_area_action_item($tmp_area, "str_renamecat", $value->id)) {

verwenden... (hat den selben effekt, da zu allererst innerhalb der methode have_perm_area_action abgefragt wird...)

bringt vielleicht ne kleine beschleunigung...

Das wird auf jeden Fall die Abarbeitung des Scriptes beschleunigen...
Diese Art von Berechtigungsabfragen tauchen im Backend an vielen Stellen auf, ist also ein Punkt, den man vielleicht bei zukünftiger Backend-Entwicklung mit aufgreifen sollte.

Noch ein Bereich ist z. B. die Verwendung der i18n()-Funktion in der Kategorien-Schleife:

Code: Alles auswählen

// schnellere variante
$tmp = i18n("Rename category");
foreach ($objects as $key => $value) {
    $link = '<a href=".$tmp."></a>';
}

// langsamere variante
foreach ($objects as $key => $value) {
    $link = '<a href=".i18n("Rename category")."></a>';
}

Hier ein bisschen, und dort ein bisschen, bringt, nach dem Motto "Kleinvieh macht auch Mist", in der Summe viel

Gruß
xmurrix

[xmurrix]

So,

habe die Datei "include.str_overview.php" etwas auseinander genommen, und an einigen Stellen die Abarbeitung optimiert.

Außerdem ist auch das Template "template.str_overview.html" geändert worden.

Da es sich um viele Änderungen handelt, sollte das Ganze vorerst nicht in einem Produktiveinsatz eingesetzt werden.
Vorher natürlich die DB/Dateien sichern

Nun zum Resultat der Änderungen:
Bei einigen Testdurchläufen mit einem normalen User und 132 Kategorien wurde die Seite in ca. 0.7 Sekunden generiert, vorher waren es ca. 2 Sekunden.
Natürlich sind diese Werte nicht auf andere Contenido-Installationen übertragbar, aber die Tendenz zur Geschwindigkeitssteigerung ist gegeben.

Download:
include.str_overview-redesign.zip

Grüße
xmurrix

[fordor]

Vielen Dank für Eure Mühe.

Werde ich gleich mal austesten...

[emergence]

hab mir das gestern noch ein wenig angesehen...

die änderungen in dem template find ich sehr gut... (wirkt sich massiv in der menge an generiertem html aus...)

das checken der rechte find ich jetzt ganz okay gelöst...
obwohl ich eher dazu dentiere der perm klasse einen cache mechanismus zu verpassen...

die i18n änderungen find ich aber nicht so gut...
und zwar von der wartung her gesehen

Code: Alles auswählen

$aStri18n['Open category'] = i18n("Open category");

ich denk mir da eher das eine zeitverzögerung bei i18n erst dann auftritt wenn die gettext extension nicht geladen wurde...
wenn sie nicht geladen ist, wird ja i18n emuliert und das ist leider ziemlich langsam... eine massive beschleunigung zeigt sich da wenn man innerhalb der contenido.po alle kommentare entfernt...
die strings könnte man da ebenfalls in einer variable cachen...

ich verschieb das mal nach bugs -> ist ja ne sinnvolle sache, das ganze zu beschleunigen...

[xmurrix]

Hallo emergence,

bin mir sicher, dass einiges natürlich besser zu Lösen ist, als ich es gemacht habe. Wollte nicht gleich alles auseinander nehmen

das checken der rechte find ich jetzt ganz okay gelöst...
obwohl ich eher dazu dentiere der perm klasse einen cache mechanismus zu verpassen...

Das habe ich mir auch schon gedacht, Änderungen an Dateien in conlib wirken sich auf das ganze System, deswegen halte ich mich da raus. Möglich wäre z. B. ein zusätzlicher Parameter zum Cachen der Berechtigung.

Code: Alles auswählen

function have_perm_area_action($area, $action = 0, $cache = false)

Damit ist es auch abwärtskompatibel.

die i18n änderungen find ich aber nicht so gut...
und zwar von der wartung her gesehen

Code: Alles auswählen

$aStri18n['Open category'] = i18n("Open category");

Stimmt, das ist nicht so gut.

ich denk mir da eher das eine zeitverzögerung bei i18n erst dann auftritt wenn die gettext extension nicht geladen wurde...
wenn sie nicht geladen ist, wird ja i18n emuliert und das ist leider ziemlich langsam... eine massive beschleunigung zeigt sich da wenn man innerhalb der contenido.po alle kommentare entfernt...
die strings könnte man da ebenfalls in einer variable cachen...

Auch wenn gettext geladen ist, ist das Cachen von mehrfach verwendeten Strings wohl schneller, als das über gettext zu holen. Bei i18n kann ich mir auch einen zusätzlichen Übergabeparameter zu Cachen des Strings vorstellen.

Soweit ich ja mitbekommen habe, kommt bald eine neue Contenido-Version raus, da stellt sich mir die Frage, wieviel Zeit man in solche Änderungen investieren soll.
Vielleicht ist schon einiges integriert, also kann man davon ausgehen, dass die aktuellen cvs-Versionen den aktuellen Entwicklungsstand wiederspiegeln?

Gruß
xmurrix