[bug] bookmarks laden traag deel 2

[Verwijderd]

Heb even gewacht maar sinds afgelopen week sinds de 'crash' heb ik er weer last van.
Eerdere topic, maar is gesloten:
[bug] bookmarks en myreact laden traag

Dit keer overigens geen timeouts en myreact reageert ook direct, maar navigeren naar bookmarks (via GoT zelf of via bookmarks in Firefox) gaat gewoon erg traag (5-10 seconden ruw geschat) terwijl alle andere pagina's meteen weergegeven worden.

code:

1. <!-- Server: astraeus.tweakers.net | Total: 19,197 | Incl: 0,027, Init: 0,043, Action: 19,147 | DB: 19,047/17, Tpl: 0,043 -->
2. <!-- Server: astraeus.tweakers.net | Total: 19,235 | Incl: 0,032, Init: 0,039, Action: 19,191 | DB: 19,089/17, Tpl: 0,042 -->

[moto-moi]

Je hebt zo te zien ruim 6300 bookmarks, ik gok dat er ergens iets inefficients gebeurt bij zulke grote aantallen.

[crisp]

Er zijn atm 8 users die meer dan 1000 bookmarks hebben. Jij hebt met bijna 6400 bookmarks bijna 2x zoveel bookmarks als de nummer 2 in het staatje 'meeste bookmarks per gebruiker'. Frankly vind ik het dan ook niet zo gek dat het bij jou wat trager is dan bij de rest

[Verwijderd]

Heb er wat weggegooit, toen ik onder de 6000 kwam was het al een stuk sneller. Ik meende ooit gelezen te hebben dat de bookmarks niet 'echt' verwijderd worden maar op disabled gezet worden oid, leek me weinig zin hebben ze te verwijderen omdat ik met mijn logica er vanuit ging dat de data toch wel gelezen moest worden om te 'zien' of een bookmark wel of niet ingelezen moest worden.

Maar ja opgelost dus, Jij hebt met bijna 6400 bookmarks bijna 2x zoveel bookmarks als de nummer 2 in het staatje 'meeste bookmarks per gebruiker'. grappig

[ACM]

Er wordt/werd voor Lighteye een query gegenereerd van 48KB groot met een heleboel id's in de topicid-in-clause... is er een reden waarom die topicids allemaal (?) in de in-list gegooid worden? 't Is iig een bijzonder inefficiente query die geregeld in de slow-log terugkomt zo te zien.

De query leest zo te zien alle bookmarks uit oid en kan blijkbaar niet al te efficient een index of combinatie van indexen gebruiken:
# Query_time: 24 Lock_time: 0 Rows_sent: 50 Rows_examined: 3459718

Blijkbaar gaat ie eerst de topics opzoeken en dan de bookmarks erbij, ipv andersom... knap staaltje planning van mysql Als je de bookmark.TopicID IN verandert in topic.TopicID IN ga je al flink vooruit kwa query tijd. Anderzijds lijkt een USE INDEX (UserID) bij de bookmark toevoegen nog het meeste effect te hebben zonder te query aan te passen.

De lange IN-list weglaten maakt niet uit voor de query-performance.

[ Voor 55% gewijzigd door ACM op 03-12-2006 19:43 ]

[Spider.007]

Waarschijnlijk is er nooit rekening gehouden met een dergelijk aantal bookmarks; maar ik kan er morgen wel even naar kijken

[ACM]

Zie de edits hierboven, ik heb al twee dingen voor je uitgeprobeerd.

[Spider.007]

Thanks! Ik zal hem morgen even toevoegen aan 1.9.4.

offtopic:
niet dus; totdat we een sluitende fix gevonden hebben

[ Voor 37% gewijzigd door Spider.007 op 06-12-2006 16:23 ]

[BtM909]

offtopic:
Overigens, holy cow 6300 bookmarks , schiet dat het doel van bookmarks nou net niet voorbij?

[crisp]

Dit is zo te zien in 1.9.5 nog steeds een issue... (hoewel TS z'n bookmarks zo te zien wel wat heeft opgeruimt )

[Spider.007]

Ik kon dan ook geen manier vinden om, naast de huidige snelheid voor kleinere aantallen ook betere snelheid aan dergelijk hoge aantallen te verkrijgen. Succes

[crisp]

Performance voor grote aantallen verviervoudigd zonder noemenswaardig negatief effect voor kleine aantallen