mouth
Willkommen Gast.
Um die volle Funktionalität des Forums nutzen zu können,
müssen Sie sich einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

 
Erweiterte Suche

31.112 Beiträge in 6.477 Themen- von 6.477 Mitglieder - Neuestes Mitglied: Frideborg

06-06-2020 19:33:40
JOOM::GALLERY::FORUMArchivJoomGallery 1.5 MVCBackend / Administrationmax execution time
Seiten: [1]
Drucken
Autor Thema: max execution time  (Gelesen 5817 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
zoomart
Newbie
*
Offline Offline

Beiträge: 6


« am: 25-09-2008 10:44:34 »

Hallo liebes Joom Gallery Team,

ich habe ein Problem mit dem Backendbereich der Joomgallery.

Zunächst eine kleine Historie: Ich habe zuvor die Ponygallery ML benutzt. Das Problem war jedoch, dass Pony alle Fotos in ein einziges Verzeichnis geschreiben hat. Sofern man dann eine Kategorie der Galerie im Backend zur Bearbeitung öffnete, dauerte es sehr lange, manchmal gab es sogar eine execution time out. Ich muss dazu sagen, dass die Galerie mit 4 Kategorien und ca. 900 Unterkategorien läuft. Die execution time liegt derzeit bei 30 sec. Darausschließend habe ich dann per Migration die Joomgallery installiert. Die Fotos und Kategorien wurden perfekt importiert. Die Galerie läuft im Frontend perfekt.

Jedoch gibt es hier genau das gleiche Problem: nach wie vor dauert es sehr lange, bis sich im Backend eine Kategorie beim Klick öffnet. Nun ist es sogar so, dass es immer ein execution time out gibt:

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/web821/html/cms/administrator/components/com_joomgallery/common.joomgallery.php on line 650

Wieso passiert das nur? Es sind doch nun alle Kategorien in Verzeichnisse abgelegt und somit wird doch auch nur das jeweilige Verzeichnis der Bilder geöffnet und die Kategorien sind doch nur Datenbankeinträge.

Vielleicht weiß jemand Rat, ich wäre sehr dankbar.

Gruß

Carsten

Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #1 am: 25-09-2008 22:29:47 »

Hallo Carsten,
bitte trenne Dich von dem Gedanken, dass eine Galerie, die ihre Bilder in einem einzigen Ordner ablegt, grundsätzlich weniger performant läuft als eine Galerie, die eine Ordnerstruktur vorsieht.

Die Ablage der Bilder wurde deshalb eingeführt, um z.B. es aus FTP-Sicht einfacher zu machen, ein bestimmtes Bild auf den Webserver zu finden und gegen ein anderes Bild auszutauschen. Also mehr eine Verbesserung hinsichtlich des Dateihandlings und der allgemeinen Übersicht.

In Deinem Fall vermute ich einen Fehler an einer anderen Stelle (PHP Version, Einbindung von PHP als Modul oder als cgi -nicht fcgi-, schlechte Plattenperformance, schlechte DB Anbindung usw.).
Ein Link zu Deiner Seite würde hier vielleicht weiterhelfen..

Gruß
Andreas

« Letzte Änderung: 25-09-2008 22:39:21 von aHa » Gespeichert
zoomart
Newbie
*
Offline Offline

Beiträge: 6


« Antworten #2 am: 26-09-2008 00:07:06 »

Hallo Andreas,

erst einmal vielen Dank für die rasche Antwort. Hmm, eigentlich möchte ich Links immer vermeiden, aber in diesem Fall wird es sicherlich nicht anders gehen. Ich nennen mal die phpinfo-Url:
http://www.denia-dogs.de/phpinfo.php Ich hoffe es nutzt, da der Fehler ja ausschließlich im Backend auftritt.

Vielen Dank im Voraus.

Gruß

Carsten
Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #3 am: 26-09-2008 09:49:04 »

Hallo Carsten,
so gut ist mein Wissen über Webserver auch nicht, um aus der phpinfo() die langen Laufzeiten erklären zu können.

Mir ist nur aufgefallen, dass dort PHP im CGI Modus läuft (Server API: CGI) statt im schnelleren Fast CGI Modus (Server API: CGI/FastCGI) oder als Apache-Modul (Server API: Apache 2.0 Handler). Das würde aber höchstens allgemein längere Laufzeiten erklären und nicht speziell die in der Galerie.

Die von Dir erwähnte Zeile (common.joomgallery.php on line 650) befindet sich in der Funktion Joom_CatgSub() der aktuellen BETA der JoomGallery. Diese Funktion wird im Backend an verschiedenen Stellen aufgerufen, um die zur Verfügung stehenden Kategorien anzuzeigen, also z.B. im Konfigurationsmanager und im Kategoriemanager. Brechen die Aufrufe immer an der gleichen Stelle ab, z.B bei dem Aufruf des Kategoriemanagers?

In Deinem Falle wäre der Zugang zum Backend am sinnvollsten. Wenn Du magst kannst Du mir einen Account 'Super Administrator' einrichten und mir die Zugangsdaten per PN schicken.

Gruß
Andreas
Gespeichert
zoomart
Newbie
*
Offline Offline

Beiträge: 6


« Antworten #4 am: 26-09-2008 10:29:19 »

Hallo Andreas,

habe Dir ne PN geschickt. Bin jedoch vom 27.09. - 13.10. im Urlaub. Ja, der Abruch ist immer an der gleichen Stelle.

edit 17.30 Uhr: Die execution time wurde nun auf 60 sec. erhöht. Die Kategorien lassen sich nun auch öffnen, jedoch benötigt es ca. 35-40 Sekunden dafür. Das darf doch eigentlich nicht sein. Kann es sein, dass die Galerie ab einer bestimmten Kategorienanzahl im Backend an Performance verliert?

Gruß

Carsten
« Letzte Änderung: 26-09-2008 17:34:40 von zoomart » Gespeichert
aHa
Entwickler-Team
Hero Member
*****
Offline Offline

Beiträge: 2.367


WWW
« Antworten #5 am: 27-09-2008 10:12:56 »

Hallo Carsten,
danke für den Account. Es ist tatsächlich so, dass ab einer bestimmten Anzahl von Kategorien Scriptlaufzeiten erreicht werden, die über
die max_execution_time hinausgehen und zum Abbruch führen.

Ich habe in meiner Testinstallation in der DB 900 kategorien wie bei Dir angelegt und dann den Picture Manager aufgerufen.
Die Laufzeit lag bei ca. 47 Sekunden...

Dies liegt an der Funktion Joom_CatgSub(), die pro Kategorie mindestens einmal aufgerufen wird. Sie ist dafür zuständig, dass in der Auswahlbox, eine Unterkategorie
direkt unterhalb der Parentkategorie angezeigt wird. Teilweise ruft sich diese Funktion rekursiv selbst auf... So summieren sich die Laufzeiten

Zusammengefasst sind diese Funktionen betroffen:
Neue Kategorie anlegen
Kategorie bearbeiten
Picture Manager aufrufen
Neues Bild anlegen (hier sogar Laufzeiten von über 2 min. da dreifacher Aufruf)
Bild(er) verschieben
alle Uploads

Eine primitive Notlösung wäre, den Aufruf der Joom_CatgSub() zu unterbinden. Damit werden dann Scriptlaufzeiten von ca. 0,5 s erreicht.
Nachteil: Die Unterkategorien werden jetzt am Ende der Auswahlbox angezeigt.

Führe diese Änderungen unbedingt auf einer Testinstallation durch.
Grundsätzlich müssen wir uns eine bessere Lösung überlegen...

common.joomgallery.php
Funktion Joom_ShowDropDownCategoryList()
nach Änderung:
Code
function Joom_ShowDropDownCategoryList($cat, $cname = 'cat', $extra = null,
                                      $orig=null) {
 global $database, $my, $func, $jg_category;
 
 $ignore = array();
 $allowedcats = explode(',', $jg_category);
 
 $output = "<select name=\"$cname\" class=\"inputbox\" $extra >\n";
 if ($func!="showupload"){
   $output .= "        <option value=\"0\"></option>\n";
 }
 $query = "SELECT cid, parent
           FROM #__joomgallery_catg"
;
 $query .= " ORDER BY parent, name ASC";
 $database->setQuery($query);
 $rows = $database->loadObjectList();
 
 foreach($rows as $row) {
   //if(($row->parent==0 || $row->parent=="") && !in_array($row->cid, $ignore)) {  DEAKTIVIERT
     //$ignore[] = $row->cid; DEAKTIVIERT
     if($row->cid!=$orig) {
       if(($func!="editpic") || in_array($row->cid, $allowedcats )) {
         $output .="        <option value=\"".$row->cid."\"";
         if($cat==$row->cid) {
           $output .= "selected";
         }
         $output .=">".Joom_ShowCategoryPath($row->cid)."</option>\n";
       }
       //$output .= Joom_CatgSub($row->cid, 1, $rows, $ignore, $orig, $cat, $allowedcats); DEAKTIVIERT
     }
   //} DEAKTIVIERT
 }
 $output .= "      </select>\n";
 
 return $output;
}
 

Gruß
Andreas
Gespeichert
zoomart
Newbie
*
Offline Offline

Beiträge: 6


« Antworten #6 am: 12-10-2008 01:27:09 »

Hallo Andreas,

funktioniert einwandfrei! Super vielen Dank!

Gruß

Carsten
Gespeichert
Seiten: [1]
Drucken
Gehe zu:  

HOSTED BY SCHWARZKÜNSTLER ®

PROTECTED BY  ZB BLOCK  AND Project Honey Pot
Theme orange-lt created by panic

Bad Behavior has blocked 1532 access attempts in the last 7 days.

mouth