Artikel editieren: Langes Warten auf assets

Diarmiud · 4. Januar 2017

Hallo,
auf einer meiner Joomla-Seiten dauert der Aufruf zum Editieren eines Artikels im Backend eeeeewwwwwwwiiiiiiggggggg. Genauso das Abspeichern. Leider werde ich aus der Debug-Meldung nicht schau. Irgendein Abruf in der _assets dauert jeweils mehrere Sekunden. Ich vermute, dass da ein Eintrag in der Tabelle fehlt? Versteht vielleicht jemand das Problem und kennt einen Lösungsansatz? Dank vorab!

Die Debug-Meldung (Auszug)

Zitat

SELECT b.rules

FROM j16_assets AS a

LEFT JOIN j16_assets AS b
ON b.lft <= a.lft
AND b.rgt >= a.rgt

WHERE (a.name = '' OR a.parent_id=0)

ORDER BY b.lft
Erklären
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE a index_merge idx_asset_name,idx_parent_id idx_asset_name,idx_parent_id 202,4 NULL 616 100.00 Using union(idx_asset_name,idx_parent_id); Using where; Using temporary; filesort wurde genutzt
1 SIMPLE b ALL idx_lft_rgt ES KONNTE KEIN INDEX-SCHLÜSSEL GENUTZT WERDEN NULL NULL 4172 100.00 Range checked for each record (index map: 0x4)

Abfragezeit: 2486.00 ms Nach letzter Abfrage: 7.42 ms Abfragespeichernutzung: 0.102 MB Speichernutzung vor Abfrage: 13.637 MB Zeilen zurückgegeben: 622

SELECT b.rules

FROM j16_assets AS a

LEFT JOIN j16_assets AS b
ON b.lft <= a.lft
AND b.rgt >= a.rgt

WHERE (a.id = 2683 OR a.name = 'com_content' OR a.parent_id=0)

ORDER BY b.lft
Erklären
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE a index_merge PRIMARY,idx_asset_name,idx_parent_id PRIMARY,idx_asset_name,idx_parent_id 4,202,4 NULL 617 100.00 Using union(PRIMARY,idx_asset_name,idx_parent_id); Using where; Using temporary; filesort wurde genutzt
1 SIMPLE b ALL idx_lft_rgt ES KONNTE KEIN INDEX-SCHLÜSSEL GENUTZT WERDEN NULL NULL 4172 100.00 Range checked for each record (index map: 0x4)

Abfragezeit: 2543.80 ms Nach letzter Abfrage: 0.32 ms Abfragespeichernutzung: 0.102 MB Speichernutzung vor Abfrage: 13.663 MB Zeilen zurückgegeben: 621

SELECT b.rules

FROM j16_assets AS a

LEFT JOIN j16_assets AS b
ON b.lft <= a.lft
AND b.rgt >= a.rgt

WHERE (a.id = 2587 OR a.name = 'com_content' OR a.parent_id=0)

ORDER BY b.lft
Erklären
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE a index_merge PRIMARY,idx_asset_name,idx_parent_id PRIMARY,idx_asset_name,idx_parent_id 4,202,4 NULL 617 100.00 Using union(PRIMARY,idx_asset_name,idx_parent_id); Using where; Using temporary; filesort wurde genutzt
1 SIMPLE b ALL idx_lft_rgt ES KONNTE KEIN INDEX-SCHLÜSSEL GENUTZT WERDEN NULL NULL 4172 100.00 Range checked for each record (index map: 0x4)

Alles anzeigen

Und oben beim Debuggen:

Zitat

Zeit: 24.38 ms / 24.38 ms Speicher: 0.490 MB / 0.82 MB Application: afterLoad
Zeit: 199.86 ms / 224.24 ms Speicher: 4.779 MB / 5.59 MB Application: Start JAccess::getAssetRules Old (1)
Zeit: 2.05 ms / 226.29 ms Speicher: 0.026 MB / 5.62 MB Application: Finish JAccess::getAssetRules Old (1)
Zeit: 44.42 ms / 270.71 ms Speicher: 1.055 MB / 6.68 MB Application: afterInitialise
Zeit: 28.39 ms / 299.10 ms Speicher: 0.417 MB / 7.09 MB Application: afterRoute
Zeit: 2.73 ms / 301.83 ms Speicher: 0.009 MB / 7.10 MB Application: beforeRenderComponent com_content
Zeit: 797.72 ms / 1099.55 ms Speicher: 6.430 MB / 13.53 MB Application: Start JAccess::getAssetRules Old (2683)
Zeit: 0.87 ms / 1100.41 ms Speicher: 0.011 MB / 13.54 MB Application: Finish JAccess::getAssetRules Old (2683)
Zeit: 13.34 ms / 1113.76 ms Speicher: 0.088 MB / 13.63 MB Application: Start JAccess::getAssetRules Old ()
Zeit: 2335.39 ms / 3449.15 ms Speicher: 0.109 MB / 13.74 MB Application: Finish JAccess::getAssetRules Old ()
Zeit: 0.31 ms / 3449.45 ms Speicher: 0.000 MB / 13.64 MB Application: Start JAccess::getAssetRules Old (2683)
Zeit: 2494.81 ms / 5944.26 ms Speicher: 0.109 MB / 13.75 MB Application: Finish JAccess::getAssetRules Old (2683)
Zeit: 1.61 ms / 5945.87 ms Speicher: 0.000 MB / 13.66 MB Application: Start JAccess::getAssetRules Old (2587)
Zeit: 2555.84 ms / 8501.71 ms Speicher: 0.110 MB / 13.77 MB Application: Finish JAccess::getAssetRules Old (2587)
Zeit: 45.98 ms / 8547.69 ms Speicher: 0.158 MB / 13.93 MB Application: afterRenderComponent com_content
Zeit: 1.02 ms / 8548.71 ms Speicher: 0.002 MB / 13.93 MB Application: afterDispatch
Zeit: 4.22 ms / 8552.93 ms Speicher: 0.123 MB / 14.05 MB Application: beforeRenderModule mod_submenu (Admin Submenu)
Zeit: 3.83 ms / 8556.76 ms Speicher: 0.028 MB / 14.08 MB Application: afterRenderModule mod_submenu (Admin Submenu)
Zeit: 3.75 ms / 8560.51 ms Speicher: 0.015 MB / 14.10 MB Application: beforeRenderModule mod_status (User Status)
Zeit: 7.24 ms / 8567.75 ms Speicher: 0.023 MB / 14.12 MB Application: afterRenderModule mod_status (User Status)
Zeit: 0.11 ms / 8567.86 ms Speicher: 0.000 MB / 14.12 MB Application: beforeRenderModule mod_cachecleaner (Regular Labs - Cache Cleaner)
Zeit: 5.74 ms / 8573.60 ms Speicher: 0.019 MB / 14.14 MB Application: afterRenderModule mod_cachecleaner (Regular Labs - Cache Cleaner)
Zeit: 0.35 ms / 8573.95 ms Speicher: 0.000 MB / 14.14 MB Application: beforeRenderModule mod_toolbar (Toolbar)
Zeit: 26.59 ms / 8600.55 ms Speicher: 0.046 MB / 14.18 MB Application: afterRenderModule mod_toolbar (Toolbar)
Zeit: 0.21 ms / 8600.76 ms Speicher: 0.000 MB / 14.18 MB Application: beforeRenderModule mod_title (Title)
Zeit: 3.46 ms / 8604.22 ms Speicher: 0.004 MB / 14.19 MB Application: afterRenderModule mod_title (Title)
Zeit: 0.19 ms / 8604.41 ms Speicher: 0.000 MB / 14.19 MB Application: beforeRenderModule mod_menu (Admin Menu)
Zeit: 30.97 ms / 8635.38 ms Speicher: 0.152 MB / 14.34 MB Application: afterRenderModule mod_menu (Admin Menu)
Zeit: 13.87 ms / 8649.25 ms Speicher: 0.442 MB / 14.78 MB Application: afterRender

Alles anzeigen

chr-hl · 5. Januar 2017

Moin und willkommen,

von welcher J-, PHP- und MySQL-Version sprechen wir hier?
Anzahl der Beiträge?
Zusätzliche Erweiterungen im Einsatz?
Datenbank reparieren versucht?

Christian

Diarmiud · 11. Januar 2017

Upps, sehe erst jetzt, dass doch eine Antwort erfolgt ist. Vielleicht ist die Benachrichtigungsmail im Spam gelandet ...

Zunächst danke für die Nachfrage.

Das Langsamkeits-Problem im Backend zieht sich nun schon mehrere Updates durch. Ich weiss nicht mehr, bei welcher Joomla Version es zuerst auftrat. Ich hoffte immer, dass es mit irgendeinem Update wieder verschwindet. Bleibt aber beharrlich

Datenbank habe ich schon mehrfach repariert, dabei ändert sich nichts.

Joomla 3.6.5
PHP: 7.0.13. Trat aber auch schon bei PHP 5.x auf.
Mysql: mysqlnd 5.0.12-dev
Gut 3.000 Beiträge
Einige Erweiterungen im Einsatz. Auch immer mal wieder welche deinstalliert. Ich vermute, daher rührt das Problem. Beim Editier-Aufruf wartet Joomla vielleicht auf eine Extension, die noch in der assets erwähnt ist. Das ist aber ins blaue fantasiert.

Hilft das?

firstlady · 11. Januar 2017

Vielleicht hast du die Benachrichtigung nicht aktiviert?
Schau in deinem Profil unter Einstellungen.
Wenn etwas soooo lang dauert sind eher die Kategorien bzw. deren assets schuld. Ich kann jetzt nicht sagen wie du das einfach diagnostizieren oder direkt beheben könntest.

Was ich versuchen würde:
backup anlegen, dann in inhalte / kategorien auf "Wiederherstellen" klicken. Vielleicht hilft das schon.
Wenn nicht:
Eine Kopie deiner Seite lokal oder auf einer Subdomain einrichten. Anstelle deiner Datenbank eine frische Joomla-Datenbank unterjubeln. Dann Inhalte mit xml2J von der alten in die neue Datenbank übertragen. Das sollte einen Neuaufbau der assets erzwingen.

Diarmiud · 11. Januar 2017

Hallo Christiane,
danke dir. Die Benachrichtigung war tatsächlich in den Einstellungen deaktiviert.

Das Wiederherstellen der Kategorien hat nichts gebracht.

Aber ... Dennoch brachte mich dein Hinweis weiter und führte (anscheinend) zur Lösung des Problemes. Mir half der Hinweis auf:
http://www.itoctopus.com/creat…sets-table/comment-page-1

Der da lautete, den folgenden Befehl in der Datenbank auszuführen:

Zitat

DELETE FROM #__assets WHERE `name` LIKE '%com_content.article.%';

#_ muss natürlich mit dem eigenen Präfix ersetzt werden. Vorher habe ich sicherheitshalber die _assets-Tabelle kopiert gehabt.

Da wurden bei mir glatt mal 80 % der _assets Einträge (rund 3.800) gelöscht. Nun ist die Geschwindigkeit auf dieser Seite beim Anlegen von Neuartikeln und beim Bearbeiten von Alt-Artikeln wieder normal.

Nochmals: Danke! Wer viel in Joomla arbeitet kann wohl nachvollziehen, wie nervig das Problem war.

firstlady · 11. Januar 2017

Hi, ich hoffe, dass niemand das nachmacht.
In den Assets sind die Berechtigungen definiert. Wenn du Zugriffsrechte gesetzt hattest, sind sie jetzt weg.
Daher mein Hinweis "Ein neuspeichern sollte einen Neuaufbau der assets erzwingen".

Viele Assets machen normalerweise keine Probleme, 3000 Beiträge ist nichts Besonderes und 100.000 assets verursachen von sich aus keine Performance-Probleme, sonst würden meine Seiten alle nicht funktionieren. Ich denke, dass bei dir im Lauf der Migrationen und Updates mit der Zeit sich falsche Verweise eingeschlichen haben, die endlose Suche in er Datenbank produzierten.

Diarmiud · 11. Januar 2017

Ohh, guter Hinweis. Zum Glück hatte ich bei diesem Projekt keine speziellen Berechtigungen beim Content.

Re:Later · 11. Januar 2017

Noch Fundsache:
Jedenfalls kommen die lft-, rgt-Werte des übergeordneten com_content-Eintrags durcheinander. Was und ob das irgendwann/wo aufschlägt/aufschlagen kann, weiß ich aber nicht. Jedenfalls ist da in meiner Testdatenbank jetzt eine Lücke "nach links", die ich auch nach "langem Zureden" nicht wegbekomme und bei evtl. auftretenden Problemen nicht wüsste, wie man sie händisch zu korrigieren hat.

firstlady · 11. Januar 2017

Worauf beziehst du dich da?
Meinst du, in der aktuellen Version ergeben sich Lücken in den lft/rgt ? oder passiert es beim Löschen oder wie ist die Lücke entstanden?

Re:Later · 11. Januar 2017

Zitat von firstlady

Worauf beziehst du dich da?

Ich habe in einer Testseite (Staging) alle assets für Beiträge (com_content.article...) in der DB gelöscht nach der Anleitung oben. Dann "Wiederherstellen" im Backenend (Keine Ahnung, ob Zusammenhang). Danach hat der Assetseintrag der Mutter-Komponente com_content diese Lücke nach links (hat einen lft von 88, aber kein Kind mit lft 89 usw (wie zuvor). Irgendwo mittendrin geht stattdessen das lft der Kinder los. Irgendwas um die 105 als Start.)

Wenn ich halt wüsste, wovon ich da rede Ich spick mir das bei jeder neuen Datenbank wieder aus schlauen Büchern ab und mal dann erst mal doll viel Pfeile und Zahlen aufs Papier.

firstlady · 11. Januar 2017

Hi, danke für die Information und deine todesmutige Aktion! Ich habe mich immer davor gehütet, asset-Sätze zu löschen. Oder irgendwas mit sql zu löschen was asset-Sätze hat, eben weil die nested sets von Hand sehr schwer zu reparieren sind wenn es mal mehr als ein Dutzend ist.
Ich kann die Konsequenzen auch nicht abschätzen, würde das Löschen der asset-Sätze aber keinesfalls empfehlen. Wenn man da später mal ACL aktiv verwenden will, keine Ahnung was dann passiert.