Meer berichten per pagina in het forum

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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 schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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 schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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.

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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 schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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

Rik schreef:

Eerdere citaten tonen

Luuko schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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

Ik had het over NodeJS en Angular. Beide frameworks die niet nodig zijn en beide ook zo hun nadelen hebben.

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Luuko schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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

Ik had het over NodeJS en Angular. Beide frameworks die niet nodig zijn en beide ook zo hun nadelen hebben.

En wat zijn de nadelen dan?

Lennard schreef:

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.

Lennard schreef:

http://www.one2xs.com/profiel/forum

Dylan schreef:

En nu nog een knopje dat je snel naar boven en naar beneden kan gaan.

Dat heet de Home en End knop op je toetsenbord. En een beetje fatsoenlijke mobile browser (Opera ) laat een knopje zien waarmee je helemaal naar boven of beneden kan als je hard scrollt

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Luuko schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Dylan schreef:

Eerdere citaten tonen

Rik schreef:

Eerdere citaten tonen

Lennard schreef:

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

Ik had het over NodeJS en Angular. Beide frameworks die niet nodig zijn en beide ook zo hun nadelen hebben.

En wat zijn de nadelen dan?

Beide zijn voor kleine projectjes prima te gebruiken, maar naarmate de projecten groter worden moet je vaak omslachtiger gaan doen om alles goed werkend te krijgen. Bovendien zijn beide makkelijk om mee te beginnen, maar moeilijk om GOED te gebruiken.
Je website is bovendien niet te indexeren door google wanneer je gebruik maakt van angular (tenzij je de site vantevoren ook laat inladen zonder angular, wat het goede aan angular weer grotendeels teniet doet).

Single page apps -> Angular superhandig
Grote complexe apps -> Gebruik iets anders

Maar dat is mijn mening.

Luukvdo schreef:

Eerdere citaten tonen

Dylan schreef:

En nu nog een knopje dat je snel naar boven en naar beneden kan gaan.

Dat heet de Home en End knop op je toetsenbord. En een beetje fatsoenlijke mobile browser (Opera ) laat een knopje zien waarmee je helemaal naar boven of beneden kan als je hard scrollt

toevoeging op 24 augustus 2015, 10:40:57:
@Lennard de pagina ververste net toen ik dat bericht postte terwijl het niet het eerste bericht voor een nieuwe pagina is. Ik gok dat er in de AJAX nog hardcoded 15 ergens in staat?

Luuko schreef:

Eerdere citaten tonen

Luukvdo schreef:

Eerdere citaten tonen

Dylan schreef:

En nu nog een knopje dat je snel naar boven en naar beneden kan gaan.

Dat heet de Home en End knop op je toetsenbord. En een beetje fatsoenlijke mobile browser (Opera ) laat een knopje zien waarmee je helemaal naar boven of beneden kan als je hard scrollt

toevoeging op 24 augustus 2015, 10:40:57:
@Lennard de pagina ververste net toen ik dat bericht postte terwijl het niet het eerste bericht voor een nieuwe pagina is. Ik gok dat er in de AJAX nog hardcoded 15 ergens in staat?

LOL, nooit geweten dat die knoppen daarvoor zijn
Maar ik had net ook, postte een bericht en toen ververste de pagina en kwam de reactie heel even op een nieuwe pagina.
En daarna gelijk weer op de vorige pagina