Meer berichten per pagina in het forum

[Aarclay]

Is er een mogelijkheid om het aantal posts per page in het forum te verruimen, als is het door een bepaalde parameter, of instelling?

Op veel andere forums is deze mogelijkheid er namelijk, en soms zelfs met een knop of mogelijkheid om gewoon alle posts te kunnen tonen.

Is er ook ook zoiets voor dit forum hier, of een mogelijkheid om dit in te bouwen?

 

[Guest]

wordt het slomer van.


toevoeging op 19 augustus 2015, 13:57:40:
dus ik stem nee.

 

[Aarclay]

Jessee (link):
wordt het slomer van.


toevoeging op 19 augustus 2015, 13:57:40:
dus ik stem nee.

Ligt wel aan je verbinding? Of zit je soms op 56k6 ofzo?
Een beetje verbinding kan wel minimaal het dubbele aan posts in een topic aan.

Daarom eventueel een instelling voor diegenen, of een verruiming van het standaard aantal berichten.

 

[Guest]

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.

 

[Aarclay]

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.

 

[Guest]

Je moet per bericht toch onderschrift en user data ophalen etc.
En ook geen idee of dit eenmalig per user gebeurd of per bericht per user.

 

[Aarclay]

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

.

 

[Guest]

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.

 

[Aarclay]

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.

 

[Guest]

Maar er blijft alsnog een verschil in 15 posts ophalen, of 2500 (bijv)

 

[Aarclay]

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?

De 15 posts per page vind ik nu erg magertjes....

 

[Lennard]

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.

 

[Rik]

Lennard (link):
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

 

[Dylan]

Rik (link):

Lennard (link):
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

 

[Rik]

Dylan (link):

Rik (link):

Lennard (link):
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.

 

[Dylan]

Rik (link):

Dylan (link):

Rik (link):

Klik om eerdere quotes te tonen


Lennard (link):
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.



how about yes

 

[Rik]

Dylan (link):

Rik (link):

Dylan (link):

Klik om eerdere quotes te tonen


Rik (link):

Lennard (link):
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.



how about yes



Het is niet nodig.

 

[Luuko]

Rik (link):

Dylan (link):

Rik (link):

Klik om eerdere quotes te tonen


Dylan (link):

Rik (link):

Lennard (link):
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.



how about yes



Het is niet nodig.



Blijkbaar wel want mensen vragen erom

 

[Dylan]

Rik (link):

Dylan (link):

Rik (link):

Klik om eerdere quotes te tonen


Dylan (link):

Rik (link):

Lennard (link):
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.



how about yes



Het is niet nodig.



Als je het doet, doe het dan gelijk goed.