Thanks/Hide tag, te stressend voor mysql - waarom?

Ik snapte niet helemaal wat je bedoelde, totdat ik ging googlen. Het lijkt een bekend probleem te zijn, zo aan de results te zien. Misschien staat hier wat meer informatie die op jou van toepassing is?

https://www.google.nl/sea...&sourceid=chrome&ie=UTF-8

Dit gebeurt in PHP? Ik zie niet in waarom dit de SQL server stresst, ipv www.link.com sla je in het de database bijv. [hide]www.link.com[/hide] op (of het HTML equivalent). PHP verwerkt die tags dan weer, SQL serveert jou alleen de data zoals opgeslagen (of dat nou met tags, zonder tags, 10 of 1000 tekens zijn).

SQL query inzichtichtelijk maken dmv logging (general_log = 'ON'). Dan kun je in een shell de mtop bekijken en in een andere shell tail je de /var/run/mysqld/mysqld.log

De mod moet natuurlijk opslaan wie er "thanks" gezegd heeft om het de volgende keer te kunnen tonen, dus elke keer als er een topic in geladen word met de tags in gebeurt er waarschijnlijk een join ofzo. Afhankelijk van de opbouw van die query of de grootte van de db kan dat dan inderdaad een probleem vormen zou ik zo zeggen...

Meten == weten. Als je niet aan de kant zit waar je kunt meten/profilen is het gewoon koffiedik kijken en speculeren hier. Wat hoop/dacht je te bereiken met dit topic?

Verder: Ik zie even niet wat dit in WEB doet Ik doe even een tikje naar SEA maar betwijfel of dit topic nog een lang leven beschoren is

[ Voor 17% gewijzigd door RobIII op 11-08-2012 17:55 ]

Dan moet je dat door iemand laten doen die het wel kan meten. Hoe wilde je het oplossen als je niet eens de rechten hebt om te meten wat er gebeurt?

Verder, wat nodig is om dat bedankje op te slaan zou niet meer moeten zijn dan een koppeltabel die user en post aan elkaar linkt. De query om die data er weer uit te halen is verdomd simpel. Het enige wat ik daarop kan bedenken wat veel mensen fout doen is dat ze een primaire index leggen op twee velden, userid en postid, en daarmee denken klaar te zijn met indexes. MySQL Kan het tweede veld van een compound key niet als index gebruiken wanneer je die als foreign key gebruikt, wat erop neerkomt dat er een full table scan nodig is om op te zoeken of iemand al bedankt heeft voor een bepaalde post. EXPLAIN voor de betreffende query zetten zou dat aan moeten tonen. De oplossing in die situatie is een aparte index aanmaken op alleen het tweede veld van die compound key.

Ik zie wel wat problemen:
- Normaliter kan je een forumposting in "geparste vorm" cachen/opslaan. Als je voor elke reactie alsnog moet kijken of er wellicht zo'n hide-sectie in zit, komt daar een stukje onzekerheid bij kijken. Er zijn vast trucjes mogelijk om het efficient te houden, maar je moet dan ineens voor elke reactieweergave nog wat extra rekenwerk doen.
- De "eenvoudige koppeltabel" voor het opslaan van reactiebedankjes is inderdaad eenvoudig. Maar zo'n tabel wordt vrij snel behoorlijk groot. En dat is op zich niet zo'n probleem, maar het is ook een tabel met vrij veel inserts tussen de hoeveelheid reads door.

Het is om die laatste reden dan ook goed mogelijk dat een explain op een testsite je laat zien dat zowel het toevoegen als uitlezen razendsnelle queries zijn... Maar op het moment dat er tientallen of honderden gebruikers tegelijk zijn, dan ga je mogelijk merken dat gebruikers moeten wachten op locks van anderen en krijg je wellicht zelfs hier en daar wat deadlocks.
Al met al vind ik het best plausibel dat een dergelijke functie een groot deel van de SQL-resources opeet, zeker als het niet heel efficient gedaan is.

ACM: Hoewel je gelijk hebt op beide punten vermoed ik dat het forum in kwestie phpBB is (ik geloof dat ik de add-on ken). Als je dat stuk software gebruikt voor een forum van de grootte waarin jouw punten een probleem kunnen worden, dan heb je allang ook op andere punten vertraging gemerkt.

Een linkje naar deze illustere add-on zou wel handig zijn

Ik zie eigenlijk niet waarom de sql server zou kunnen crashen van zoiets, tenzij de server beroerd geconfigureerd is en er bijvoorbeeld een geheugenprobleem ontstaat.. Hooguit zou je timeouts/bereikte connectielimieten moeten krijgen. Of de (my?)sql server heeft toch wel een typische bug..

Aangezien het jarenlang heeft gewerkt: Is er toevallig onlangs een softwareupgrade geweest? Heeft de server niet toevallig stuk geheugen gekregen of andere kapotte hardware als de sql server meerdere keren per dag crashed?

Mijn gok is... ze gebruiken geen gedenormaliseerde counters en bij het laden van het forum worden voor alle topics het aantal "thanks" ingeladen waardoor het geval effectief dus voor elk topic alle "thanks" regels moet gaan ophalen.

Dat kan vrij zwaar zijn

Eenvoudige fix, zorg ervoor dat er een counter opgeslagen wordt per topic met de "thanks_count"

Wolfboy schreef op woensdag 15 augustus 2012 @ 01:37:
Mijn gok is... ze gebruiken geen gedenormaliseerde counters en bij het laden van het forum worden voor alle topics het aantal "thanks" ingeladen waardoor het geval effectief dus voor elk topic alle "thanks" regels moet gaan ophalen.

Dat kan vrij zwaar zijn

Eenvoudige fix, zorg ervoor dat er een counter opgeslagen wordt per topic met de "thanks_count"

Die thanks gaan per post als het die addon is die ik denk dat het is. Zelfde principe verder natuurlijk.

[ Voor 3% gewijzigd door NMe op 15-08-2012 01:41 ]

kan wellicht al met mysql partitioning opgelost worden (by user of by thread), dan zou het een stuk vriendelijker moeten zijn om die data op te halen, of per user/thread een aparte tabel om dit soort spul in op te slaan. Of een tabel met goede indexen en dan als de gebruiker inlogt in een keer de thanks inlezen (vereist meer van de webserver) of dit als cookie zetten (mag niet te raden zijn; kans op misbruik omdat je dan de client moet vertrouwen). Zijn genoeg manieren om de load op de SQL server kleiner te maken.

Gewoon denormaliseren, countertje bij de user en elke keer updaten. Eventueel in Redis/Memcached als je teveel updates op de rijen krijgt en/of je query cache/hot rows niet wil trashen.

CMG schreef op donderdag 16 augustus 2012 @ 13:00:
kan wellicht al met mysql partitioning opgelost worden (by user of by thread), dan zou het een stuk vriendelijker moeten zijn om die data op te halen, of per user/thread een aparte tabel om dit soort spul in op te slaan.

Ik denk niet dat je MySQL heel vrolijk wordt van vele duizenden partitions of tabellen dat in potentie doorloopt tot vele miljoenen
Om je een idee te geven; wij hebben ruim 400k useraccounts en zo'n 1.5M topics. Nou zal niet elk forum zo groot zijn of zo lang bestaan, maar het gaat natuurlijk wel hard als je dat soort ongebreidelde groei gebruikt voor extra tabellen of partities. Je zou het natuurlijk wel kunnen partitioneren op 'userid % 100' ofzo, dan heb je alsnog wat meer gespreide toegang mogelijk tot je data.

Er zijn vziw uberhaupt maar weinig databases die echt goed tegen ongelimiteerde tabelgroei kunnen. Per user+thread een redis-list/set/whatever is dan waarschijnlijk een van de weinige die wel redelijk efficient zal werken met zo'n soort aanpak. Totdat het geheugen op is natuurlijk, hoewel je alle oude thank-meldingen wel gewoon in je database kan opslaan, het gaat vooral om de nieuwe topics waar je de meeste moeite in moet steken.

Of een tabel met goede indexen en dan als de gebruiker inlogt in een keer de thanks inlezen (vereist meer van de webserver) of dit als cookie zetten (mag niet te raden zijn; kans op misbruik omdat je dan de client moet vertrouwen). Zijn genoeg manieren om de load op de SQL server kleiner te maken.

Ik denk dat met goed gebruik van indexen, logisch gedrag van queries (bijv de 'thanks'-tabel direct meejoinen ipv per bericht kijken of er een thanks was en die checken) en al dat soort dingen een goede eerste stap zijn.

Wolfboy schreef op donderdag 16 augustus 2012 @ 16:22:
Gewoon denormaliseren, countertje bij de user en elke keer updaten. Eventueel in Redis/Memcached als je teveel updates op de rijen krijgt en/of je query cache/hot rows niet wil trashen.

Hoe zie je dat denormaliseren voor je? Je moet per userid-topicid (of zelfs messageid) een tellertje hebben dan... Die wil je ook niet in je usertabel hebben. En je kan het hooguit als een soort bloomfilter gebruiken dan: heeft user U uberhaupt in topic T een thanks-melding geplaatst. Maar dan krijg je alsnog voor elke thanks-melding een los record voor elke U en T.

ACM schreef op vrijdag 17 augustus 2012 @ 07:55:
Hoe zie je dat denormaliseren voor je? Je moet per userid-topicid (of zelfs messageid) een tellertje hebben dan... Die wil je ook niet in je usertabel hebben. En je kan het hooguit als een soort bloomfilter gebruiken dan: heeft user U uberhaupt in topic T een thanks-melding geplaatst. Maar dan krijg je alsnog voor elke thanks-melding een los record voor elke U en T.

Op elke dimensie waar je zo'n counter wil hebben voeg je de counter toe (eventueel dus per message ja). Zoiets is met een paar triggers prima te fixen als je het op kleinere schaal wil doen (gaat prima tot ~10 thanks per seconde als je het direct doet, wat voor de meeste sites voldoende is).

Wil je het op een iets grotere schaal doen dan zal je deze rijen ergens in een queue moeten stoppen zodat je ze in batch kan verwerken en kan laten updaten.

Wil je het op een nog grotere schaal doen dan zal je het slimmer moeten aanpakken met een Redis hash oid.


Vergelijkbare problemen heb ik al bij een aantal sites opgelost waarvan een paar groter dan Tweakers.net, dus het is zeker op grotere schaal zo werkend te krijgen