De server geeft geen fuck om wat voor verbinding ik heb hoor.
toevoeging op 19 augustus 2015, 14:28:49: "Daarom eventueel een instelling voor diegenen"
Gevolg dat het voor hun slomer wordt en ook voor de andere. Al zal het zon vaart niet lopen, maar als je alle posts in een topic (max 2500) (en in oudere topics zelfs nog veel meer) in één keer moet laden kost dit wel enorm veel meer querys. Per bericht komen er waarschijnlijk meerdere querys aan en als er dan ineens (3q*2500p=7,5k) querys uitgevoerd moeten worden krijgt de database het wel ff moeilijk (als dit voor meerdere users tegelijk moet) en dan moeten andere leden wachten waardoor het voor iedereen slomer wordt.
Ligt er ofc aan hoeveel de database server aankan en hoeveel querys erbij komen.
Ik mag hopen dat er geen querys uitgevoerd worden per item. Ik ken de code van one2xs niet, maar ik denk dat Len wel meer kan vertellen over de performance.
Ik heb dit wel op meerdere forums gezien, dus standaard zou het geen probleem mogen zijn lijkt me. Tenzij de query-datastructuur te wensen overlaat.
Dat zou makkelijk met een query voor een hele zichtbare thread worden gedaan? Gewoon wat JOINs aanleggen met de nodige tabellen voor de preferences, en de usertable.
Maar of mijn idee haalbaar is mag Lennard ons wel uitleggen .
Ja maar per post moeten er alsnog meerdere querys uitgevoerd worden. Of één query met enorm veel joins maar die wordt dan nóg groter en dan heb je hetzelfde verhaal.
Ik zou niet weten waarom je per post meerdere queries moet gebruiken? Ik heb het nog nooit nodig gehad.
En met JOINS hoef je niet steeds een nieuwe query op te halen, en kan je met een enkele query alle nodige data in je array schuiven. Vooral je je nog INDEXES hebt, kan je ene mooie performance halen.
Ja, maar om het iets op te kunnen rekken naar een variabel aantal tot 50 per page (desnoods als limiet) is al een aardig idee. Mocht het meer kunnen, zou dat ook tof zijn. En misschien trekt de performance het wel om alles te tonen?
Wat Aar zegt klopt; alle berichten en relevante userinfo wordt in één query met slechts twee joins en wat subqueries opgehaald, dus in theorie moet het kunnen.
Die theorie houdt alleen al snel op doordat er wel meer subqueries uitgevoerd moeten worden bij meer posts (voor met name het ophalen van de feedbacks) en je dus eigenlijk wel meer queries krijgt, ook al zijn het subqueries van één grote query en heb je feitelijk gezien nog wel evenveel queries.
Ik heb net even een klein testje gedaan door het limiet op 150 te zetten in plaats van op 15 en tien keer de parsetijd genomen. Die parsetijd is dan 8 keer zo hoog (1,8 sec vs 0,24 sec), wat wel weer veel is.
Ik kan het eventueel invoeren met een kleine range, zodat je bijvoorbeeld 1-30 posts per pagina in kunt stellen, maar veel groter dan dat wordt te traag. Oplossing zou kunnen zijn om de boel te denormaliseren zodat je die subqueries kwijt bent, maar das ook weer wat veel gedoe voor een kleine feature.
Wat Aar zegt klopt; alle berichten en relevante userinfo wordt in één query met slechts twee joins en wat subqueries opgehaald, dus in theorie moet het kunnen.
Die theorie houdt alleen al snel op doordat er wel meer subqueries uitgevoerd moeten worden bij meer posts (voor met name het ophalen van de feedbacks) en je dus eigenlijk wel meer queries krijgt, ook al zijn het subqueries van één grote query en heb je feitelijk gezien nog wel evenveel queries.
Ik heb net even een klein testje gedaan door het limiet op 150 te zetten in plaats van op 15 en tien keer de parsetijd genomen. Die parsetijd is dan 8 keer zo hoog (1,8 sec vs 0,24 sec), wat wel weer veel is.
Ik kan het eventueel invoeren met een kleine range, zodat je bijvoorbeeld 1-30 posts per pagina in kunt stellen, maar veel groter dan dat wordt te traag. Oplossing zou kunnen zijn om de boel te denormaliseren zodat je die subqueries kwijt bent, maar das ook weer wat veel gedoe voor een kleine feature.
Dus zoals bij de meeste suggesties: "Site herschrijven" zou de beste optie zijn
Wat Aar zegt klopt; alle berichten en relevante userinfo wordt in één query met slechts twee joins en wat subqueries opgehaald, dus in theorie moet het kunnen.
Die theorie houdt alleen al snel op doordat er wel meer subqueries uitgevoerd moeten worden bij meer posts (voor met name het ophalen van de feedbacks) en je dus eigenlijk wel meer queries krijgt, ook al zijn het subqueries van één grote query en heb je feitelijk gezien nog wel evenveel queries.
Ik heb net even een klein testje gedaan door het limiet op 150 te zetten in plaats van op 15 en tien keer de parsetijd genomen. Die parsetijd is dan 8 keer zo hoog (1,8 sec vs 0,24 sec), wat wel weer veel is.
Ik kan het eventueel invoeren met een kleine range, zodat je bijvoorbeeld 1-30 posts per pagina in kunt stellen, maar veel groter dan dat wordt te traag. Oplossing zou kunnen zijn om de boel te denormaliseren zodat je die subqueries kwijt bent, maar das ook weer wat veel gedoe voor een kleine feature.
Dus zoals bij de meeste suggesties: "Site herschrijven" zou de beste optie zijn
en dan met nodejs
toevoeging op 23 augustus 2015, 10:39:43: en angular
Wat Aar zegt klopt; alle berichten en relevante userinfo wordt in één query met slechts twee joins en wat subqueries opgehaald, dus in theorie moet het kunnen.
Die theorie houdt alleen al snel op doordat er wel meer subqueries uitgevoerd moeten worden bij meer posts (voor met name het ophalen van de feedbacks) en je dus eigenlijk wel meer queries krijgt, ook al zijn het subqueries van één grote query en heb je feitelijk gezien nog wel evenveel queries.
Ik heb net even een klein testje gedaan door het limiet op 150 te zetten in plaats van op 15 en tien keer de parsetijd genomen. Die parsetijd is dan 8 keer zo hoog (1,8 sec vs 0,24 sec), wat wel weer veel is.
Ik kan het eventueel invoeren met een kleine range, zodat je bijvoorbeeld 1-30 posts per pagina in kunt stellen, maar veel groter dan dat wordt te traag. Oplossing zou kunnen zijn om de boel te denormaliseren zodat je die subqueries kwijt bent, maar das ook weer wat veel gedoe voor een kleine feature.
Dus zoals bij de meeste suggesties: "Site herschrijven" zou de beste optie zijn
en dan met nodejs
toevoeging op 23 augustus 2015, 10:39:43: en angular
How about no.
Jouw reactie
Deel je idee, stel een vraag of help een ander verder.
.
