Freitag, 24. April 2015

Cmsmadesimple.de optimiert falsch

So wie man es bei cmsmadesimple.de probiert sollte man es nicht machen:

<?php
$start1 = microtime(1);
for ($i = 0; $i < 100000; $i++)
{
phpversion();
}
$diff1 = microtime(1) - $start1;
echo "<p>Test 1: Laufzeit phpversion() ohne @: " . $diff1 . "</p>\n";

$start2 = microtime(1);
for ($i = 0; $i < 100000; $i++)
{
phpversion();
}
$diff2 = microtime(1) - $start2;
echo "<p>Test 2: Laufzeit phpversion() mit @: " . $diff2 . "</p>\n";
?>

Damit meine ich die Ermittlung einer Startzeit und die Differenzausrechnung mit einer Endzeit.
Damit wird lediglich die zu überprüfende Funktion x mal aufgerufen nicht aber das Script welches das beinhaltet.
Die dynamischen Ergebnisse  - also der x malige Aufruf einer Seite entsprechende der Anzahl X User kann ein völlig anderes Ergebnis zeigen.

Um es zu checken verwendet man z.B. das Programm Siege.

Was bei cmsmadesimple.de immer wieder ignoriert wird - die richtig dicken Dinger stecken in falscher Programmierung und falschen Konzepten.

Dienstag, 21. April 2015

Cmsmadesimple - deutsche Anwender nicht willkommen

Wer als Deutscher Cmsms  einsetzen möchte hat als Hilfsquelle praktisch nur noch die deutsche Fraktion von cmsmadesimple.de zur Verfügung oder man nimmt die englischsprachigen Foren von Cmsmadesimple.org.

Aber die eingesetzte Moderatorin für den deutschen Bereich von cmsmadesimple.org hat definitiv keine Ahnung von Details - andere User stehen für Hilfsaktionen offenbar nicht zur Verfügung.

Die von der amerikanischen und deutschen Seite sind sich aus diversen Gründen nicht grün.

Der Betreiber der deutschen Fraktion wird aktuell zur  Persona non Grata erklärt und andere Anwender der deutschen Fraktion titulieren den Hauptdeveloper von Cmsms als Arschloch oder empfehlen dem schleunigst einen Arzt aufzusuchen.

Tatsächlich ist die Führungsqualität und die Ansprache der Anwender von der amerikanischen Seite her sehr seltsam.

Allein die Foren - Unterschrift des US Hauptdevelopers spricht Bände:

if you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
----------------
Don't make me angry..... you won't like me when I'm angry....
Klar ist das man weder über deren Bugtracker noch  zu einem Featurerequest überhaupt eine Reaktion erwarten kann.

Ja selbst dann nicht wenn man einen Bug meldet und deren Lösung gleich dazu liefert ( siehe hier ).

Bei der Entwicklung der Cms selbst wurden in den letzten Jahren lediglich Bugs beseitigt und Kleinigkeiten geändert die kosmetischer Natur sind.

Die Cms in der Version 2, welche unlängst mit "coming soon" angekündigt wurde ist im starken Zeitverzug, hat wiederum rein nichts was dem System weiter hilft und erst recht nicht ist es eine Runderneuerung.

Diverse Dinge sind bei Cmsms einfach fehlerhaft  und einige Dinge sind vom Konzept her nicht mehr ausreichend und sogar falsch.
Es wird nur noch Mysql unterstützt, man verwendet aber ein kleines Layersystem Adodb Lite das seit vielen Jahren nicht gewartet wird.
Indexe die man benötigt sind nicht angelegt, Indexe die man nicht benötigt sind angelegt  und nur wenige brauchbare Indexe sind angelegt aber deren Verwendung wird nicht angestoßen.
Die Aufbereitung des Menüs ist eine Krankheit und hat ein Niveau eines Anfängers.
Smarty wird vollkommen falsch eingesetzt und und und .

Cmsmadesimple belegt mit der Version 2 seinen Stillstand.
Die Gesamtleistung (Speed) ist bereits bei den paar Demoinhalten denkbar mies.
Für richtig große Web's ist Cmsms die Garantie für Erfolglosigkeit - die Langsamkeit ist kaum noch zu überbieten.

Tatsächlich sollte jeder der ein CMS einsetzen möchte es sich sehr genau überlegen ob er Cmsmadesimple einsetzen möchte oder nicht.

Freitag, 17. April 2015

file_exists oder filemtime - Optimierungsblödsinn

Ausgehend von einer Bemerkung einer der Smarty - Entwickler der angab, man werde nun filemtime statt file_exists einsetzen hat man in der deutschen Fraktion nun langsam auswuchernde Test's damit veranstaltet.
Is_file ist auch eine Option allerdings sind die einsetzbaren Wrapper nicht identisch mit den anderen Methoden.

Ausufernd ist es nun deshalb weil niemand gecheckt hat warum und wieso Smarty das macht.

Smarty schreibt als Kommentar im Quelltext seiner Klasse

 Smarty deliberately uses @filemtime() over file_exists() and filemtime() in some places. Reasons include
                - @filemtime() is almost twice as fast as using an additional file_exists()
                - between file_exists() and filemtime() a possible race condition is opened,
                  which does not exist using the simple @filemtime() approach.

filemtime taucht als Wort bei Smarty 41 mal in 15 Scripten auf und es geht immer darum den Timestamp einer Datei zu ermitteln.
Das ist eine Angabe die Smarty laufend benötigt um z.B. den Ablauf von Cachedateien zu ermitteln oder einen Vergleich Template-Quelldatei und compilierte Datei vornehmen zu können um einen eventuell notwendigen Bedarf einer Neucompilierung festzustellen.

Die Zeitnachteile dieser Methode der dann eintritt, wenn eine Datei nicht vorhanden ist nimmt man bewusst in Kauf, da dies relativ selten vorkommt.
Die Zeitvorteile überwiegen also sehr stark und deshalb ist es richtig.

Und genau deshalb ist es falsch das als Wohltat für andere Teile von Cmsms anzusehen.


Da heißt die bessere Alternative für file_exists ist is_file, wobei is_file nur auf lokal einsetzbar ist und im Rahmen der Rechte.
Mit file_exists sind auch Zugriffe auf eine URL möglich.
Aber genau das sollte man aus Sicherheitsgründen eben nicht einsetzen.

Der Tausch von file_exists nach is_file in den reinen Cmsms Teilen (also ohne Smarty) bringt eine Erhöhung des Speed um 13% und das ist doch recht ansehnlich.
Die kürzeste Transactionzeit reduziert sich sogar von 0.34 Sekunden auf 0.11 Sekunden.

Und damit dürfte klar sein  was man machen sollte.

Optimierer sollten sich immer darüber im klaren sein warum jemand eine bestimmte Optimierung einsetzt und ob es gut für einem selbst ist.

Und man sollte immer unter Last prüfen (Siege) ob es sich lohnt.

Auf der anderen Seite wird einem immer mehr klar das solche Gedanken dem eigentichen Developer offenbar völlig fremd sind.
Betreibt man Entwicklung so wie es bis jetzt bei Cmsms geschieht ist es kein Wunder das man eine lame duck gezüchtet hat.

Donnerstag, 16. April 2015

Bugreport bei Cmsmadesimple

Nun doch noch schnell ein kleiner Beitrag zu Cmsmadesimple.
Interessant der Beitrag von Calguy1000 zum Thema Bug - Beseitigung.

In vielen Punkten hat er zweifelsohne Recht.

Die Arbeit an dem Projekt wird nicht bezahlt.
Aber - die Entlohnung kommt über  Projekte die man über Cmsmadesimple herein holt.

Das kann die Erstellung von Websites sein , Einrichtung oder Installationsproblembeseitigung aber auch individuelle Programmierung dazu.

Es ist also immer ein Spagat zwischen Familie, Freizeit und Einkommenserwerb auf der einen Seite und der Arbeit an dem Cmsms Projekt.

Klar ist - beschreibt jemand einen Fehler exakt und kann angeben wie man ihn reproduziert, dann ist es für den Entwickler sehr viel einfacher den Fehler oder die Ursache zu finden und ihn gegebenenfalls zu beseitigen.

Das Problem ist aber - der normale Cmsms Anwender kann es nicht so exakt beschreiben wie der Programmierer es hätte.

Und - in den allermeisten Fällen schreibt er dazu etwas im Forum und nicht in dem Bugtracker.
Und schriebt er dann auch mal etwas in den Tracker stößt er auf einen Programmierer der keine Lust hat sich mit ungenauen Dingen zu beschäftigen.

Aber auch der Programmierer selbst muss mit dem Kopf gegen die Wand gerannt sei, denn schauen wir uns einmal die erste Seite des Bugtrackers an ergibt sich eine interessante Darstellung:


Wir sehen da uralte und akzeptierte und zugewiesene Meldungen ohne weitere Reaktion.
Wir sehen uralte, akzeptierte Meldungen die an niemanden zugewiesen wurden.
Wir sehen eine Anzahl Meldungen mit der Resolution fixed aber mit dem Status Open.
Und wir sehen auch Meldungen bei denen rein nichts passiert ist.

In der Vergangenheit hat man nach ein paar Jahren die uralten nie abgearbeiteten Dinge einfach gelöscht wohl in der Annahme das die sich über die zwischenzeitlich  abgelieferten neueren Versionen erledigt haben.

Das grundsätzliche Problem bleibt aber erhalten - die meisten Nutzer von Cmsmadesimple sind Anwender und keine Programmierer.
Sie bemerken wohl das da etwas nicht richtig läuft können aber den Rahmen nur relativ ungenau beschreiben.
Sie suchen im Forum nach Lösungen und wenn sie nichts finden halten die meisten die Klappe.
Kann man mit dem Fehler noch leben arbeitet man vielleicht weiter mit Cmsms ansonsten wendet man sich einem anderen Produkt zu.

Und es gibt eine stattliche Anzahl von schwerwiegenden Bugs die so einfach für niemanden zu erkennen sind weil die Software funktioniert.
Sie funktioniert - die Frage ist nur wie.
Es macht einen großen Unterschied aus wenn eine Routine 35 mal ein Haus mit 10 Stockwerken hoch laufen muss um einmal sein Ergebnis abzuliefern oder ob sie einmal mit dem Fahrstuhl fährt.
Und viele von den Bugs gibt es schon seit rund 10 Jahren.

Und es gibt massive grundsätzliche Fehler im Programmlayout die dazu führen das die Software zwar funktioniert aber ätzend langsam.

Was Robert Champbell nicht begriffen hat ist das Geheimnis jeglicher erfolgreicher Software - Teamwork, Delegation von Aufgaben , vernünftige Kontrolle und beide Ohren bei den Kunden sprich Abnehmern von Cmsms zu haben.
Dann kommt er auch privat mit seinem Einkommenserwerb, Familie und Freizeit klar.

Moderatoren sollten ihre Ohren bei den Anwendern haben und aufkommende Probleme von sich aus im Tracker melden - machen sie aber in der Regel nicht.
Grund - so mancher Moderator hat keine Kenntnisse die für eine für Champbell wohlwollende Formulierung ausreichen würde.

Es gäbe eine ganze Anzahl von Möglichkeiten die aber alle daran scheitern werden weil Champbell als Führungskraft praktisch nicht geeignet ist - das hat er mehrfach in den letzten Jahren unter Beweis gestellt.

Klar ist das der vorhandene Bugtracker wie auch die nun für jedermann klare Einstellung von Champbell dazu die reinste Anwenderverscheuchung ist.
Das habe eine Menge Leute begriffen die Champbell offenbar für Dummköpfe hält.

Mittwoch, 15. April 2015

Speed Version Cmsms V2 B3

Hier mal Cmsms V2 B3 mit allen Optimierungen die ich mal für Cmsmadesimple  vorgeschlagen hatte und die man in die Tonne getreten hat.

Hier bis auf Menüsystem und fehlendem Adodb 100% kompatibel zur Originalversion.

Gemessen auf Highspeed Server lokal und das sind die traumhaften Ergebnisse:

siege -b -t10S -c100 http://localhost/cmsms
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:      152340 hits
Availability:      100.00 %
Elapsed time:        9.97 secs
Data transferred:       43.75 MB
Response time:        0.01 secs
Transaction rate:    15279.84 trans/sec
Throughput:        4.39 MB/sec
Concurrency:       98.08
Successful transactions:       76222
Failed transactions:           0
Longest transaction:        0.12
Shortest transaction:        0.00

Das System ist so schneller als der Server verarbeiten kann. Ursache ist hier Smarty - das Templatesystem kann nicht folgen.


Und nun die Originalversion Cmsms 2 B3 - wie ausgeliefert gemessen auf dem gleichen Server.
siege -b -t10S -c100 http://localhost/cmsmsorg/
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:         465 hits
Availability:      100.00 %
Elapsed time:        9.60 secs
Data transferred:        2.17 MB
Response time:        1.82 secs
Transaction rate:       48.44 trans/sec
Throughput:        0.23 MB/sec
Concurrency:       88.09
Successful transactions:         465
Failed transactions:           0
Longest transaction:        2.96
Shortest transaction:        0.92


Das nur mal um Cmsms - Anwendern zu zeigen was möglich gewesen wäre.

Damit habe ich nun mal eine Marke abgeliefert und ich sage voraus - das wird bei Cmsms nie Realität werden.
Dazu sind die Macher komplett nicht geeignet. Sie könnten es sicher auch aber ihre sonstigen Fähigkeiten bezüglich dem Team reichen nicht um das durchzuziehen.
Und - es mangelt bei denen an Entscheidungsfreudigkeit.

Um es auch gleich noch anzusagen - ich werde weder konkreten Code, noch konkrete Hinweise zu den Optimierungen und garantiert nicht den geänderten Quellcode oder gar das famose Menüsystem (1 SQL Abfrage!) an irgend jemanden abgeben, weder umsonst noch gegen Bezahlung.

Dafür bin ich zu oft von immer den gleichen Leuten in den Arsch getreten worden.

Und damit ist für mich die Serie der Beiträge für Cmsmadesimple hier zunächst beendet.
Ich melde mich wieder wenn die V2 stable ausgegeben wird.

Cmsmadesimple V2 B3 - kein Speedwunder

Auf einem extrem schnellen exklusiven Webserver mit aktuellster Software, Hardware vom schnellstem inkl. 64 GB RAM und reinem SSD Betrieb liegt der Knickpunkt von Cmsmadesimple bei 30 Besuchern die gleichzeitig auf einer mit Cmsms erstellten Website herum surfen.

Die Leistung lässt rapide nach und das System ist unter diesen Bedingungen bereits ab 50 Besucher nicht mehr professionell verwendbar.

Es ist klar das diese Serverkonfiguration im oberen Bereich angesiedelt und nicht alltäglich ist.
Man darf erwarten das auf normalem Webspace die Leistung sehr viel früher abfällt und Cmsmadesimple dann bestenfalls nur noch für Sites geeignet ist mit extrem wenigen Besuchern.

Eine solche Leistung führt auch dazu das man auf Dauer nicht mit einem großartigen Anstieg der Besucherzahlen rechnen darf.


Optimierung messen - oder wie Dick und Doof am Kopf kratzen

Die deutsche Fraktion versucht sich tatsächlich an Kleinoptimierungen in einem etwas größerem Umfang und bedient sich schlauerweise auch bei den Ergebnissen von Herstellern von ganz anderen Produkten.

Auch das ist sehr positiv zu sehen.

Aber es gibt bei der Fraktion immer die gleichen Heinis die sich bereits früher meist mit negativen Kommentaren zu Ergebnissen zu Wort gemeldet haben, ja auch versuche etwas nachzuvollziehn aber zu keinem Ergebnis kommen.

Zitat:
Der Benchmark von GMoS Tews hätte mich mal interessiert. Denn wenn ich das in einem PHP Script teste, stelle ich da nur einen einen Performance-Unterschied von durchschnittlich ca. 1% fest - wenn die Datei existiert. Und dabei wechselt der Gewinner ständig.
Wenn die Datei nicht existiert, liegt filemtime() im Durchschnitt mit ca. 10% hinter den beiden Funktionen is_file() und file_exists() zurück. Ich wüsste echt gerne wie der auf diese Zahlen kommt.

Man misst die Erfolge einer Optimierung unter lokaler Last.
Das bedeutet  - man befeuert ein Testscript eine Zeit lang mit virtuellen Usern.

Auf mich bezogen wird da Siege als Programm verwendet und zwar  wie folgt:

siege -t10S -c100 http://localhost/cmsms/speedtest.php


Und damit auch ordentlich etwas passiert erfolgt der Test - hier in der speedtest.php in einer Schleife wo das alles 10.000 mal aufgerufen wird.

Beispiel:

<?php

$i=0;
while ($i<10000)
{
    $ok=filemtime('index.php');
    $i++;
}    

Die Ergebnisse des Siege - Laufes sind die welche interessieren.

Nehmen wir das Beispiel des Moderators der mal wieder nichts versteht.

Die Ergebnisse:

file_exists

siege -t10S -c100 http://localhost/cmsms/speedtest.php
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:        1120 hits
Availability:      100.00 %
Elapsed time:        9.28 secs
Data transferred:        0.00 MB
Response time:        0.30 secs
Transaction rate:      120.69 trans/sec
Throughput:        0.00 MB/sec
Concurrency:       36.60
Successful transactions:        1120
Failed transactions:           0
Longest transaction:        0.56
Shortest transaction:        0.02

 is_file

 siege -t10S -c100 http://localhost/cmsms/speedtest.php
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:        1892 hits
Availability:      100.00 %
Elapsed time:        9.88 secs
Data transferred:        0.00 MB
Response time:        0.03 secs
Transaction rate:      191.50 trans/sec
Throughput:        0.00 MB/sec
Concurrency:        5.54
Successful transactions:        1892
Failed transactions:           0
Longest transaction:        0.16
Shortest transaction:        0.00

filemtime

siege -t10S -c100 http://localhost/cmsms/speedtest.php
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:        1700 hits
Availability:      100.00 %
Elapsed time:        9.01 secs
Data transferred:        0.00 MB
Response time:        0.03 secs
Transaction rate:      188.68 trans/sec
Throughput:        0.00 MB/sec
Concurrency:        5.89
Successful transactions:        1700
Failed transactions:           0
Longest transaction:        0.16
Shortest transaction:        0.00

Die Ergebnisse sprechen für sich und entsprechen auch den Ergebnissen die ich für PowerCms vor einigen Jahren ermittelt und umgesetzt habe.

Entscheidend sind beim Test immer die Anzahl der Transactions pro Sekunde - je mehr ausgeführt werden können desto besser.

Wir haben hier also bei der Erkennung der Leistung  immer damit zu tun das wir dynamisch testen müssen.
Es nützt rein nichts etwas in einer Schleife laufen zu lassen und dann über eine Start - und Endzeit  die Laufzeit zu berechnen.
Entscheidend ist immer - wie verhält es sich wenn eine Anzahl von Besuchern auf eine Seite zugreifen - also unter Last.

Bei dem Moderator ,der das nicht kapierte, haben wir es genau mit dem Typ zu tun der aus simplen Unverständnis auch in der Vergangenheit so manche Optimierungen zerredet hat.
Eine Anzahl anderer Cmsms Anwender die noch weniger verstehen - weil sie grundsätzlich von der Programmierung und Technik keine Ahnung haben - heulten dann immer mit dem Leitwolf und schon war so etwas bereits unten durch.

Bei Cmsmadesimple stellt sich unverändert seit über 10 Jahren die Frage ob die Entwickler irgend etwas übernehmen werden.

Die Leute die heute in der deutschen Fraktion da herum testen waren immer genau die, welche stets der Meinung waren, das es sinnlos ist Verbesserungen einzuführen, weil die Entwickler davon nichts annehmen und beim nächsten Update eigene Änderungen futsch sind.

Nachtrag:

Messungen wenn eine Datei nicht existiert:

<?php

$i=0;
while ($i<10000)
{
    $ok=file_exists('indexos.php');
    $i++;
}    

file_exists

siege -t10S -c100 http://localhost/cmsms/speedtest.php
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:        1268 hits
Availability:      100.00 %
Elapsed time:        9.60 secs
Data transferred:        0.00 MB
Response time:        0.24 secs
Transaction rate:      132.08 trans/sec
Throughput:        0.00 MB/sec
Concurrency:       31.48
Successful transactions:        1268
Failed transactions:           0
Longest transaction:        0.59
Shortest transaction:        0.02

is_file

siege -t10S -c100 http://localhost/cmsms/speedtest.php
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:        1772 hits
Availability:      100.00 %
Elapsed time:        9.82 secs
Data transferred:        0.00 MB
Response time:        0.05 secs
Transaction rate:      180.45 trans/sec
Throughput:        0.00 MB/sec
Concurrency:        9.07
Successful transactions:        1772
Failed transactions:           0
Longest transaction:        0.28
Shortest transaction:        0.01


filemtime

siege -t10S -c100 http://localhost/cmsms/speedtest.php
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.

Transactions:          25 hits
Availability:      100.00 %
Elapsed time:        9.96 secs
Data transferred:        2.07 MB
Response time:        4.03 secs
Transaction rate:        2.51 trans/sec
Throughput:        0.21 MB/sec
Concurrency:       10.11
Successful transactions:          25
Failed transactions:           0
Longest transaction:        9.46
Shortest transaction:        0.00

filemtime ist der Verlierer.
Auch hier sind die Differenzen gewaltig.

Man muss aber beachten das file_exists auch über Wrapper auf URL's zugreifen kann während is_file rein lokal arbeitet.

Bevor man also file_exists in is_file ändert muss man wissen ob das Sinn macht.

Dienstag, 14. April 2015

Optimierungsansätze der deutschen Fraktion

Interessant ist das der Betreiber der deutsche Cmsmadesimple Fraktion einige Ansätze für Optimierungen prüft und Alternativen dazu anbietet.

Teils interessant, teils aber auch daneben weil  das Ganze Programmsystem noch nicht durchschaut wurde.

Aber egal - grundsätzlich ist das ein richtiger Ansatz.

Es gibt jedoch 4 Dinge dabei zu beachten

1. Cmsmadesimple.org hat sich von allen Ansätzen anderer Personen über die Jahre hinweg nicht beeindrucken lassen und buchstäblich nichts daraus gemacht.
Da die Fronten zwischen DE und der ORG von Cmsmadesimple verhärtet sind dürfte auch von daher rein nichts übernommen werden.

2. Kleinoptimierungen haben eine Wirkung die sich aus der Summe der Kleinoptimierungen und vor allem der dadurch verminderten Last des Servers ergibt . Die Last eines weniger optimierten Systems steigt mit der Anzahl der gleichzeitig wirkenden Besucher abrupt in ziemliche Höhen. Vermindert man diese durch Kleinoptimierungen dann setzt die Lastkurve viel sanfter an.

3. Grundsätzliche Strukturprobleme in der Programmierung sind mit Kleinoptimierungen NIE gut zu machen. Aber von diesen Problemen gibt es reichlich siehe auch hier .

4. Es gibt überall reichlich Programmierdummköpfe die von dem allen rein nichts verstehen, aber ihren Senf dazu geben und solche Dinge damit blockieren. Volltrottel die über mangelnde Geschäfte bei Printmedien zum Webdesign kommen und schon bei den kleinsten Problemen bei der Installation oder beim Server nicht mehr weiter wissen.
Das sind Leute die sehen die wenigen Millisekunden Vorteil einer Kleinoptimierung und sagen laut - das lohnt sich nicht. Die haben tatsächlich nichts verstanden und sollten lieber die Klappe halten bevor ein Endkunde so etwas sieht und dann nur noch den Kopf schüttelt.
Jeder der ein System wie Cmsms verwendet muss ein sehr großes Interesse daran haben das die lieferbare Leistung eines solchen Systems für den Endkunden optimal ist - ein Web besteht schließlich nicht nur aus Design sondern auch aus der Technik die Design und Inhalte abliefern soll.

Montag, 13. April 2015

Sinn oder Unsinn ?

Der Betreiber der deutschen Fraktion schrieb heute das:

http://forum.cmsmadesimple.de/viewtopic.php?pid=34202#p34202

Recht hat er.

Aber seine Aussage trifft auch noch auf folgendes zu - die Funktion cms_db_prefix wird 683 mal in den Quellen der CMS benannt und ausgeführt.

Sie soll den Tabellenprefix vor den Tabellennamen setzen.
Den Prefix kann der Anwender der CMS bei der Installation bestimmen.
Das macht er einmalig.

Was aber macht die Funktion genau ?

Sie ruft ihrerseits die Funktion GetDbPrefix.
Die soll nun den in cmsms()->dbprefix gehaltenen Prefix zurück geben wenn vorhanden oder den aus der config holen und dann zurück geben.

Schaut man sich aber GetDbPrefix() genauer an so fehlt da die Zuweisung an cmsms()->dbprefix so das bei Verwendung von cms_db_prefix tatsächlich jedes mal neben GetDbPrefix auch GetConfig aufgerufen wird.

Ich habe mal GetDbPrefix modifiziert mit einer hochzählbaren Variablen.
So wird diese Flut von Funktionsaufrufen auf der Home Seite von Cmsms 2.0 Beta 37 x ausgeführt.

Auch alles überflüssig wenn man den Prefix einmal als Konstante überführt hätte (siehe Thema der deutschen Fraktion).

Solche  und  noch ganz andere poofelige Fahrlässigkeiten  sind überall im Quellcode zu finden.
Qualität und Qualitätskontrolle sind vollkommen unbekannt.

/**
 * Returns the currently configured database prefix.
 *
 * @since 0.4
 * @return string
 */
function cms_db_prefix() {
  return cmsms()->GetDbPrefix();
}

Zum Test geänderte Funktion:

public function GetDbPrefix()
{   static $i;
if( $this->dbprefix ) return $this->dbprefix;
                $i++;
$config = $this->GetConfig(); echo "Hallo ".$i;
return $config['db_prefix'];
}

Die insgesamt korrigierte Funktion:

public function GetDbPrefix()
{
if( $this->dbprefix ) return $this->dbprefix;
             
$config = $this->GetConfig();
                $this->dbprefix = $config['db_prefix'];
         
return $config['db_prefix'];
}

Das CMSMS Dev Problem - zu wenig Ahnung von Mysql

Wer sich die Struktur der verwendeten Mysql Tabellen  anschaut stellt fest - es wurden teils  massiv Indexe angelegt.
Das hört sich gut an denkt man doch das Mysql damit schnellere Abfragen ausführt.

Aber ob diese Indexe tatsächlich jemals zum Einsatz kommen - das hat bei Cmsms wohl niemand geprüft. Es schaut so aus als wenn man gedacht hätte das Mysql sich schon einen passenden Index bei Abfragen auswählen würde.

Tatsächlich kommen die meisten Indexe nie zum Einsatz.

Aber sie müssen von Mysql geführt und somit verwaltet werden. Ein Absturz während eines Schreibvorganges und diese teils zahlreichen Indexe und der Tatsache das man keine Transaktionen verwendet können das aus für die Tabelle oder DB bedeuten.

Hier ein ganz einfaches Beispiel an Hand Originalabfrage.

SELECT * FROM cms_modules ORDER BY module_name

Das führt dazu das Mysql ein Filesort ausführt.
Filesort ist aufwendig und belastet den Server.

Die bessere Variante wäre die Mysql mitzuteilen welchen Index verwendet, denn der hier nutzbare Index der liegt vor:

SELECT * FROM cms_modules FORCE INDEX (cms_idx_modules_by_name)

Diese Abfrage führt zu einem simplen Select ohne jeglichen Sortierungsaufwand da die Sortierung über den Index bereits vorliegt.

Der Unterschied bei dieser kleinen Abfrage mit wenigen Einträgen in der Tabelle mag hier klein sein.

Aber andere Tabellen sind größer und vor allem die Tabellen werden ausgelöst vom Besucher abgefragt und verursachen kumuliert eine enorme Mehrbelastung des Servers.

Das Endergebnis - de Site selbst wird deutlich langsamer .

Halten wir fest

  • es gibt jede Menge Indexe
  • Indexe werden aber meist nicht verwendet
  • Indexe die man hätte gebrauchen können gibt es nicht.


Diese Situation ist im übrigen kein Einzelfall sondern die Regel.
Das deutet darauf hin das die Developer von Cmsms eigentlich keine wesentlichen Kenntnisse von Mysql haben.

Nachtrag:

Hier noch ein weiteres Beispiel aus dem Adminbereich

Original Netto SQL:
SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_idhier) WHERE content_id IN (1,2,3,4,5,6,7,8,9,10,11,22) ORDER BY hierarchy
Fabriziert:
Using index condition; Using filesort

Bessere SQL:
SELECT * FROM cms_content FORCE INDEX (cms_idx_content_by_hier) WHERE content_id IN (1,2,3,4,5,6,7,8,9,10,11,22)
Fabriziert:
Using where

Man hat offenbar für die Originalabfrage irgendwann mal den darin angegebenen Index angelegt.
Der Index in der besseren Abfrage war schon vorhanden.

Der Unterschied - die Originalabfrage ist 1/3 langsamer als die bessere.

Das Problem ist aber immer generell - unnötige Belastungen des Servers, Mysql und der PHP Umgebung ziehen alles runter.

Manch Möchtegernoptimierer sieht immer nur die realen Ergebnisse einer einzigen Optimierung und meint dann - lohnt nicht - solche sehen das Ganze nicht und fallen rein.



Sonntag, 12. April 2015

Cmsms - nicht nur doppelt sondern 15 fach

Das Cmsms nicht besonders gut programmiert ist weiß jeder der sich damit beschäftigt hat.

Die Version 2 ist zwar noch Beta aber auch hier ist die schludrige und falsche Programmierung Pflicht.
Wer sich nur aus den Demoinhalten zB. die Seite event-manager anschaut und das Ende der index.php so ergänzt hat:

print_r($smarty);  // das ist die Änderung
exit();
?>

der findet den Inhalt dieser Seite glatte 15 mal bei Smarty gespeichert und nicht nur das sondern auch fast alles andere.
Glatter Fall von rekursivem Aufruf immer und immer wieder.

Das sind Fehler die passieren einem Anfänger. Aber auch der würde das über diesen simplen Testaufruf bemerken.

Die Developer von Cmsms aber merken anscheinend nichts mehr.

Menü - ja doch oder nicht - Cmsms lame duck menu

Das Menüsystem - und das ist nichts neues - ist von Anfang an bei Cmsmadesimple sehr bescheiden konstruiert worden.

Extrem viel PHP Einsatz und reichlich Mysql Abfragen für etwas was andere System mit minimalem Aufwand gelöst haben.

Wer sich das mal genauer anschaut muss erkennen . die verantwortlichen Dev's hatten zum Zeitpunkt der Erstimplementation keine große Ahnung  von Mysql.

Ja selbst die Basis dieses Hierarchie - Systems stammt aus fremder Feder.

Der Knackpunkt heute ist der , das für das Menü viel zu viel Kosten entstehen und das Gesamtsystem extrem nach unten ziehen.

Hier nun mal ein paar Basis - Beispiele von SQL Abfragen - mit  DB Demodaten Cmsms 2.0 wie man ansetzen kann.
Abfrageteile wie auf active oder show_in_menu fehlen der Übersicht wegen.



1-
SELECT * FROM `cms_content` WHERE LOCATE('00003.00007', hierarchy)=1 ORDER BY hierarchy


Holt Parent  und alle Subeinträge zu 00003.00007





2.
SELECT * FROM `cms_content` WHERE LOCATE('00003.00007.', hierarchy)=1 ORDER BY hierarchy

Holt alle Subeinträge zu 00003.00007 jedoch nicht Parent Level 1




3.
SELECT * FROM `cms_content` WHERE LOCATE('.', hierarchy)=0 ORDER BY hierarchy

Holt alle Level 1 Einträge


4.
SELECT * FROM `cms_content` WHERE LOCATE('.', hierarchy)=0   OR LOCATE(hierarchy,'00003.00007.00003' )=1 ORDER BY hierarchy

Holt alle Level 1 wie den Parent der 00003.00007.00003


Wie gesagt das sind Basisabfragen die man leicht ändern kann um sich sein Menü zu bauen.

Es ist möglich das gesamte bisherige Menügedröhne von Cmsms in eine einzige wenn auch umfangreiche Mysqlabfrage zu packen.
Das habe ich mal der deutschen Fraktion angeboten - die haben aber abgelehnt weil die 300€ denen zu viel waren.

Vielleicht findet sich ja jemand der sich etwas auskennt und es mal selbst versucht.

Nachtrag:

Abfrage 4  kann man hervorragend z.B. für Breadcrumbs verwenden  Beispiel:

SELECT * FROM `cms_content` WHERE  LOCATE(hierarchy,'00004.00001.00003' )=1 ORDER BY hierarchy




Und diese Basis kann man für die Ermittlung von Prev und Next einsetzen:

SELECT * FROM `cms_content` WHERE
 (
        hierarchy = IFNULL((select min(hierarchy) from `cms_content` where hierarchy > '00004.00001.00003'),0)
        or  hierarchy = IFNULL((select max(hierarchy) from `cms_content` where hierarchy < '00004.00001.00003'),0)
      )




Nachtrag:

Wer in den Breadcrumbs auch den Link zu Startseite haben möchte - der setzt das hier ein.
Man beachte FORCE INDEX -  Mysql wird den vorhandenen Index nutzen . man erspart sich die Sortierung über ORDER BY.

SELECT * FROM `cms_content` FORCE INDEX (cms_idx_content_by_hier) WHERE  LOCATE(hierarchy,'00004.00001.00003' )=1 OR default_content =1


Samstag, 11. April 2015

Profiling nur mit Zielen im Visier

PHP - Programme lassen sich mit Xdebug debuggen . Mit Xdebug kann man aber auch elegant Profiling durchführen.

Profiling ist richtig und wichtig denn nur so erkennt man Schwachstellen im Code aber auch in der Struktur.

Es geht dabei immer darum die bestmöglichste Leistung heraus zu holen.

Was diese bestmögliche Leistung aber sein soll, wo ihre Grenze liegen muss das sollte man vorher genau definieren, denn optimieren kann man ohne Ende.

Bei einem weiten Fortschritt geht es dann aber nur noch um sehr kleine Erfolge.

Die Optimierung sollte man dann abbrechen wenn das gesetzte Ziel unter allen Umständen erreicht wird.

Wichtig ist die grafische Aufbereitung  eines Profilerlaufes.
So kann man sofort erkennen wo man zu suchen hat.

Die Auflistung nach ausgegebenen Kosten (Zeiten) ist zudem sehr hilfreich.

Auch hier kann man sehr gut ansetzen um Code zu untersuchen und sich nebenbei Gedanken über die richtige Struktur von Code und Daten zu machen.

Häufig genug ist eine mangelnde Leistung eine Sache eben mangelhafter Programmstrukturen - eine Optimierung in Codedetails wird dann nie den erhofften Leistungsschub bringen sondern immer nur Kleinkram.

Der Kleinkram in der Summe kann es in sich haben wird aber nie schwerwiegende Strukturfehler ausgleichen.

Grafische Aufbereitungen liefern ein direktes Bild wo viel Zeit verbraten wird. Stehen einzelne Klassen und Funktionen in Bezug um eine bestimmte Aufgabe zu lösen und sind die Grafiken groß hat man einen Anhaltspunkt auf schwerwiegende Strukturfehler.
Im blauen Bild klar zu erkennen -  die Aufbereitung der Navigation bei Cmsmadesimple kostet viel zu viel - ein ganz klarer Fall eines fehlerhaften Ansatzes.

Zudem ist auch zu erkennen ob man eine Rekursion bewusst oder versehentlich verwendet.
Hier - wieder bei Cmsmadesimple ist es wohl mangelnder Durchblick über Zusammenhänge einzelner Programmteile.
Rekursion in einem komplexen Umfeld führt zu einem enormen Leistungsabfall.



Schaut man sich das alles sortiert nach Kosten an fallen einem sofort Sachen auf die so eigentlich nicht vorhanden sein dürften.
Auch hier - bei Kenntnis der Zusammenhänge zeigt es sich deutlich - die Aufbereitung des Menüsystems ist voll daneben.

Donnerstag, 9. April 2015

Cmsmadesimple - aus gehabten Fehlern nichts gelernt

Die groß angekündigte Cmsmadesimple Version 2 befindet sich im Zeitverzug und ist mit der Beta3 noch ziemlich weit entfernt von einer stable Version.

Davon einmal abgesehen sind die tatsächlichen Neuerungen  nicht so groß wie man sie anpreist und zerstören aber weitgehend  die Kompatibilität mit den 1 er Versionen.

Das wäre alles in Kauf zu nehmen wenn man denn endlich mal einen Schnitt gemacht hätte die zu einer radikalen Verbesserung geführt hätten.

Darunter sind insbesondere zu verstehen


  • multilinguale Fähigkeiten
  • Abkehr von der Uraltversion von Adodb Lite und Einsatz von PHP PDO::Mysql
  • Abkehr von der seltsamen Suchmethode und Zuwendung zu Mysql Fulltext
  • Einsatz von Transactionen
  • Modernisierung der Aufbereitung der Menüaufbereitung
  • richtiger Einsatz von Smarty
  • Dramatische Erhöhung der Arbeitsgeschwindigkeit
Multilingual ist sehr einfach - das hatte ich bei Powercms innerhalb von 2 Tagen eingebaut.
Zusatzfeld mit 2 Buchstaben für den ISO Ländercode und alle Manipulatiosn - und Darstellungsteile angepasst inkl, der Session - fertig ist der Salat und sehr viele Anwender von CMS würden eine Alternative in Cmsmadesimple sehen können.
Über Adodb Lite oder die große Version da müssen wir nicht großartig reden.
Ein Layersystem dann einzusetzen wenn man nur Mysql unterstützt ist der größte Unsinn überhaupt.


Und Lite ist in der Pflege seit vielen Jahren  gestorben.

Warum man Mysql Fulltext nicht unterstützt liegt auch in der anfänglichen Unterstützung von mehreren DB Systemen - das aber ist seit einiger Zeit hinfällig geworden.

Keine Transactions einzusetzen ist heute tödlich. Ein immer möglicher Abriss während eines Mysqlvorganges der schreibt kann den Tod der Datenbank bedeuten.

Die Menüaufbereitung ist derart poofelig vorgenommen worden das daraus eine richtige Bremse wurde (siehe Profiling).

Smarty wird verbogen eingesetzt und dann noch recursiv - das ist der Hauptgrund warum Smarty der Hauptbremser ist.

Eine dramatische Erhöhung der Arbeitsgeschwindigkeit um Faktor 4..5 ist möglich wenn man die bereits genannten Hauptpunkte berücksichtigt.

Bei der Verteilung der Leistung muss man zwei Situationen unterscheiden

1. die Templates müssen von Smarty compiliert werden - Bild1























2. die Templates sind bereits compiliert Bild 2

Im ersten Fall geht der Löwenanteil an Smarty - dieses Tempatesystem hat am meisten zu tun.

Im zweiten Fall ist es Cmsmadesimple das Leistung aufsaugt.

Deutlich erkennbar - die Aufbereitung des Menüsystems taugt rein nichts.

Diese Umstände sind auch in der folgenden Grafik ersichtlich:



Was bedeutet das alles.
Cmsmadesimple V2 taugt nicht mehr oder weniger als die V1 Linie.
In den wesentlichen Dingen hat sich rein nichts getan.

Die Leistung reicht nicht für professionelle Anwendungen aus - man kann zwar solche damit erstellen - der Erfolg solcher Anwendungen hängt aber direkt von der Kürze der Präsentationszeit ab und da leistet Cmsms viel zu wenig.

Nachtrag:

Das Profiling hier wurde mit der verbesserten und aktuellen Smarty Version vorgenommen.

Mittwoch, 1. April 2015

Adodb Betrachtungen und Cmsmadesimple

Cyberman der Moderator und die Antriebsfeder von cmsmadesimple.de hat sich offenbar Adodb  und Adodb Lite angesehen und glaubt da Performancebremsen gefunden zu haben.

Performancebremse zum einen wegen erhöhtem RAM Verbrauch und Nichtnutzung von Adodb Modulen und die Verwendung von unterschiedlichen Funktionen die aber angeblich das gleiche ausführen.

Schwierig das zu verfolgen da er mal von Adodb und mal von Adodb Lite spricht.

GetAll und GetArray soll identisch sein.

Schauen wir mal in das Adodb Manual:

GetAll($sql,$inputarr=false)

Executes the SQL and returns the all the rows as a 2-dimensional array. The recordset is discarded for you automatically. If an error occurs, false is returned.GetArray is a synonym for GetAll.

GetArray([$number_of_rows])

Generate a 2-dimensional array of records from the current cursor position, indexed from 0 to $number_of_rows - 1. If $number_of_rows is undefined, till EOF.

Wer das liest muss zu der Meinung kommen das in dem Manual etwas nicht stimmen kann.

GetAll führt eine SQL aus während GetArray das hier nicht macht sondern ab Cursor solange liest bis number_of_rows erfüllt ist.

Ergebnis: CMSMS nutzt gerade mal 51% der von ADOdb lite bereit gestellten Funktionen. Im Bereich der Extensions ist das Bild noch etwas dramatischer - da sind es gerade mal 31% Nutzung (bei knapp 290k Overhead)

Hier wird klar von der Lite Version gesprochen.
Das Problem von externen Libs besteht darin das andere Programmierer eine solche Lib kennen und verwenden wollen und dann natürlich auch die darin angebotenen Funktionen die natürlich nur dann nutzbar sind wenn sie eingebunden wurden.

Und diese Funktionen sind ganze Sammlungen in einem Modul.

Module wie date oder transaction sind nicht zu verwechseln mit PHP Date und ähnliches.

Date ermöglicht den Zugriff auf die Mysql Date Funktionen (https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html) bzw verwenden / ermöglichen sie in Abfragen, Date - Funktionenvon Mysql sind eine der wichtigsten Funktionen unter Mysql überhaupt - ohne die wäre Mysql nahezu wertlos.

Transaction einzubinden wenn keine genutzt werden ist natürlich Unsinn - Cmsmadesimple verwendet z.Z. keine Transaktionen.
Bei einem defekten Speichervorgang wird der alte Zustand nicht wieder herbeigeführt, d.h. man hat u.U. eine defekte Tabelle. Erfolglose Transaktionen führen jedoch den alten Zustand herbei und geben eine Meldung ab auf die man reagieren sollte , ja muss.

Die Version  2 von Cmsmadesimple soll eine Datensatzsperrung vornehmen (über eine Zweittabelle), so das eine weitere Person nicht darauf zugreifen kann.

Das führt dann zu Problemen wenn ein Programmlauf beendet wird ohne das die Sperrung aufgehoben wurde.

Also tatsächlich ist es müssig das alles mal zu vergleichen denn hinsichtlich Adodb  ist es so, das Cmsmadesimple nur Mysql unterstützt und aus dem Grunde ein Adodb System völlig überflüssig ist da man alles was Mysql betrifft direkt unter PHP zur Verfügung gestellt bekommt.