Verblüfft

piratos · 30. November 2010 19:50

Das verblüfft mich etwas:

http://forum.cmsmadesimple.org/index.php?topic=7645.0

NaN · 01. Dezember 2010 13:15

Ach komm schon.
Da sollte einen doch eigentlich nichts mehr überraschen wink

piratos · 01. Dezember 2010 16:52

Also das Ding ist ja uralt und tatsächlich ist die Kritik immer noch gültig - cmsms läuft schneller und ohne Probleme in den beschriebenen Art wenn contentcache.php den Bach runter geht.

Nur die Lösung ist heute eine andere - man tauscht diese Funktion in calss.contentoperations.inc.php aus und der Brei ist gegessen:

Hier klicken, um den Code zum Kopieren zu markieren

function &GetAllContentAsHierarchy($loadcontent = false) {
        debug_buffer('', 'starting tree');
        global $gCms;
        $db = &$gCms->GetDb();
        $tree = null;
        $query = "SELECT id_hierarchy,content_alias FROM " . cms_db_prefix() . "content ORDER BY hierarchy";
        $dbresult = & $db->Execute($query);
        $nodes = array();
        if ($dbresult && $dbresult->RecordCount() > 0) {
            while ($row = $dbresult->FetchRow()) {
                $nodes[] = $row['id_hierarchy'] . ',' . $row['content_alias'];
            }
        }
        debug_buffer('', 'Start Loading Children into Tree');
        $tree = cms_tree_operations::load_from_list($nodes);
        debug_buffer('', 'End Loading Children into Tree');
        $this->LoadChildren(-1, true, true);
        debug_buffer('', 'ending tree');
        return $tree;
    }

läuft noch ein Tick schneller wenn debug_buffer entnommen wird.

piratos · 02. Dezember 2010 13:53

Das ist übrigens die Highspeed Version - poste ich auch nur mal um zu zeigen wieviel Power verpulvert wird, wenn man alles auf Lowlevel macht:

Hier klicken, um den Code zum Kopieren zu markieren

    function &GetAllContentAsHierarchy($loadcontent = false) {
        global $gCms;
        $db = $gCms->GetDb();
        $tree = cms_tree_operations::load_from_list($db->GetCol("SELECT CONCAT_WS(',',id_hierarchy,content_alias) AS nodes FROM " . cms_db_prefix() . "content ORDER BY hierarchy"));
        $this->LoadChildren(-1, true, true);
        return $tree;
    }

Beitrag geändert von piratos (02. Dezember 2010 13:54)

NaN · 02. Dezember 2010 16:44

Das Problem bei derartigem Tunning ist aber, dass Debug-Ausgaben verloren gehen.
Die möchte ich manchmal nicht missen.

debug_buffer sollte allerdings nur dann ausgeführt werden, wenn $config['debug'] = true ist.
(Weiß nicht ob debug_buffer das evtl. selber nochmal macht.)

piratos · 02. Dezember 2010 17:15

Schaut man sich einmal das an:

Hier klicken, um den Code zum Kopieren zu markieren

function debug_buffer($var, $title="")
{
    global $gCms;
    if ($gCms)
    {
        $config = $gCms->GetConfig();

        //debug_to_log($var, $title='');

        if($config["debug"] == true)
        {
          cmsms()->add_error(debug_display($var, $title, false, true));
        }
    }
}

dann sieht man den Aufwand der zig mal betrieben wird und teils auch noch in Schleifen liegt.

Der Nutzen für einen Entwickler liegt nahe bei null, das einzige was interessant sein könnte sind die SQL Ausgaben und die kann man sich von Adodb ausgeben lassen.

Ansonsten ersetzt es weder ein echtes Debug noch ein Profiling und kostet der CMS geschätzt 3..5% Power auch wenn in der config debug auf false ist.

Die Funktion wird bei der Startseite (Demodaten) allein 28 x aufgerufen, davon entalten nur 15 Aufrufe einen Titel.

Wenn dann sollte man die Funktion so aufbauen:

Hier klicken, um den Code zum Kopieren zu markieren

function debug_buffer($var, $title="") {

    global $config;
    if ($config["debug"] == true)
        cmsms()->add_error(debug_display($var, $title, false, true));
}

Beitrag geändert von piratos (02. Dezember 2010 18:02)

NaN · 02. Dezember 2010 19:49

Ich glaube nicht, dass $config['debug'] als Ersatz für ein echtes Debugging bzw. Profiling gedacht ist.
Es ist aber sehr komfortabel und auch von Laien einzusetzen, sodass man auch per Ferndiagnose weiterhelfen kann. Ansonsten müsste man jedesmal vollen Zugriff auf den Server haben. Und das haben die wenigsten.

piratos · 02. Dezember 2010 20:58

Also bis auf die aber auch von anderer Seite (Adodb) beziehbaren SQL Formulierungen reichen die Ausgaben für einen Entwickler in keinster Weise zu überhaupt etwas weil sie nichtssagend sind und für einen Laien sind sie absolut russisch rückwärts.

Auch das Smarty Debug Fenster bringt bis auf die Schrotschussinformationen aller aktuellen Smarty - Vars nichts was man im speziellen Fall geberauchen könnte.

Man entwickelt auch nicht auf einem Produktionsserver sondern entweder auf einem lokalen Server oder in einer Lamp Ungebung.
Debugging und Profiling macht man immer lokal.

NaN · 04. Dezember 2010 01:12

piratos schrieb:

Also bis auf die aber auch von anderer Seite (Adodb) beziehbaren SQL Formulierungen reichen die Ausgaben für einen Entwickler in keinster Weise zu überhaupt etwas weil sie nichtssagend sind

Wie ich schon sagte, es wird auch nicht für den Entwickler gedacht sein.
Mir hilft es, auf einem Produktionsserver Fehlerquellen ausfindig zu machen.
Ob ich diese dadurch dann beheben kann, ist eine andere Sache, aber allein zu wissen wo es klemmt, kann einem eine Menge Zeit ersparen. Meistens packe ich an entsprechender Stelle auch lieber eigene Ausgaben einfach in den Quellcode, um zu sehen was Sache ist, als mich aufs "Debugging" zu verlassen.
Aber wenn ich im Forum unterwegs bin, habe ich als ersten Anhaltspunkt nur diese Debug-Ausgabe des Hilfe-Suchenden.

Außerdem rede ich hier ja nicht von professioneller Entwicklung von Webapplikationen, sondern davon, dass ein lokaler Testserver nur in den seltensten Fällen die gleichen Vorraussetzungen liefert wie ein Produktionsserver. Oft erstellt man eine Seite lokal (ohne großartig irgendwas zu entwickeln; Templates, Stylesheets, paar UDTs - der typische reine Designer-Kram) und muss dann feststellen, dass auf dem gemieteten Webspace nach dem Upload und Einspielen der DB plötzlich nichts so läuft wie in der lokalen Testumgebung. Das ist leider häufig der Fall. Und genau da hilft oft und vor allem schnell der "Debug-Modus".
Und wenn nicht, dann muss eh jemand ran, der sich damit besser auskennt.
Und dann spielt es keine Rolle wie derjenige dem Fehler auf die Schliche kommt.
Ob nun durchs "Debugging" oder durch eigene Ausgaben in Form von kurzen Änderungen am Quellcode.

Und wenn ich selber ein Modul entwickle, dann nutze ich auch lieber die eingebaute Debug-Funktion.
Weil ich die bei Bedarf einfach abschalten kann, wenn alles läuft wie es soll, ohne den gesamten Quellcode jetzt nach Debug-Ausgaben zu durchforsten und nochmal zu ändern.

Es ist einfach nur etwas komfortabler.
Und die paar if-Abfragen... Junge auf was für mickrigen Maschinen hostest Du CMSms, dass ein derartiger Fliegenfurz gleich 3 bis 5 % an Performance ausmachen soll??? Dass kann ich Dir beim besten Willen nicht glauben.

Verzichtest Du etwa auch auf Rückbank, Klimaanlage und Gepäck, nur um mehr PS aus Deinem Auto rauszuholen?
Na dann entspannten Urlaub...

piratos schrieb:

Auch das Smarty Debug Fenster bringt bis auf die Schrotschussinformationen aller aktuellen Smarty - Vars nichts was man im speziellen Fall geberauchen könnte.

Was aber nicht an CMSms liegt.
Soweit ich weiß ist das ein Smarty-Plugin welches von Haus aus mit Smarty ausgeliefert wird.

piratos schrieb:

Man entwickelt auch nicht auf einem Produktionsserver sondern entweder auf einem lokalen Server oder in einer Lamp Ungebung.
Debugging und Profiling macht man immer lokal.

Siehe oben.

piratos · 04. Dezember 2010 13:29

3 bis 5 % an Performance

Nicht reden sondern in der Praxis unter Last ausprobieren !
Ich würde sagen fang da mal mit 50 Besuchern gleichzeitig an und wenn du nicht vorher in Ohnmacht fällst steigere das mal auf 100, 200, 500.

Das ist ein grundsätzliches Problem das lamentiert wird ohne vorher getestet zu haben.

Wenn ich da etwas in Richtung Speed mache ist das immer ausgetestet - das begründet u.a. auch den Speed von P... und den erheblich geringerem Speed von Cmsms.

Und zum Server(n) - da bin ich was Entwicklung betrifft allerbestens ausgestattet - lokal wie auch im Netz.
Entscheiden für mich sind aber Testergebnisse unserer Org live oder im Testfeld, da wir auf einem shared Webserver mit z.Z. 219 Domains und Diensten arbeiten und somit auf einer durchschnittlichen Serverumgebung arbeiten.

NaN · 04. Dezember 2010 13:37

piratos schrieb:

Nicht reden sondern in der Praxis unter Last ausprobieren !
Ich würde sagen fang da mal mit 50 Besuchern gleichzeitig an und wenn du nicht vorher in Ohnmacht fällst steigere das mal auf 100, 200, 500.

Wie ich schoneinmal sagte, wer eine große Internetpräsenz mit entsprechend hoher Besucherzahl betreibt, der muss auch in eine entsprechend performante Umgebung investieren. Wenn Du bei 100 - 500 Besuchern gleichzeitig Probleme bekommst, dann ist entweder Dein Server nicht dafür ausgelegt oder das CMS.
Egal woran es letztendlich liegt, in jedem Fall hast Du Dich für die falsche Technik entschieden.
Dann kannst Du eben leider nicht CMSms einsetzen oder musst einen performanteren Server mieten.
So einfach ist das.
Du scheinst Dich ja bereits für ersteres entschieden zu haben.
Also wo liegt das Problem?

piratos · 04. Dezember 2010 14:21

Dann kannst Du eben leider nicht CMSms einsetzen oder musst einen performanteren Server mieten.
So einfach ist das.
Du scheinst Dich ja bereits für ersteres entschieden zu haben.
Also wo liegt das Problem?

Deine Antwort beschreibt genau das Problem und trifft den Satz

Das ist ein grundsätzliches Problem das lamentiert wird ohne vorher getestet zu haben.

voll.

Also deine Worte sind die eines relativ Ahnungslosen wenn ich das mal auf die Performance von CMSMS beziehen darf und entsprechen mehr denen eines Abwicklers von Hilfefragen aus der Supportecke. Tatsache ist das CMSMS schon bei nur einem Besucher mässige Leistungen zeigt, bei 10..20 aktiven Besuchern geht es steil abwärts, in den meisten Fällen bereits sehr viel früher - das ist das Level einer pofelig besuchten gewerblichen Site.

Stresstest's scheinst du nur aus Beschreibungen zu kennen und nicht aus der Praxis und schon garnicht im Zusammenhang mit CMSMS.
Konkrete Vorschläge zur Verbesserung kann man nicht damit in den Eimer werfen in dem man sagt - performanterer Webserver oder CMSMS ist nicht einsetzbar.

Jeder der also eine kleine Website mit bereits mässigem Besuchereinsatz hat kann also CMSMS in die Tonne werfen oder sich für 150€ einen eigenen Highendserver anmieten - das ist ein prima Ratschlag an alle die damit zu kämpfen haben und genau der richtige um das hier zu promoten.

Das wird ja die paar CMSMS Freunde freuen die sich hier bereits wegen Performanceproblemen gemeldet haben.

Dieser Art des Umganges mit erarbeiteten Lösungsansätzen bei Problemen die bereits vor 5 Jahren erkannt wurden kennen wir ja.

Also nicht lamentieren - ausprobieren - Stresstest machen - Meinung abliefern und nicht lesen und dann blah blah.

NaN · 04. Dezember 2010 14:57

piratos schrieb:

Also deine Worte [...] entsprechen mehr denen eines Abwicklers von Hilfefragen aus der Supportecke.

Was glaubst Du wo Du hier bist und was ich hier mache?
Wenn ich ein professioneller Programmierer wäre, würde ich bestimmt nicht hier in diesem Support-Forum rumhängen.

Aber ich kann hier keinen Support geben, wenn die Debug-Ausgaben fehlen.
Dann muss ich vor Ort sein und alles Stück für Stück auseinander nehmen.
Das kann ich mir zeitlich nicht leisten und der Hilfe-Suchende kann es sich finanziell nicht leisten.

piratos schrieb:

Jeder der also eine kleine Website mit bereits mässigem Besuchereinsatz hat kann also CMSMS in die Tonne werfen oder sich für 150€ einen eigenen Highendserver anmieten

Kann ich nicht bestätigen.

piratos schrieb:

das ist ein prima Ratschlag an alle die damit zu kämpfen haben und genau der richtige um das hier zu promoten.

Im Gegensatz zu Dir und Deinem ominösen P... promote ich hier garnichts.

piratos schrieb:

Das wird ja die paar CMSMS Freunde freuen die sich hier bereits wegen Performanceproblemen gemeldet haben.

Wenn ich mir ein Auto kaufe und mit voll beladenem Kofferraum den Berg nicht hochkomme, dann ist das entweder der falsche Weg, zu viel Gepäck oder schlichtweg das falsche Auto. Ich könnte an dem Auto jetzt rumschrauben, es tunen, tieferlegen, einen anderen Weg nehmen, auf mein Gepäck verzichten und weiß der Geier was... oder ich kaufe mir ein anderes Auto.
Du kannst gern versuchen mit dem Hersteller zu verhandeln, das Fahrzeug so zu modifizieren - und in Serie zu produzieren - dass es auch eine 60° Steigung mit 300 Kg Gepäck bei jedem Wetter ohne Probleme überwindet, aber ich fürchte er wird Dir eher einen Vogel zeigen bzw. ein anderes Modell empfehlen.

piratos schrieb:

Dieser Art des Umganges mit erarbeiteten Lösungsansätzen bei Problemen die bereits vor 5 Jahren erkannt wurden kennen wir ja.

Du kannst hier erzählen was immer du willst, die if-Abfrage bei der Debug-Funktion ist definitiv nicht die Wurzel irgendwelcher Performanceprobleme.

Ich wollte doch lediglich darauf hinaus, dass man zwar Deinen geposteten Vorschlag umsetzen kann, aber dadurch auf eine Funktion verzichten muss, die man evtl. irgendwann mal brauchen könnte.
Es bleibt jedem selbst überlassen, wofür er sich letzendlich entscheidet, ob einem die paar % mehr Performance wert sind oder lieber doch nicht.
Aber diese Debug-Ausgabe generell als Performance-Killer oder absolut unsinnig abzustempeln ist so nunmal nicht korrekt.
Für Entwickler taugt sie nichts, okay. Das wissen wir beide.
Aber für die ist sie meiner Meinung nach ja auch nicht gedacht.

piratos · 04. Dezember 2010 16:09

Wenn man den Code nicht lesen kann ok dann verstehe ich ein paar Dinge.
Und wer die Zusammenhänge nicht verbindet der kann auch nur Bahnhof verstehen.

Es geht um contentcache.php - die vorgeschlagene Lösung bringt etwas und noch mehr wenn CMSMS in einem Umfeld im Einsatz ist wo ein CMS als solches auch eingesetzt wird, nämlich mit vielen Backendusern die ständig Inhalte ändern.

Der Rauswurf der debug_buffer Sache aus der contentcache Funktion hat deinen Protest hervorgerufen - du brauchts das.

In der Funktion contentcache.php spielt der Gewinn nach der Entfernung vom debug_buffer keine große Geige.

Wer es aber generell braucht redet vom generellen Einsatz.
Da bringt die Nutzung debug_buffer praktisch nichts, spart aber eine Menge ein.

Wer also Code nicht lesen kann und auch die Ansage ignoriert das allein bei den Demodaten im Frontend die Funktion 28 x aufgerufen wird, der sollte sich das erklären lassen.

Und es geht nicht um eine IF Abfrage.

Hier klicken, um den Code zum Kopieren zu markieren

global $gCms;
    if ($gCms)
    {
        $config = $gCms->GetConfig();

        //debug_to_log($var, $title='');

        if($config["debug"] == true)
        {
          cmsms()->add_error(debug_display($var, $title, false, true));
        }
    }
}

#
1. Abfrage ob gCms vorhanden ist oder nicht.
2. Wenn ja die Variable config nochmals lokal zuweisen.
3. Dann Abfrage ob config gesetzt wird, wenn ja ausführen oder nicht.

Und das 28 mal bei der Standardinstallation.
Und das erhöht sich drastisch nach Seitenzahl - wenn ich da an den User mit den schönen Festtagsgedichten denke hat das eine direkte Bremswirkung.
Und der Aufwand kann sich noch ziemlich ausdehnen wenn weitere Module eingesetzt werden.

Da reden wir absolut nicht über Penauts sondern schon über einen Snickers.

Hoffe das dies nun klar ist - es sind hier zwei Dinge .- die Ausgangslage contentcache.php und debug_buffer.

Jeded CMS sollte in der Lage sein in der Standardausstattung auf einem normalen Qualitäts - Shared - Webserver mindestens 20 Besucher gleichzeitig bedienen zu können.

Vergleicht man diverse Produkte auf dem gleichen Testserver per Stressprogramm sieht CMSMS nicht gerade gut aus.

Wer also da locker sagt hast den falschen Webserver oder kannst CMSMS nicht einsetzen der promoted den Abgang - das sollte man nicht machen, wirkt abschreckend.

Und - Thema eine IF Abfrage : eine If Abfrage kostet rund 300 Bytes und etwas Zeit im Fliegeschissformat.
Bei Performance ist es normal so, das extrem viele Fliegenschisse erst den Haufen machen.

Es gibt relativ wenige Dinge die gleich Elefantenmist bedeuten.
contentcache.php und das Menüsystem sind Elefantenmist.

Beitrag geändert von piratos (04. Dezember 2010 16:31)

NaN · 04. Dezember 2010 18:03

piratos schrieb:

Der Rauswurf der debug_buffer Sache aus der contentcache Funktion hat deinen Protest hervorgerufen - du brauchts das.

Ich habe nicht protestiert.
Ich habe auch nicht gesagt, dass Du unrecht hast.
Ich wollte lediglich auf etwas hinweisen.
Denn im Forum wird zur Fehleranalyse als erstes häufig geraten, $config['debug'] = true zu setzen.
Das sage ich jedem, der keine nennenswerten Angaben zu seiner CMS Installation machen kann bzw. wo aus diesen Angaben keine Fehlerquellen erkennbar sind oder ich einfach keine Ahnung von dem Modul habe und bevor ich das jetzt installiere, ausprobiere und mich durch den Code wühle...

Nach Deinem Tunning kann man mit dieser Antwort allerdings noch weniger anfangen als vorher.
Ich wollte nur als "Abwickler von Hilfefragen aus der Supportecke" anmerken, dass damit auch der Verlust einer Funktion einhergeht, die in den meisten Fällen von den "Abwicklern von Hilfefragen aus der Supportecke" bisher immer als erstes verwendet wurde, um Fehler zu finden.
Darum ging es mir.

Ob sie nun so viel Performance frisst oder nicht, wenn sie weg ist und einer der "Abwickler von Hilfefragen aus der Supportecke" angeboten hat, ihre Ausgabe auszuwerten, was soll der betreffende User dann sagen?
Hier kann man sagen "Öhm... da iss nüscht! Ach ja, ich hab übrigens von Piratos das Tunningdingens angewendet. Das wo man hier mit der Contentcache und nix debug_buffer mehr. Kann das damit zusammenhängen?"

Im .org Forum würde man schon bei der bloßen Erwähnung Deines Namens beinahe gebannt werden.

piratos schrieb:

[...]
Elefantenmist
[...]
Fliegenschiss
[...]
Fliegenfurz
[...]
Wenn man den Code nicht lesen kann
[...]

Und so wie Du hier auftrittst, wundert es auch überhaupt nicht, dass dort niemand mehr mit Dir zu tun haben will.

piratos · 04. Dezember 2010 19:19

Und so wie Du hier auftrittst, wundert es auch überhaupt nicht, dass dort niemand mehr mit Dir zu tun haben will.

Ich denke gerade darüber nach aus welchen Gründen man hier ein Forum erstellt hat und wie denn ausgerechnet solche Leute wie du hier zum Moderator gebracht haben.
Du hast ein ähnliches Kaliber wie CG allerdings nicht von gleicher Güte.

NaN · 04. Dezember 2010 19:50

Vielleicht bin ich einfach nur ein netter Kerl wink

Lass gut sein, Jan.
Ich habe keine Lust mich mit Dir zu streiten.
Du has Recht.
P... hat immer recht.

@all:
P... ist einfach besser!
Mehr Performance!
Mehr Komfort!
Mehr Support!
Supergeiles Design!
Und hat nach eigenen Angaben des Entwicklers nichts mehr mit dem öden CMSms zu tun.
Warum der Chefentwickler von P... allerdings dennoch ständig hier rumhängt, darf er euch in seinem Forum selbst erklären.

Andynium · 06. Dezember 2010 08:25

piratos schrieb:

Ich denke gerade darüber nach aus welchen Gründen man hier ein Forum erstellt hat

Dieses Forum ist und bleibt eine Supportplattform für den freien Gedankenaustausch rund um CMS made simple, basierend auf den aktuellen Versionen. Jede KONSTRUKTIVE Mitarbeit ist hier herzlich willkommen.

Dieses Forum ist jedoch weder eine Läster-Plattform noch ein Werbe- oder Vergleichsportal für Smarty-basierte CMS-Systeme, sei es nun ImpressCMS, BigACE oder auch P.

Ich habe nix gegen einen Blick über den Tellerrand, aber ich dachte, ich hätte mich klar genug ausgedrückt, dass hier KEINE Werbung für Fremdsysteme erwünscht ist, sei es direkt oder nur subtil.

Forum für CMS/made simple

#1 30. November 2010 19:50

Verblüfft

#2 01. Dezember 2010 13:15

Re: Verblüfft

#3 01. Dezember 2010 16:52

Re: Verblüfft

#4 02. Dezember 2010 13:53

Re: Verblüfft

#5 02. Dezember 2010 16:44

Re: Verblüfft

#6 02. Dezember 2010 17:15

Re: Verblüfft

#7 02. Dezember 2010 19:49

Re: Verblüfft

#8 02. Dezember 2010 20:58

Re: Verblüfft

#9 04. Dezember 2010 01:12

Re: Verblüfft

#10 04. Dezember 2010 13:29

Re: Verblüfft

#11 04. Dezember 2010 13:37

Re: Verblüfft

#12 04. Dezember 2010 14:21

Re: Verblüfft

#13 04. Dezember 2010 14:57

Re: Verblüfft

#14 04. Dezember 2010 16:09

Re: Verblüfft

#15 04. Dezember 2010 18:03

Re: Verblüfft

#16 04. Dezember 2010 19:19

Re: Verblüfft

#17 04. Dezember 2010 19:50

Re: Verblüfft

#18 06. Dezember 2010 08:25

Re: Verblüfft

Fußzeile des Forums