Dynamisch profiel

[jelmervos]

Is het toegestaan om een dynamisch profiel te hebben, en zoja, mag deze open-source zijn?
Is het beleid misschien gelijk aan dat bij de Topix software: het mag wel, zolang je niet te vaak gaat updaten, vanwege de server load.

Alvast bedankt voor een reactie.

[Robin]

Een random icon kan geen kwaad (heb er zelf ook een ) maar als je een random sig hebt, gaat dat ten koste van de serverload. Vooral als iedereen een random sig gaat gebruiken

Zie ook dit topic: Random signatures

[LuNaTiC]

lijkt me niet echt bevordelijk voor de snelheid, en zolang GoT nog steeds niet lekker loopt lijken me dit soort dingen wel erg overbodig en onhandig eerlijk gezegd

[SiHiDa]

Smiecht, ik wilde ook al zo'n prog maken. Maar ja, als het niet mag, hoef ik hem ook niet te maken...

[RvdH]

Pff wat een onzin zeg, ik weet dat React niet erg resource-zuinig is, maar stel dat er 100 (ff overdrijven) users zijn met een random signature, en die signature elke minuut updaten.. nou, dan heb je wel ff 1,nogwat requests per seconde extra! Poepoe. Das toch helemaal niks? Kunnen die servers makkelijk aan..

[Erkens]

strlen schreef op 09 september 2002 @ 21:33:
Pff wat een onzin zeg, ik weet dat React niet erg resource-zuinig is, maar stel dat er 100 (ff overdrijven) users zijn met een random signature, en die signature elke minuut updaten.. nou, dan heb je wel ff 1,nogwat requests per seconde extra! Poepoe. Das toch helemaal niks? Kunnen die servers makkelijk aan..

maar wie zegt dat ze 1x per minuut updaten misschien wel 1x per seconde, je weet het maar nooit.
rekenen kan je btw ook niet:

100 users, 1x per minuut updaten == 100 updates per minuut
100 updates per minuut == 1,67 updates per sec afgerond 2
2 updates per sec != 1 update per sec

[LuNaTiC]

strlen schreef op 09 september 2002 @ 21:33:
Pff wat een onzin zeg, ik weet dat React niet erg resource-zuinig is, maar stel dat er 100 (ff overdrijven) users zijn met een random signature, en die signature elke minuut updaten.. nou, dan heb je wel ff 1,nogwat requests per seconde extra! Poepoe. Das toch helemaal niks? Kunnen die servers makkelijk aan..

mwoh toen GoT met topix nagenoeg perfect draaide was er al onenigheid over het gebruik van random sigs enzo. Toen was het niet eens open source.

Waarom zou je dat nu wel doen bij een situatie waarin GoT af en toe gewoon bagger loopt?

[Erkens]

LuNaTiC schreef op 09 september 2002 @ 22:13:
Waarom zou je dat nu wel doen bij een situatie waarin GoT af en toe gewoon bagger loopt?

blij dat ik niet de enige ben die dat vind

[LuNaTiC]

erkens schreef op 09 september 2002 @ 22:14:
[...]

blij dat ik niet de enige ben die dat vind

mja je kan er kort over zijn, het werkt gewoon niet perfect, en af en toe loopt het gewoon bagger.

Heeft inmiddels bijna niks meer met React te maken overigens, maar met load balancers enzo (weet het fijne er ook niet echt van )

[flat]

ik dacht dat gold: zelf schrijven mag, zolang je 't maar niet aan mensen doorvertelt of openbaar maakt
zo blijft de groep die 't weet vrij beperkt

[RvdH]

erkens schreef op 09 september 2002 @ 22:10:
[...]

maar wie zegt dat ze 1x per minuut updaten misschien wel 1x per seconde, je weet het maar nooit.

Daar kun je dan wel regels over maken. 1 x per minuut is al erg veel, en het is met crontabs niet mogelijk om dingen per secondes te doen. En daar zullen de meeste dynamische signatures gebruik van maken.

rekenen kan je btw ook niet:

Ik kan wel rekenen, jij kan niet lezen. 1,67 is 1,nogwat, zoals ik zei.

[RvdH]

LuNaTiC schreef op 09 september 2002 @ 22:13:

[...]


mwoh toen GoT met topix nagenoeg perfect draaide was er al onenigheid over het gebruik van random sigs enzo.

Ja.. toen was de "regel" onzin en nu ook.

Toen was het niet eens open source.
Waarom zou je dat nu wel doen bij een situatie waarin GoT af en toe gewoon bagger loopt?

Waarom zou ik wat doen?

Persoonlijk vindt ik dat als je (zoals je het zelf zegt) "het fijne er niet van af weet", je ook niet kunt zeggen dat er een verschil zou zijn tussen Topix en React.

[LuNaTiC]

strlen schreef op 09 september 2002 @ 22:29:
[...]

Ja.. toen was de "regel" onzin en nu ook.

maar kennelijk was de regel er wel en om bepaalde redenen. Dat jij dat als onzin is natuurlijk iets anders Dus waarom zou dat nu ineens veranderd zijn, bij 'verergerde' toestand (als in: GoT loopt al minder, en nu wordt het _ook_ nog eens open source gemaakt )

Waarom zou ik wat doen?

'je' kan ook in het algemeen bedoeld worden in het Nederlands.

[LuNaTiC]

strlen schreef op 09 september 2002 @ 22:29:


Persoonlijk vindt ik dat als je (zoals je het zelf zegt) "het fijne er niet van af weet", je ook niet kunt zeggen dat er een verschil zou zijn tussen Topix en React.

Ik geef alleen maar door wat de Parse devvers er zelf van zeggen.

[RvdH]

LuNaTiC schreef op 09 september 2002 @ 22:36:

[...]
maar kennelijk was de regel er wel en om bepaalde redenen. Dat jij dat als onzin is natuurlijk iets anders Dus waarom zou dat nu ineens veranderd zijn, bij 'verergerde' toestand (als in: GoT loopt al minder, en nu wordt het _ook_ nog eens open source gemaakt )
[...]

Ik zeg helemaal nergens dat het nu ineens veranderd is, dat is mijn punt nu juist. Toen was het onzin om zo bang te zijn voor dynamische profielen, en nu ook.
En je zegt zelf dat je niet weet waarom GoT minder goed loopt als normaal, hoe kun je dan de conclusie trekken dat dynamische profielen de zaak verergeren?

'je' kan ook in het algemeen bedoeld worden in het Nederlands.

Dan moet je het wel op een goede, Nederlandse manier formuleren. In je zin refereert "dat" nergens aan, en dat is de reden waarom ik vroeg wat ik moest doen. Niet omdat je het aan mij persoonlijk richtte.

LuNaTiC schreef op 09 september 2002 @ 22:37:

[...]


Ik geef alleen maar door wat de Parse devvers er zelf van zeggen.

Dus als zij zeggen dat het niet aan hun product ligt, maar aan de loadbalancers, dan neem je dat klakkeloos over? Nogmaals, als je niet weet waarover je het hebt, zeg er dan niks over... je kunt niet overal wat vanaf weten. Als je wel dingen gaat concluderen, ondernemen e.d., gebaseerd op dingen die zij zeggen, dan ben je weinig meer als een ge-indoctrineerde zombie toch?

[LuNaTiC]

laat ik het zo zeggen: ik weet er idd misschien minder op dat gebied af dan jij (bv), en daar moet ik misschien idd wat terughoudender zijn met mn mening daarover

Maar als ik niet eens kan vertrouwen op wat de mensen die zich er mee bezig houden zelf van zeggen, tsjah, waarom zouden ze dat dan uberhaupt naar buiten brengen? En om dan maar meteen te impliceren datik een geindoctrineerde zombie ben daarom... thnx

[RvdH]

LuNaTiC schreef op 09 september 2002 @ 22:58:
laat ik het zo zeggen: ik weet er idd misschien minder op dat gebied af dan jij (bv), en daar moet ik misschien idd wat terughoudender zijn met mn mening daarover

idd misschien, misschien idd..
Gaat er helemaal niet om wie er meer van weet. Ik heb geen idee hoe ranzig of mooi React werkt, laat staan die loadbalancers, of het profiel-submit scriptje.

Maar zelfs al zou React er gigantisch van over z'n nek gaan, dan kunnen die servers dat wel afhandelen. 1,67 requests per seconde extra is niks, alle gebruikte servers leveren nu al 50+ requests per seconde.

Als het echt zo slecht zou zijn om dynamische profielen te hebben voor een paar gebruikers die genoeg hersencellen gebruiken om het geinstalleerd te krijgen, waarom dan? Is het uitgetest? Zijn er cijfers over beschikbaar?
Lever me wat simpele feiten, en ik verander zo van mening! Maar kom niet aanzetten met dingen die je "gehoord hebt van die en die, die het hoorde van die en die", daar hebben we niks aan.

Maar als ik niet eens kan vertrouwen op wat de mensen die zich er mee bezig houden zelf van zeggen, tsjah, waarom zouden ze dat dan uberhaupt naar buiten brengen?

Lijkt me nogal duidelijk hier.. 't is lekker makkelijk om te zeggen dat de traagheid van GoT de schuld is van de loadbalancers. Als ik me niet vergis draaide React al traag vanaf het moment dat het geinstalleerd was. En als het aan de loadbalancers zou liggen, dan zouden tweakers.net en fokzine.net ook traag moeten zijn.

En om dan maar meteen te impliceren datik een geindoctrineerde zombie ben daarom... thnx

Vervelend dat je die zin verkeerd interpreteert. Daar kan ik echter niets aan doen.

[LuNaTiC]

strlen schreef op 09 september 2002 @ 23:12:
[...]

idd misschien, misschien idd..
Gaat er helemaal niet om wie er meer van weet. Ik heb geen idee hoe ranzig of mooi React werkt, laat staan die loadbalancers, of het profiel-submit scriptje.

Maar zelfs al zou React er gigantisch van over z'n nek gaan, dan kunnen die servers dat wel afhandelen. 1,67 requests per seconde extra is niks, alle gebruikte servers leveren nu al 50+ requests per seconde.

Als het echt zo slecht zou zijn om dynamische profielen te hebben voor een paar gebruikers die genoeg hersencellen gebruiken om het geinstalleerd te krijgen, waarom dan? Is het uitgetest? Zijn er cijfers over beschikbaar?
Lever me wat simpele feiten, en ik verander zo van mening! Maar kom niet aanzetten met dingen die je "gehoord hebt van die en die, die het hoorde van die en die", daar hebben we niks aan.

Goed, point taken.

Lijkt me nogal duidelijk hier.. 't is lekker makkelijk om te zeggen dat de traagheid van GoT de schuld is van de loadbalancers. Als ik me niet vergis draaide React al traag vanaf het moment dat het geinstalleerd was. En als het aan de loadbalancers zou liggen, dan zouden tweakers.net en fokzine.net ook traag moeten zijn.

dan is het wachten op iemand die er meer van afweet en dan wel kan vertellen waar het aan ligt.

Vervelend dat je die zin verkeerd interpreteert. Daar kan ik echter niets aan doen.

Goed Nederlands schrijven en interpreteren is ook een kwestie van logica. Simpel optelsommetje die iedereen wel kan maken. (je weet niet waar je over praat en je zegt maar wat je hoort van anderen --> mensen die dat doen zijn geindoctrineerde etc --> dus... maak maar af). Maar ik kan je posts natuurlijk ook sarcastischer opvatten dan jij ze wellicht bedoelt.

maar ik stel verder voor om op te houden met dit gekibbel en te wachten op reacties van mensen die er wat meer over kunnen zeggen.

[Verwijderd]

strlen schreef op 09 september 2002 @ 23:12:
[...]

Als het echt zo slecht zou zijn om dynamische profielen te hebben voor een paar gebruikers die genoeg hersencellen gebruiken om het geinstalleerd te krijgen, waarom dan? Is het uitgetest? Zijn er cijfers over beschikbaar?
Lever me wat simpele feiten, en ik verander zo van mening! Maar kom niet aanzetten met dingen die je "gehoord hebt van die en die, die het hoorde van die en die", daar hebben we niks aan.

Als dit opensource aangeboden wordt, dan is een inschatting van 100 gebruikers erg positief vrees ik. Dat aantal zal vele malen hoger gaan liggen vrees ik. Waarschijnlijk bijna net zo hoog als het aantal mensen met een dynamisch icoon.

Als er dan ook nog mensen zijn die de sig laten updaten na elke topicview van een topic waarin zij gereageerd hebben, dan wordt het aantal updates van die ene persoon al gelijk aan het aantal views van topics waarin deze persoon gereageerd heeft. Dit loopt enorm snel op kan ik je vertellen, aangezien ik destijds zelf zo'n sig had (maar dat kan je je nog wel herinneren ). (uiteraard afhankelijk van de hoeveelheid topics waarin deze persoon reageert)

Daarom ben ik eigenlijk niet echt voorstander om dit helemaal opensource te maken. Laat het maar gewoon net zo als nu zijn. De mensen die weten hoe ze zoiets maken kunnen hun gang gaan, de rest moet zicht er gewoon in verdiepen of anders is het pech hebben.

[jelmervos]

Oke, heel erg bedankt voor de reacties. Weten we weer waar we aan toe zijn.

[RvdH]

Verwijderd schreef op 10 september 2002 @ 02:27:

[...]

Als dit opensource aangeboden wordt, dan is een inschatting van 100 gebruikers erg positief vrees ik. Dat aantal zal vele malen hoger gaan liggen vrees ik. Waarschijnlijk bijna net zo hoog als het aantal mensen met een dynamisch icoon.

Zal wel meevallen? Durf te wedden dat er lang geen 100 mensen zijn met een dynamisch icon. En dan nog, waarom zouden die allemaal dezelfde sig willen hebben?

Als er dan ook nog mensen zijn die de sig laten updaten na elke topicview van een topic waarin zij gereageerd hebben, dan wordt het aantal updates van die ene persoon al gelijk aan het aantal views van topics waarin deze persoon gereageerd heeft. Dit loopt enorm snel op kan ik je vertellen, aangezien ik destijds zelf zo'n sig had (maar dat kan je je nog wel herinneren ). (uiteraard afhankelijk van de hoeveelheid topics waarin deze persoon reageert)

Dat is dan ook een belachelijke manier om sigs te maken.. Je kunt voor aantallen keren per tijdsperiode gewoon een limiet instellen/bepalen/in de regels opnemen?

Daarom ben ik eigenlijk niet echt voorstander om dit helemaal opensource te maken. Laat het maar gewoon net zo als nu zijn. De mensen die weten hoe ze zoiets maken kunnen hun gang gaan, de rest moet zicht er gewoon in verdiepen of anders is het pech hebben.

*Jij* kunt het ook niet opensource maken... die mensen kunnen dat. Wie ben jij om hun te verbieden hun software te releasen?

[nulkelvin]

Hmmm ik hou er niet zo van, opensource mag niet, closed source wel, ik snap wel genoeg om zo'n random sig te maken. maar kunnen ze in GOT niet iets bouwen dan, dat er voor zorgt dat men z'n sig niet al te vaak mag updaten? Bijvoorbeeld max elke 5 minuten en als het vaker gebeurt waarschuwingen geven?

[ACM]

strlen schreef op 09 september 2002 @ 23:12:
Lijkt me nogal duidelijk hier.. 't is lekker makkelijk om te zeggen dat de traagheid van GoT de schuld is van de loadbalancers. Als ik me niet vergis draaide React al traag vanaf het moment dat het geinstalleerd was. En als het aan de loadbalancers zou liggen, dan zouden tweakers.net en fokzine.net ook traag moeten zijn.

Gelukkig weet jij dan ook niets van de achterliggende architectuur (meer) af.
Fokzine draait sowieso al vanaf dag 0 NIET achter de loadbalancers.

Tweakers.net wel al een tijdje, maar is kwa scripting wel wat minder resource intensief dan react.
Voornamelijk omdat de sites leunen op het gebruik van NFS, React moet hierbij echter meer requests verwerken naar de nfs-doos toe dan tweakers.net-FP (templates als voornaamste reden).

Anyway, de reden waarom het traag zou zijn is nog niet eens zo heel erg boeiend.

Ik wil alvast een foute aanname van je wegnemen:

select count(*) from users WHERE webicon LIKE '%.php%' OR webicon LIKE '%.pl%'

count(*)
422

Meer dus dan jouw 100 en dat aantal stijgt natuurlijk ook nog es.
Hier zitten de genen die al die trucjes uithaalden (.gif laten parsen enzo) al niet eens bij.

Daarnaast vergeet je dat een update altijd zwaarder is dan een select, vooral ook omdat er nog het nodige gelogd wordt aan allerlei zaken.
Al met al is het daardoor dus wel wat meer dan slechts "1,nogwat requests per seconde extra".
Magoed, ook al zouden de servers dat met gemak aan kunnen (en kunnen ze wellicht ook wel, niet getest, we kunnen moeilijk alle users van een dynamische sig voorzien) er is sowieso imho al weinig nut voor zoiets.

[Verwijderd]

strlen schreef op 10 september 2002 @ 23:15:
Dat is dan ook een belachelijke manier om sigs te maken.. Je kunt voor aantallen keren per tijdsperiode gewoon een limiet instellen/bepalen/in de regels opnemen?

Misschien zal dat voor bepaalde sigs wel wenselijk zijn? Je kunt die van mij ongetwijfeld nog wel herinneren. Ik kon makelijk een limiet instellen, maar dat wilde ik simpelweg niet, omdat dan het hele effect van die sig weg zou zijn.

*Jij* kunt het ook niet opensource maken... die mensen kunnen dat. Wie ben jij om hun te verbieden hun software te releasen?

Sjees, doe eens een beetje relaxed a.u.b.

Ik geef alleen aan, waarom ik niet voorstander ben van het feit dat iemand anders dat als opensource vrij zou geven.

[chem]

Ik zal iig dan maar even reageren hier.

Waarom het eea niet zo snel is als wenselijk zou zijn (al is het nu al veeeel beter) ga ik niet hier in LA behandelen. Ten opzichte van de 1.6.4 release is React al veel sneller, en er liggen al stukken code op het bord die de boel nog sneller maken. Daarnaast zijn er problemen geweest met NFS en de LB.

Wat ik wel kan vertellen is dat het submitten van je profile redelijk wat checks in zich heeft; is je email geldig of dubbel, is je ICQ dubbel, is je password veranderd, is de URL van je icon goed (veel preg-matches) etc., en vv het uitvoeren van de UPDATE query.

En die query is natuurlijk het hele probleem zo'n beetje. Elke keer dat je aan dat record zit te frunniken kunnen andere queries/processen er niet bij. Alles bij elkaar maakt dat de toch al veelvuldig gebruikte user-table er niet sneller op.

Of mensen hun signature dynamisch willen wijzigen; het zal me aan m'n reet roesten. Maar als iedereen ('iedereen' is figuurlijk hier) dat doet zit je wel op een 'shitload' aan UPDATE queries op 1 van de meest gebruikte tables. Het kan, maar het kan er ook trager van worden.

Wat men eerder voorstelde "max 5x per dag" etc. zou op zich kunnen (maar dan bv je hele profile) maar kost NOG meer queries dan je zou uitsparen in alle waarschijnlijkheid.

[RvdH]

ACM schreef op 11 september 2002 @ 01:19:

[...]

Gelukkig weet jij dan ook niets van de achterliggende architectuur (meer) af.
Fokzine draait sowieso al vanaf dag 0 NIET achter de loadbalancers.

Tweakers.net wel al een tijdje, maar is kwa scripting wel wat minder resource intensief dan react.
Voornamelijk omdat de sites leunen op het gebruik van NFS, React moet hierbij echter meer requests verwerken naar de nfs-doos toe dan tweakers.net-FP (templates als voornaamste reden).

En wat heeft dat met de loadbalancers te maken?
Ik wil best geloven dat React traag is door de NFS server.. maar kun je dan niet beter de React files op de harde schijven van de servers zetten (en dan evt 's nachts rsyncen)?
Daarmee haal je load van de NFS bak af, en zou React volgens deze redenatie ook sneller moeten zijn...

Anyway, de reden waarom het traag zou zijn is nog niet eens zo heel erg boeiend.

Ik wil alvast een foute aanname van je wegnemen:

[...]

Meer dus dan jouw 100 en dat aantal stijgt natuurlijk ook nog es.
Hier zitten de genen die al die trucjes uithaalden (.gif laten parsen enzo) al niet eens bij.

Hoeveel van die users zijn er actief? Hoeveel van die users komen nog dagelijks voor in de topics?

Daarnaast vergeet je dat een update altijd zwaarder is dan een select, vooral ook omdat er nog het nodige gelogd wordt aan allerlei zaken.

Al met al is het daardoor dus wel wat meer dan slechts "1,nogwat requests per seconde extra".
Magoed, ook al zouden de servers dat met gemak aan kunnen (en kunnen ze wellicht ook wel, niet getest, we kunnen moeilijk alle users van een dynamische sig voorzien) er is sowieso imho al weinig nut voor zoiets.

Waarom zou je SQL queries willen loggen
En test jij alles meteen uit op een live-server waarbij het op iedereen invloed heeft? Lijkt me niet.. daar gebruik je een *test* server voor.. hoop ik.
Dat je het niet wilt testen omdat je het niet nuttig vindt, is hetzelfde als zeggen "ik heb gelijk maar ik wil geen feiten leveren want dan heb ik geen gelijk meer".

[RvdH]

chem schreef op 11 september 2002 @ 08:05:
Ik zal iig dan maar even reageren hier.

Waarom het eea niet zo snel is als wenselijk zou zijn (al is het nu al veeeel beter) ga ik niet hier in LA behandelen. Ten opzichte van de 1.6.4 release is React al veel sneller, en er liggen al stukken code op het bord die de boel nog sneller maken. Daarnaast zijn er problemen geweest met NFS en de LB.

Het kan mij, als gebruiker, weinig interesseren *waarom* GoT traag is. Het enige wat ik zie, nogmaals als gebruiker, is dat Topix snel was en React langzaam. Dus trek ik, net als de rest, de conclusie dat het aan React ligt, of dat nou juist is of niet.. het is jullie taak als admins en coders de zaak snel te maken, en te houden, voordat er allemaal nasty features worden toegevoegd.

Wat ik wel kan vertellen is dat het submitten van je profile redelijk wat checks in zich heeft; is je email geldig of dubbel, is je ICQ dubbel, is je password veranderd, is de URL van je icon goed (veel preg-matches) etc., en vv het uitvoeren van de UPDATE query.

Waarom zou je willen checken op dubbelheid van info? Dan maak je die velden toch zeker gewoon UNIQUE? Kun je in PHP weer de error opvangen van je update, waarin precies verteld wordt welke velden dubbel zijn.. beetje raar om dat in php te doen als dat op database niveau al gebeurd

En die query is natuurlijk het hele probleem zo'n beetje. Elke keer dat je aan dat record zit te frunniken kunnen andere queries/processen er niet bij. Alles bij elkaar maakt dat de toch al veelvuldig gebruikte user-table er niet sneller op.

Ik kan me de laatste #55 niet herinneren.. is de databaseload nog wel zo'n issue?
En daar zit je nu ook al mee, met laatste bezoeken e.d. (er vanuit gaande dat die in de users table wordt opgeslagen).

[Osiris]

strlen schreef op 11 september 2002 @ 14:58:
Het kan mij, als gebruiker, weinig interesseren *waarom* GoT traag is. Het enige wat ik zie, nogmaals als gebruiker, is dat Topix snel was en React langzaam. Dus trek ik, net als de rest, de conclusie dat het aan React ligt, of dat nou juist is of niet.. het is jullie taak als admins en coders de zaak snel te maken, en te houden, voordat er allemaal nasty features worden toegevoegd.

Wow!

Mag ik je er op wijzen, dat GoT nog steeds een GRATIS iets is??? Als jij nou centen er voor neer zou leggen, okay, maar je kunt niet eisen dat ze het sneller maken!

Bouw anders je eigen forum dat wel sneller is ofzow

[ACM]

strlen schreef op 11 september 2002 @ 14:37:
En wat heeft dat met de loadbalancers te maken?
Ik wil best geloven dat React traag is door de NFS server.. maar kun je dan niet beter de React files op de harde schijven van de servers zetten (en dan evt 's nachts rsyncen)?
Daarmee haal je load van de NFS bak af, en zou React volgens deze redenatie ook sneller moeten zijn...

Ik geef jou een argument waarom React tov Tweakers.net trager is, ondanks het gebruik van de loadbalancers die ook nog steeds niet helemaal goed de load balancen.

Hoeveel van die users zijn er actief? Hoeveel van die users komen nog dagelijks voor in de topics?

Juist die users die zoveel moeite voor een icon doen zullen we aardig actief zijn.

Waarom zou je SQL queries willen loggen

Zei ik dat dan
Er worden extra zaken gelogd wat extra inserts betekend.

En test jij alles meteen uit op een live-server waarbij het op iedereen invloed heeft? Lijkt me niet.. daar gebruik je een *test* server voor.. hoop ik.

Klopt, maar ik heb geen 50k gebruikers voor handen op een testserver, jij wel?
Performance implicaties kan je gewoon bijna niet testen met een testserver, statische benchmarks leveren lang niet altijd goede informatie op, zeker met dit soort zaken niet.

Dat je het niet wilt testen omdat je het niet nuttig vindt, is hetzelfde als zeggen "ik heb gelijk maar ik wil geen feiten leveren want dan heb ik geen gelijk meer".

Neuh, dat is meer een soort luiheid, desinteresse, hoe je het wilt noemen.

strlen schreef op 11 september 2002 @ 14:58:
Het kan mij, als gebruiker, weinig interesseren *waarom* GoT traag is.

Vraag er dan niet naar/over

Het enige wat ik zie, nogmaals als gebruiker, is dat Topix snel was en React langzaam. Dus trek ik, net als de rest, de conclusie dat het aan React ligt, of dat nou juist is of niet.. het is jullie taak als admins en coders de zaak snel te maken, en te houden, voordat er allemaal nasty features worden toegevoegd.

En je denkt toch niet dat wij daar niet mee bezig zijn?

React was een pakket compleet nieuwe code voor een setup als de onze, daar zitten gewoon zaken in die wellicht efficienter kunne, daarbij komt nog dat de ondersteunende hardware ook al niet bijzonder hun best doet om de boel vlot te laten lopen en dat er niet alleen een transitie "topix -> react" was, maar ook een transitie "got single server -> got multiple server", "got niet achter loadbalancing -> got wel achter loadbalancing", "got niet van nfs/file-sharing -> got wel van nfs/file-sharing".

Waarom zou je willen checken op dubbelheid van info? Dan maak je die velden toch zeker gewoon UNIQUE?

Beste jongen, dan WORDT er toch een check gedaan op dubbelheid? Dat de database dat doet is dan leuk, maar ook voor de database is een bewerking niet gratis.
En juist voor de database geldt dat een insert/update/delete een heel stuk slomer is dan een select.

Kun je in PHP weer de error opvangen van je update, waarin precies verteld wordt welke velden dubbel zijn.. beetje raar om dat in php te doen als dat op database niveau al gebeurd

Dat is sowieso nog een erg vieze oplossing, om er maar vanuit te gaan dat de query "wel fout gaat".
Sowieso noemde chem nog een aantal andere handelingen (wijzigen van wachtwoord bijv, moet weer een mailtje opleveren en dat moet dus gecontroleerd worden) die bij een normale pageview niet gedaan worden.

Ik kan me de laatste #55 niet herinneren.. is de databaseload nog wel zo'n issue?

Er worden dan ook geen #55's meer gegeven door react

Maar de database load is wel degelijk een gevoelige factor, als we bijvoorbeeld op de search-indexer continue mee laten draaien wordt het forum duidelijk merkbaar trager en de load op de database schiet dan omhoog.

En daar zit je nu ook al mee, met laatste bezoeken e.d. (er vanuit gaande dat die in de users table wordt opgeslagen).

Ja, klopt.
Maar we hebben het er over dat het er MEER worden, hoe toegankelijker de devvers van zoiets het maken, hoe erger het wordt.
Vooral dus als het op de "nelske-manier" wordt toegepast, dan wordt voor elke view van iemand niet 1 user-entry bijgewerkt, maar bijvoorbeeld 3 of 4...
Met niet alleen simpelweg een update van de lastvisit-tijd, maar dus ook al die extra controles.

[chem]

strlen, ik had nog zin om je een serieus antwoord te geven maar elke aandrang is me wel ontgaan.
Het is me wel duidelijk dat je geen flauw idee hebt waar we mee bezig zijn, laat staan wat het submitten van een profiel voor invloed heeft op de load, of waarom we afraden om dit automagisch te doen.

Niet alleen vind ik het kinderachtig om dynamisch je signature aan te passen (persoonlijk), ten tweede vind ik het totaal onnodig om te kijken waar de load zou zijn, en hoe ik die zou kunnen omzeilen als mensen dit en masse gaan doen dmv. open source software (en helemaal als dit op 'views' gelinkt gaat worden).

Nee, ik besteed liever m'n tijd aan andere zaken.

Goede middag.

[RvdH]

Osiris schreef op 11 september 2002 @ 15:05:
[...]

Wow!

Mag ik je er op wijzen, dat GoT nog steeds een GRATIS iets is??? Als jij nou centen er voor neer zou leggen, okay, maar je kunt niet eisen dat ze het sneller maken!

Bouw anders je eigen forum dat wel sneller is ofzow

Ik eis helemaal niks. Ik vind het alleen frappant dat developers eerst allemaal extra functies e.d. gaan maken, en daarna pas bedenken hoe ze de zut efficient moeten schrijven.
Tweakers.net legt er centen voor neer, en zij zouden moeten eisen dat Parse z'n code beter schrijft.

ACM schreef op 11 september 2002 @ 16:07:
[nohtml]
[...]
Ik geef jou een argument waarom React tov Tweakers.net trager is, ondanks het gebruik van de loadbalancers die ook nog steeds niet helemaal goed de load balancen.
[...]

Maar de loadbalancers hebben er toch niks mee te maken dat React NFS gebruikt? Wederom, als dat de bottleneck is, waarom dan wachten met React files op de servers plaatsen en van NFS afstappen?

Juist die users die zoveel moeite voor een icon doen zullen we aardig actief zijn.
[...]

Best, maak je van 1,nogwat requests per seconde, 5,nogwat requests per seconde. Kunnen die servers nog steeds makkelijk aan...

Zei ik dat dan
Er worden extra zaken gelogd wat extra inserts betekend.

Sorry, begreep ik er uit. Dus er worden extra zaken gelogged.. hoe is dat anders dan een gewone pageview?

Klopt, maar ik heb geen 50k gebruikers voor handen op een testserver, jij wel?
Performance implicaties kan je gewoon bijna niet testen met een testserver, statische benchmarks leveren lang niet altijd goede informatie op, zeker met dit soort zaken niet.

Je hebt toch een testforum? Ga dan eerst 10 minuten eroverheen surfen zonder dynamische signatures van users, en kijk bij elke request naar die getalletjes onderin. Daarna doe je hetzelfde met 10 useraccounts die elk 1 keer per minuut hun dingetjes updaten, en kijk weer naar die getalletjes. Gemiddelde getalletjes vergelijken, en dan (het verschil / 10) * voorspelde dynamische accounts? Dan heb je de tijd die het per page ongeveer zal schelen met 1 actieve user. Vermenigvuldigen met aantal actieve users..

Niets is niet te testen.

Neuh, dat is meer een soort luiheid, desinteresse, hoe je het wilt noemen.

Waarom reageer je dan nog als het je toch niet interesseert?

En je denkt toch niet dat wij daar niet mee bezig zijn?

React was een pakket compleet nieuwe code voor een setup als de onze, daar zitten gewoon zaken in die wellicht efficienter kunne, daarbij komt nog dat de ondersteunende hardware ook al niet bijzonder hun best doet om de boel vlot te laten lopen en dat er niet alleen een transitie "topix -> react" was, maar ook een transitie "got single server -> got multiple server", "got niet achter loadbalancing -> got wel achter loadbalancing", "got niet van nfs/file-sharing -> got wel van nfs/file-sharing".

Goh.. na al die dingen die je hier opnoemt, is het forum trager geworden.
Waarom bespaar je je al die moeite niet door eerst dingen uit te testen?
En dat die dingen nu doorgevoerd zijn, betekent toch niet dat het niet meer teruggedraaid kan worden? D'r is niks beschamends aan "Okay, het werkte niet, dus we hebben het weer zoals het eerst was en nu is het weer snel".

Beste jongen, dan WORDT er toch een check gedaan op dubbelheid? Dat de database dat doet is dan leuk, maar ook voor de database is een bewerking niet gratis.

PRECIES. Dus doe je de check dubbel als je het in PHP nog eens doet!

En juist voor de database geldt dat een insert/update/delete een heel stuk slomer is dan een select.

Dat maakt niet uit, want die update moet toch plaatsvinden.

Dat is sowieso nog een erg vieze oplossing, om er maar vanuit te gaan dat de query "wel fout gaat".

Daar ga je niet van uit, dat controleer je.

code:

$sql = "INSERT INTO blaat (veld1, veld2) VALUES (?,?)";
$sth = $dbh->prepare($sql);
if (!$sth) { 
    print "deze query is brak";
} elsif (!$sth->execute("bestaande-entry","blaat")) {
    if ($sth->errno == x) { 
       print "dubbele entry: " . $dbh->errstr;
    } else { 
       print "andere error: " . $dbh->errstr;
    }
} else {
    print "je profile is met succes bijgewerkt.";
}

Iets dergelijks, maar dan in PHP.

Sowieso noemde chem nog een aantal andere handelingen (wijzigen van wachtwoord bijv, moet weer een mailtje opleveren en dat moet dus gecontroleerd worden) die bij een normale pageview niet gedaan worden.

Je hebt toch wel een user-object oid met het password van de submittende user, waar je makkelijk een ifje op los kan laten?

Er worden dan ook geen #55's meer gegeven door react

Maar de database load is wel degelijk een gevoelige factor, als we bijvoorbeeld op de search-indexer continue mee laten draaien wordt het forum duidelijk merkbaar trager en de load op de database schiet dan omhoog.
[...]

Beetje kromme vergelijking, een indexer en een profile-update... Ligt het niet gewoon aan de indexer? Die tijdelijke search in het mededelingen forum doet het toch ook goed?

Ja, klopt.
Maar we hebben het er over dat het er MEER worden, hoe toegankelijker de devvers van zoiets het maken, hoe erger het wordt.
Vooral dus als het op de "nelske-manier" wordt toegepast, dan wordt voor elke view van iemand niet 1 user-entry bijgewerkt, maar bijvoorbeeld 3 of 4...
Met niet alleen simpelweg een update van de lastvisit-tijd, maar dus ook al die extra controles.

Jammer dat het erger wordt.. maar wat wou je ertegen doen? Iedereen met een dyn. profiel bannen ofzo?

chem schreef op 11 september 2002 @ 16:14:
strlen, ik had nog zin om je een serieus antwoord te geven maar elke aandrang is me wel ontgaan.
Het is me wel duidelijk dat je geen flauw idee hebt waar we mee bezig zijn, laat staan wat het submitten van een profiel voor invloed heeft op de load, of waarom we afraden om dit automagisch te doen.

Als het submitten van een bepaalde form substantiele invloed heeft op de load, dan ben je erg verkeerd bezig.

Niet alleen vind ik het kinderachtig om dynamisch je signature aan te passen (persoonlijk),

Wat voor boodschap hebben wij daaraan? Ik vind het onzin om je systeemspecs in je sig op te nemen, maar die mensen hebben daar schijnbaar behoefte aan.

ten tweede vind ik het totaal onnodig om te kijken waar de load zou zijn, en hoe ik die zou kunnen omzeilen als mensen dit en masse gaan doen dmv. open source software (en helemaal als dit op 'views' gelinkt gaat worden).

Ik ben bang dat je na verloop van tijd geen andere keuze meer hebt?
Je kunt wel koppig blijven nee-schudden, maar als straks het forum *nog* trager is omdat een bepaalde developer niet houdt van dynamische sigs, dan zal je klant, t.net, ook aan de bel gaan hangen. En dan zul je alsnog moeten werken voor je geld.

[Kaasplank]

man wat kun jij zeuren zeg. echt waar.

[jelmervos]

Uhmz, oke, ik denk dat ik m'n antwoord wel heb.
Beetje rustig heren, straks loopt het uit de hand.

Ik zal de source voor mezelf houden en niet te vaak mijn profile bewerken.

Bedankt voor de zeer uitgebreide antwoorden heren, ga zo door.

[ACM]

strlen schreef op 11 september 2002 @ 20:08:
Maar de loadbalancers hebben er toch niks mee te maken dat React NFS gebruikt? Wederom, als dat de bottleneck is, waarom dan wachten met React files op de servers plaatsen en van NFS afstappen?

Geen fuck inderdaad, maar jij begint te mieren dat de loadbalancers wel goed voor Fok! en tweakers.net LIJKEN te werken en niet voor react.
Dat argument spreek ik tegen.

Best, maak je van 1,nogwat requests per seconde, 5,nogwat requests per seconde. Kunnen die servers nog steeds makkelijk aan...

Vast wel, en 10/sec ook wel en 20/sec ook wel en ...
Ga maar door...

Sorry, begreep ik er uit. Dus er worden extra zaken gelogged.. hoe is dat anders dan een gewone pageview?

Er wordt _meer_ gelogd dan bij een gewone pageview.

Je hebt toch een testforum? Ga dan eerst 10 minuten eroverheen surfen zonder dynamische signatures van users, en kijk bij elke request naar die getalletjes onderin. Daarna doe je hetzelfde met 10 useraccounts die elk 1 keer per minuut hun dingetjes updaten, en kijk weer naar die getalletjes. Gemiddelde getalletjes vergelijken, en dan (het verschil / 10) * voorspelde dynamische accounts? Dan heb je de tijd die het per page ongeveer zal schelen met 1 actieve user. Vermenigvuldigen met aantal actieve users..

Owja... 10 minuten surfen over een testsite met 10 accounts die 1x per minuut wat doen.
En dan nog denken dat het lineair schaalbaar is ook...
FYI: De wereld schaalt op dit soort gebieden slechts zeer beperkt lineair en boven bepaalde thresholds zal het eerder kwadratisch of zelfs exponentieel zijn.

Met de door jou voorgestelde test zul je inderdaad zeer zeker niet een performance verlies zien.

Niets is niet te testen.

Klopt, maar een test moet wel representatief zijn.

Waarom reageer je dan nog als het je toch niet interesseert?

Dat vraag ik me idd ook af...

Goh.. na al die dingen die je hier opnoemt, is het forum trager geworden.
Waarom bespaar je je al die moeite niet door eerst dingen uit te testen?
En dat die dingen nu doorgevoerd zijn, betekent toch niet dat het niet meer teruggedraaid kan worden? D'r is niks beschamends aan "Okay, het werkte niet, dus we hebben het weer zoals het eerst was en nu is het weer snel".

Zou het toevallig niet dan wel getest zijn? Maar de performance implicaties onderschat.
En het min of meer ons het idee kunnen geven: "Het is weliswaar nog slomer nu, maar nog makkelijk werkbaar dus geen noodzaak om terug te gaan aangezien dit wel veiliger is" ?

PRECIES. Dus doe je de check dubbel als je het in PHP nog eens doet!

Dubbel
Eerst zeg je dat je dat niet moet checken en dan zeg je dat de unique constraint dat af moet gaan dwingen.

Je spreekt jezelf tegen, daar had ik het over.
Overigens is het in php gechecked omdat react niet alleen voor GoT gebruikt wordt en er ook klanten zijn die geen unieke emailadressen willen...
Maar dan nog, ook de unique constraints check is niet gratis...

Dat maakt niet uit, want die update moet toch plaatsvinden.

De update gaat alleen wel vooraf van een aantal extra zaken, die er eerst niet waren.

Daar ga je niet van uit, dat controleer je.

Dat snapte ik ook nog wel.

Je hebt toch wel een user-object oid met het password van de submittende user, waar je makkelijk een ifje op los kan laten?

Waarom zou het userobject het huidige pass bijhouden
En dan nog, er moet nog steeds gecontroleerd worden een md5 gedraait noem maar op, allemaal zaken die anders niet gedaan worden bij een normale pageview.

Beetje kromme vergelijking, een indexer en een profile-update... Ligt het niet gewoon aan de indexer? Die tijdelijke search in het mededelingen forum doet het toch ook goed?

De indexer select data uit en insert, delete en update data in de mysql tabel.
Dat eerste maakt overduidelijk niet zo uit, want "die tijdelijke search doet het toch ook goed?" (die werkt dus niet met mysql als opslag medium), maar het delete/update/etc deel maakt dus wel degelijk uit.

Jammer dat het erger wordt.. maar wat wou je ertegen doen? Iedereen met een dyn. profiel bannen ofzo?

Neuh, maar het ging hier over of we het gebruik wel of niet moeten aanmoedigen door de boel opensource te maken en daar is het antwoord 'nee' op...

Als het submitten van een bepaalde form substantiele invloed heeft op de load, dan ben je erg verkeerd bezig.

Niet als dat form relatief weinig opgevraagd wordt...
En ook niet bedoelt is om vaak opgevraagd te worden.

Het plaatsen van een reactie is ook veel zwaarder dan een normale pageview.

Ik ben bang dat je na verloop van tijd geen andere keuze meer hebt?
Je kunt wel koppig blijven nee-schudden, maar als straks het forum *nog* trager is omdat een bepaalde developer niet houdt van dynamische sigs, dan zal je klant, t.net, ook aan de bel gaan hangen. En dan zul je alsnog moeten werken voor je geld.

Och, ik kan de source code inkijken wanneer ik wil en als ik dan inzie dat de code gewoon niet of nauwelijks efficienter kan lijkt me niet dat ik nog recht heb op klagen bij parse.
Echter kan ik wel het gebruik van dynamische sigs (als dat de oorzaak is) tegen gaan dan...

[Glimi]

Er wordt hier gepraat over een dynamisch profiel. Lijkt me leuk, elke minuut een andere naam, e-mail en geslacht. Lekker nuttig ook

Maar even inzoomen op de sigs/ondertitels: Ik zie het nut in de eerste plaats niet en in de twee plaats lijkt me deze drempel te laag, zodat een te grote groep mensen het zal gaan gebruiken. Hoe je het ook went of keert, het kost gewoon performance. En dan niet performance van jou, maar van iedereen.
Dus omdat enkele mensen gebruik willen maken van sigs waarin ze hun ziel dynamisch in kwijt kunnen, moet iedereen hier bloeden?

Misschien kan het forum het nu wel aan ( vraag ik me af, want waarom loopt de indexer dan nog niet? ) zodat het niet te veel performance kost, maar wat als er zich na verloop van tijd 1000 users aanmelden en actief worden? Juist, dat kost load. Maw de load die dynamische sigs veroorzaken kan ook ingezet worden voor nieuwe users.

Jij kiest voor de sigs zie ik, maar het is niet jouw performace. De admin beslist gewoon in dit geval of hij/zij het nuttig genoeg vindt om performance X eraan te besteden. En dat vind ik nou een beetje raar qua discussiestijl van u. Je doet het namelijk voorkomen alsof ze bovenstaande afweging niet mogen maken zonder discussie