cRegistry::getDb();

[samse]

Hi Zusammen

Ich musste kurz heute ein Contenido-Projekt von einem Kunden profilen, da er sich über die Performance im Backend beschwert hat. Dabei ist mir aufgefallen, dass die Funktion

Code: Alles auswählen

cRegistry::getDb();

viel Zeit verbraucht, da immer eine neue cDB-Instanz zurückgegeben wird.
Wäre es nicht klüger, nur eine Datenbank-Instanz zu haben (Stichwort: Singleton)?

Ich habe versucht in der Klasse cRegistry eine neue Membervariable hinzuzufügen und die DB dort zu speichern, sodass ich immer diese zurückgeben kann, aber das hat mir irgendwie 1000 andere Fehler verursacht (Bilder werden nicht dargestellt, AMR funktioniert nicht).

Hat jemand einen Lösungsansatz dafür?

Liebe Grüsse
Samse

[rethus]

Profiling ist schon mal der richtige Ansatz. Mein letzten Profiling hat ergeben, das nicht zwingend die menge der DB-connections die Ursache des Problems ist, es ist vielmehr die exzessive Nutzung von DB Anfragen die aus dem Backend abgefeuert werden.

Somit ist das C-Backend schon mal von Haus aus alles andere als ein Performance-Biest... was bei kleinen Pages aber um so mehr nervt, je größer deine Seiten werden.

Mit der größte Flaschenhals ist der Aufbau des Kategorie-Baums im Backend. Ich hatte das Thema schon mal angeschnitten
viewtopic.php?f=98&t=39028&hilit=teaser+abfragen
und
viewtopic.php?f=98&t=40016&hilit=performance#p174936

Kurzum werden im Backend bei jedem Reload des Bereichs "Content" alle Kategorien und alle darin befindlichen Artikel einmal (bis mehrmals, wenn z.B. Online-Editing & Teaser in den Artikeln verwendet werden) aufgerufen. Wenn du also umfangreiche Kategorien und Artikelstrukturen hast, wäre der erste Ansatz hier zu Entschlacken, wo immer möglich.

Anderer Ansatz ist, aus dem Server rauszuholen was geht.. hier nur als Stichworte: Backend auf HTTPS, Persistente-SQLVerbindung, Query-Cache, Apache-Keep-Alive, File-Caching via htaccess oder gar Umbau auf PWA

Ein Paar weitere Tipps auch hier: viewtopic.php?f=98&t=36630&hilit=perfor ... 15#p172465