Adminbereich sehr langsam

[lokbase]

Hi,
ich bin sehr begeistert von den Möglichkeiten die CMSMADESIMPLE in der Programmierung eines Redaktionssystems bietet aber das Arbeiten im Adminbereich ist wirklich extrem langsam. Derzeit pflege ich Daten im Adminbereich ein und benötige unter einer lokalen MAMP-Installation (PHP, MySQL lokal unter Mac) für das Speichern beispielsweise einer News benötige ich ca. 8 Sekunden. Der Aufruf des Seitenindex dauert ebenfalls ca. 8 Sekunden. Je nach offenen Programmen benötige ich für die Anzeige der Hauptübersicht ca. 5 Sekunden. Beim Speichern von Seiten sieht es ähnlich aus.

Andere System sind da viel pflegeleichter. Zum Beispiel ExpressionEngine, das bei mir lokal wesentlich schneller reagiert und nicht weniger komplex ist. 

Natürlich habe ich die bereits abgelaufenen Geschwindigkeitsdiskussionen verfolgt. Trotzdem meine Frage: Ist das bei Euch aktuell auch so? Oder muss ich meine Installation noch mal überprüfen. Gibt es Speed-Tipps? Ich nutze kaum externen Module außer MenuManager, News und FSCK-Editor.

Für Tipps bin ich sehr dankbar.

Liebe Grüße
Matthias

[Piratos]

Solche Zeiten habe ich bei mir mit lokalen Webservern (Windows oder Linux) noch nie beobachtet.

Ein einfacher Trick un etwas zu beschleunigen (das macht den Kohl aber nicht fett) ist die Entfernung aller nicht benötigten Sprachdateien aus dem Ordner admin/lang , die werden nämlich mit der lang.php
und der nachfolgenden Routine ALLE included, egal ob man sie benötigt.

while (($file = $ls->read()) != "") {
if (is_file("$dir/$file") && strpos($file, "nls.php") != 0) {
include("$dir/$file");
}
}

[lokbase]

Hi Piratos,
hat schon was gebracht die Sprachpakete zu entfernen aber nach umstellen auf PHP 5 läuft es jetzt wieder erträglich. Schein wohl ein lokales Problem bei mir zu sein.

Danke für die Info.

Liebe Grüße
Matthias

[Piratos]

na ja den Hauptgrund kann man gut erkennen , wenn man  Phpmyadmin anwirft und sich die Laufzeitinformationen ansieht.

Wer viel zu wenige indexe setzt muss sich nicht über die Geschwindigkeit wundern - das trifft insbesondere den Adminbereich aber auch den allgemeinen Besucherbereich.

[piratos]

Andere Gründe für ein teils gemütliches Verhalten sind fehlende Optimierungen, die sich dann auf den Besucher über unnötige Belastungen des Servers bemerkbar machen können, wenn jemand im Adminbereich arbeitet:

Hier ein Beispiel aus einer Optimierung, die im Adminbereich wirkt
Auszug aus changegroupassign.php

Original:
else if ($group_id != -1 && $submitted != -1)
        {
        // we have group preferences
$query = "DELETE FROM ".cms_db_prefix()."user_groups WHERE group_id = ?";
$result = $db->Execute($query, array($group_id));
foreach ($_POST as $key=>$value)
{
if (strpos($key,"user-") == 0 && strpos($key,"user-") !== false)
{
$query = "INSERT INTO ".cms_db_prefix()."user_groups (group_id, user_id, create_date, modified_date) VALUES (".$db->qstr($group_id).", ".$db->qstr(substr($key,5)).", '".$db->DBTimeStamp(time())."', '".$db->DBTimeStamp(time())."')";
$result = $db->Execute($query);
}
}

audit($group_id, 'Group ID', lang('assignmentchanged'));
        echo ''.lang('assignmentchanged').'';
      }

Optimiert:

else if ($group_id != -1 && $submitted != -1)
        {
        // we have group preferences
$query = "DELETE FROM ".cms_db_prefix()."user_groups WHERE group_id = $group_id ;";
$tstamp = $db->DBTimeStamp(time());
foreach ($_POST as $key=>$value)
{
  if (strpos($key,"user-") == 0 && strpos($key,"user-") !== false)
            $query  .= "INSERT INTO ".cms_db_prefix()."user_groups (group_id, user_id, create_date, modified_date) VALUES (".$group_id.", ".substr($key,5).", ".$tstamp.",".$tstamp.");";
        }
        $result = $db->Execute($query);
audit($group_id, 'Group ID', lang('assignmentchanged'));
        echo ''.lang('assignmentchanged').'';
      }

Der Unterschied besteht darin, das im Original eine Anzahl Queries 1 + Anzahl der User, die wieder einzufügen wären, ausgeführt wird.
Hat man z.B. 10 User einzutragen, wird 11 x Execute ausgeführt.

In der optimierten Version ist es immer nur ein Execute , das abgesetzt wird.
Und es wird auf die Übergabe eines Arrays verzichtet ( $db->Execute($query, array($group_id) ), da an dieser Stelle nicht angebracht, wegen des absolut trivialen Einstzes lohnt es sich nicht den ganzen Rattenschwanz an Abläufen in der Funktion Execute in Gang zu setzen, nur weil man ein Array übergibt.

Im Original wird pro User 2 mal die Funktion DBTimeStamp aufgerufen (also bei den fiktiven 10 Usern = 20 x , in der optimierten Version nur ein einziges Mal.

Ähnliche optimierbare Konstrukte gibt es einige.

Aber in diesem speziellen Fall ist auch klar erkennbar wie gefährlich der Code ist und zwar in beiden Varianten.
Es wird nämlich zuerst einmal alles gelöscht und dann neu aufgesetzt.
Reisst die Verbindung vor oder während der Neueinspielung ab, dann ist alles futsch.

Hinweis:
Der optimierte Code ist für Adodb Lite oder Adodb  Original ausgelegt, da ist DBTimeStamp in '' gesetzt, bei der von CMSMS verwendeten gehackten Version jedoch nicht.

[cyberman]

hat schon was gebracht die Sprachpakete zu entfernen aber nach umstellen auf PHP 5 läuft es jetzt wieder erträglich. Schein wohl ein lokales Problem bei mir zu sein.

Ich weiss zwar nicht, mit welcher CMSms-Version Du arbeitest, aber unter Umständen bringt es auch noch etwas Geschwindigkeit, alle nicht genutzten Module und Tags zu entfernen.

[Piratos]

Module und Tags zu entfernen.

Das bringt leider wie immer nur eine Kleinigkeit - aber die Summe macht's - es ist eine mühselige Sache.