Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 21. März 2013 16:08

czarnowski
kennt CMS/ms
Registriert: 18. Oktober 2012
Beiträge: 457

ADOdb lite für InnoDB nicht geeignet

InnoDB liefert 4,6 bis 35 x bessere Performance als die Tabellen vom Typ Myisam.

Das sind Werte, die ich bei meinen eigenen Sachen bestätigen kann.

Wer nun auf die Idee kommt, durch Umstellung der CMSMS Tabellen auf InnoDB profitieren zu können, der wird heftig enttäuscht.

Ursache ist hier die verwendete ADOdb-Version.

Hier ein Vergleich:

cmsms.png

Beitrag geändert von Andynium (24. März 2015 19:28)

Offline

#2 22. März 2013 06:36

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

czarnowski schrieb:

Ursache ist hier die verwendete Adodb - Version.

Bitte den Topic etwas konkretisieren wink - Adodb oder Adodb lite?

Offline

#3 22. März 2013 17:36

czarnowski
kennt CMS/ms
Registriert: 18. Oktober 2012
Beiträge: 457

Re: ADOdb lite für InnoDB nicht geeignet

Die verwendete Adodb ist die Lite.

Offline

#4 23. März 2013 07:24

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

Du ahnst sicherlich schon meine nächste Frage wink

czarnowski schrieb:

Wer nun auf die Idee kommt durch Umstellung der CMSMS Tabellen auf InnoDB profitieren zu können der wird heftig enttäuscht.

Ursache ist hier die verwendete Adodb - Version.

Wie sehen die Ergebnisse mit der Adodb full aus?

(Oder schätze ich deine "Neugier" falsch ein?)

Offline

#5 23. März 2013 11:47

czarnowski
kennt CMS/ms
Registriert: 18. Oktober 2012
Beiträge: 457

Re: ADOdb lite für InnoDB nicht geeignet

Es ist alles eine Frage der Zeit, die man mal abzweigen kann, und davon habe ich leider nicht viel.

Das wird also noch etwas dauern.

Grundsätzlich ist Adodb in allen Formen für Cmsms der reinste Unsinn, da das System nur einen Sinn macht, wenn man diverse DB's unterstützen will, und das ist für Cmsms nicht mehr relevant.

Offline

#6 24. März 2013 23:34

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

czarnowski schrieb:

Grundsätzlich ist Adodb in allen Formen für Cmsms der reinste Unsinn

Mag ja sein, doch ist es die aktuelle CMSMS-Realität, aus der wir das beste machen müssen!

czarnowski schrieb:

InnoDB liefert 4,6 bis 35 x bessere Performance als die Tabellen vom Typ Myisam.

Quelle?

Eine 35fache Beschleunigung der DB-Performance nur durch eine Änderung des Tabellentyps halte ich mit meinen laienhaften MySQL-Kenntnissen für utopisch, insbesondere für CMSMS ...

Offline

#7 24. März 2013 12:50

czarnowski
kennt CMS/ms
Registriert: 18. Oktober 2012
Beiträge: 457

Re: ADOdb lite für InnoDB nicht geeignet

cyberman schrieb:

Quelle?

Das kann man z.B. bei Mysql nachlesen (z.B. http://www.oracle.com/partners/en/knowl … 522945.pdf )

Und  - wer wie ich -  seine Systeme komplett und das seit Jahren auf InnoDB umgestellt hat, der kann es locker bestätigen, wie auch Profianwender es zu ihrer Freude bestätigen können.

Und - wer Mysql 5.6 einsetzt, erzielt mit InnoDB und in der Version möglichen START TRANSACTION READ ONLY  eine  mehr als deutlich höhere Leistung bei einem Endprodukt.

Wer eine Site betreibt, die im Frontend Besuchereingaben ermöglicht, die mit Mysql zu speichern sind, der kommt überhaupt nicht um InnoDB herum, da InnoDB Locking auf Row - Ebene vornimmt, während Myisam die ganze Tabelle sperrt.

Und - InnoDB beherrscht Transaktionen, so dass der alte Zustand hergestellt wird, wenn eine Transaktion z.B. durch Störungen oder Ausfall in die Grütze geht.

Beispiel - wenn man unter CMSMS ein neues Recht zu einer Gruppe einfügt und der Speichervorgang an der blödesten Stelle abgebrochen wird, dann sind alle Eintragungen zu der Gruppe flöten gegangen - nicht mehr vorhanden.
Mit Transaktionen wird der alte Zustand wieder hergestellt, auch wenn man dem Server als Ursache für die Unterbrechung den Stecker gezogen hätte.

Wer im Backend zahlreiche Autoren hat und Myisam einsetzt, der wird mit Sicherheit irgendwann auf dieses Sperrproblem stoßen.

Also die Vorteile von InnoDB sind ein bereits ziemlich alter Hut, und die Vorteile liegen nicht nur in der Geschwindigkeit.

Nicht umsonst ist seit einiger Zeit InnoDB der Default-Tabellentype.

Also man hat mit InnoDB neben besserer Leistung, was Geschwindigkeit betrifft, auch noch andere erhebliche Vorteile.

Beitrag geändert von czarnowski (24. März 2013 13:06)

Offline

#8 24. März 2013 13:56

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

Soweit ich den Test verstanden habe, ist der Vergleich eher theoretischer Natur und bezieht sich auf die mögliche Leistung bei entsprechender Skalierung und wie ich schon sagte, für CMSMS eher utopisch.

Welcher Standard-Hoster, auf denen CMSMS vorwiegend eingesetzt wird, stellt seinen Kunden eine 36-CPU-Core-Maschine zur Verfügung?

Natürlich mag InnoDB seine Vorteile haben, produziert aber gleichzeitig einen gewaltigen Overhead, der die Performance nach unten zieht, siehe dazu auch

https://pseudelia.wordpress.com/2009/05 … nd-innodb/
https://pseudelia.wordpress.com/2009/10 … tatements/

Wie gesagt, es geht mir hier um die praktische Verwendbarkeit deines Tipps für CMSMS (jetzt und heute), welches bislang keine Transactions verwendet.

Offline

#9 24. März 2013 14:17

czarnowski
kennt CMS/ms
Registriert: 18. Oktober 2012
Beiträge: 457

Re: ADOdb lite für InnoDB nicht geeignet

Solange Vergleiche x und y auf der gleichen Maschine und Umgebung ablaufen, ist es völlig egal, was für eine Maschine es ist, da die Relation in der Regel so gut wie gleich bleibt.

Und in der Praxis kann man es locker bestätigen und das auf normalen Maschinen.

Es macht keinen Sinn, alte Kamellen aus 2009 heran zu ziehen, da sich Mysql in allen Bereichen permanent verändert hat.

Transaktionen einzusetzen ist für Systeme völlig normal und jedes System, dass sich auch nur den Hauch von Professionell geben will, kann nicht darauf verzichten.

Stell dir doch einmal vor, beim Verschiebevorgang einer Seite semmelt die Verbindung zum Mysql-Server ab - dann kannst du die komplette Hierarchie in die Tonne treten.

Und - Transaktionen zu verwenden, ist Pippifax einfach - da gibt es nichts kompliziertes.

Also wenn andere es problemlos verwenden können, um mehr Power zu erhalten und vor allem - für mich viel wichtiger - wesentlich mehr Sicherheit in der Anwendung, dann sollte man einen solchen Standard doch einsetzen.

Nur weil Adodb Lite keinen Schimmer von Transaction hat, hat die normale Adodb mit mysqlt sehr wohl die Fähigkeit, Transactions zu verwenden, und das seit Jahren.

Zu empfehlen wäre allerdings PDO.

Offline

#10 24. März 2013 15:04

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

czarnowski schrieb:

Also wenn andere es problemlos verwenden können um mehr Power zu erhalten und vor allem - für mich viel wichtiger - wesentlich mehr Sicherheit in der Anwendung, dann sollte man einen solchen Standard doch einsetzen.

+1

czarnowski schrieb:

Nur weil Adodb Lite keinen Schimmer von Transaction hat hat die normale Adodb mit mysqlt sehr wohl die Fähgigkeit Transactions zu verwenden und das seit Jahren.

Na endlich - war das mühsam, dir diese Aussage zu entlocken ...

czarnowski schrieb:

Zu empfehlen wäre allerdings PDO.

Tja, schön wärs, isses aber im Moment nicht. Und der Schritt zur adodb full wäre vom Umstellungsaufwand her geringer als PDO, zumal dann die Kompatibilität zu allen bislang existierenden Modulen weg ist.

Offline

#11 30. März 2013 22:52

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

czarnowski schrieb:

Nur weil Adodb Lite keinen Schimmer von Transaction hat

Bist du dir da so sicher?

http://adodblite.sourceforge.net/modules.php schrieb:

transaction     Adds transaction support for databases that support it

czarnowski schrieb:

hat die normale Adodb mit mysqlt sehr wohl die Fähgigkeit Transactions zu verwenden

Einen mysqlt Treiber hat aber adodb lite auch (wenngleich der in der aktuellen Distri nicht mehr mitgeliefert wird).

Offline

#12 04. April 2013 01:28

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

czarnowski schrieb:

Nur weil Adodb Lite keinen Schimmer von Transaction hat

Wer Transaktionen verwenden möchte, muss dafür die Datei /lib/adodb.functions.php ergänzen.

Zeile 51 (in CMSMS 1.11.5) ändern von

in

  $str = 'pear:date:extend:transaction';

Offline

#13 04. April 2013 11:13

czarnowski
kennt CMS/ms
Registriert: 18. Oktober 2012
Beiträge: 457

Re: ADOdb lite für InnoDB nicht geeignet

Um Transaction einsetzen zu können, benötigt man

1. die Möglichkeit der Ansprache von Mysql damit und zwar auf dem aktuellen Stand, d.h. diese Möglichkeit muss, was Cmsms betrifft, eingebunden werden - Lite ist da nicht aktuell und auch nicht eingebunden, und kann selbst bei einer Einbindung nicht genutzt werden.

2. Beim Einsatz muss man auf das Ende einer Transaction reagieren, und nicht auf das Ende eines SQL Statements.

Zu 2 mal eine Beispielfunktion

[== php ==]
    function DeleteGroupByID($id) {
        global $db,$config;
        $db->starttransaction();
        $db->Execute("DELETE FROM ".$config['db_prefix']."group_perms where group_id = ?", array($id));
        $db->Execute("DELETE FROM ".$config['db_prefix']."groups where group_id = ?", array($id));
        return $db->endtransaction();
    }

der return Wert ist hier true oder false, true, wenn alles geklappt hat und false, wenn nicht.

Das ist also der Wert, auf den nachfolgend mit Meldung oder entsprechenden Aktionen zu reagieren ist.

Klappt hier z.B. die erste Sql Anweisung einwandfrei, die zweite aber nicht, dann wird false zurück gegeben, der erste erfolgreiche Löschvorgang ist damit hinfällig, d.h. es bleibt alles beim alten, die Tabelleninhalte haben sich nicht verändert.

Also nur über eine DB Klasse Transaction möglich zu machen, reicht nicht - bei CMSMS  müsste man erhebliche Eingriffe vornehmen, um das auch nutzen zu können.

Nutzt man es, dann steigt die Sicherheit enorm.
Bei praktischen Versuchen mit gewaltigen Datenmengen und reichlich Parallelzugriffen und zufallsbedingten provozierten Abstürzen habe ich bislang noch keine einzige Tabelle zerstören können.

Unter Myisam ist das in Nullkommanix zu machen.

Bei den aktuellen Mysql Versionen kann man zudem auch Transactions im read only Modus ausführen  - die bringen beim reinen Lesevorgang (also SELECT ...) nochmals gewaltige Zeitvorteile und auch Vorteile bei zahlreichen parallel ausgeführten Zugriffen (z.B. durch zig Benutzer).

Was CMSMS betrifft, wird man sehr schnell auf ein weiteres Problem treffen.

Anstatt sich bei der Nutzung grundsätzlich voll auf die tatsächlich benötigten Funktionen von ADOdb zu stürzen, die komplette Ergebnisse liefern wie z.B.

$query = "SELECT user_id,content_id FROM ".cms_db_prefix()."additional_users";
$result = $db->GetArray($query);

greift man auf Detailfunktionen zu, die auf ein Resultset des Adodb Ergebnisses wirken
Beispiel:

$query = "SELECT user_id, username FROM ".cms_db_prefix()."users WHERE user_id <> ? ORDER BY username";
$result = $db->Execute($query, array($userid));
if ($result && $result->RecordCount() > 0) {
  while($row = $result->FetchRow()) {
    if( $row['user_id'] == 1 ) continue;
    if( $row['user_id'] == $userid ) continue;
    $addt_users .= "<option value=\"".$row["user_id"]."\">".$row["username"]."</option>";
  }

Das hat zur Folge, dass man selbst bei der Erstellung einer Ersatzklasse diese Stellen ebenfalls abändern muss.

Das habe ich vor Jahren bereits bei einem anderen Produkt gemacht.

Die Arbeit mit Resultsets ist, was Speed und RAM betrifft, eine Katastrophe.

Offline

#14 22. März 2015 19:31

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

cyberman schrieb:

Zeile 51 (in CMSMS 1.11.5) ändern von

in

  $str = 'pear:date:extend:transaction';

Gerade entdeckt ... in der aktuellen Version ist der Eintrag (wieder) drin wink ...

Offline

#15 24. März 2015 19:42

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

cyberman schrieb:

Gerade entdeckt ... in der aktuellen Version ist der Eintrag (wieder) drin wink ...

Pfff ... hab mir heute nen Wolf gesucht, wo die Funktionen genutzt werden - nix, nada, niente ... und dann das

http://adodblite.sourceforge.net/modules.php schrieb:

The Transaction Module will add 10-12k to the libraries memory overhead

Damit geht die Entfernung des transaction Eintrages glatt als Tuning-Tipp durch  cool .

Aber es kommt noch besser

The following is a list of Date functions. The Date Module will add approximately 240k to the libraries memory overhead. It is recommended that you do not load the date functions unless you absolutely need them because of the high overhead.

Und wofür?

Date Database Functions
$db->DBDate($date)
$db->DBTimeStamp($timestamp)
$db->UnixDate($str)
$db->UnixTimeStamp($str)
$db->OffsetDate($dayFraction, $basedate=false) - Mysql/Postgres/MsSql based drivers only
$db->SQLDate($dateFormat, $basedate=false) - Mysql/Postgres/MsSql based drivers only
$db->UserDate($str, [$fmt])
$db->UserTimeStamp($str, [$fmt])


Date Resultset Functions
$result->UnixDate($str)
$result->UnixTimeStamp($str)
$result->UserDate($str, [$fmt])
$result->UserTimeStamp($str, [$fmt])

Kann so auf den ersten Blick nichts erkennen, was den "high overhead" wert wäre ...

Offline

#16 29. März 2015 07:28

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: ADOdb lite für InnoDB nicht geeignet

Ok, Teil 2 führe ich hier weiter, da OT

http://www.cmsmadesimple.de/forum/viewtopic.php?id=4311

Offline