FOK! is (niet) traag *O*
Game on.
!11!1 @ TT.
quote:
quote:Voor 15k koop je minstens 2 HP DL380's (of 1 570) met 4 Xeon (of 2 quadcores) processoren, 8gb geheugen, 2 raid-controllers, een 4uur's carepack en genoeg sas-schijfjes om fok in 10-voud op te slaan.Op dinsdag 8 april 2008 18:13 schreef ACM het volgende:
Voor een redelijk budget (10-15k euro ofzo) moet je een heel wat vlottere machine aan kunnen schaffen dan je nu hebt
Voor 5k koop je ook een prima server die op de toekomst is voorbereid...(en zeker als je niet veel waarde hecht aan een topmerk)
Misschien wel aan de load balancer die het (niet) goed aan kan?
Een databaseserver die niet goed staat?
quote:...ik geef alleen antwoord op de ietwat ruime budgettering van ACM.Op dinsdag 8 april 2008 21:25 schreef Netsplitter het volgende:
Wie zegt dat het aan de servers ligt?
quote:Was ook niet echt tegen jou gericht, meer in het algemeen.Op dinsdag 8 april 2008 21:26 schreef Kreator het volgende:
[..]
...ik geef alleen antwoord op de ietwat ruime budgettering van ACM.
Het is echt weer drama met Fok! de laatste tijd.
quote:Die gaat niet zo traag als het forum, maar verbruikt net zoveelOp dinsdag 8 april 2008 21:28 schreef pvc_boer het volgende:
En zijn hummer dan ?
quote:Pssst... het ís op bepaalde tijden trager!Op dinsdag 8 april 200821:31 schreef Juup© het volgende:
Het lijkt net of het op bepaalde tijden trager is. Over het algemeen heb ik er niet zo veel last van.
quote:Dan klopt het dus wat ik waarneemOp dinsdag 8 april 2008 21:34 schreef mcDavid het volgende:
[..]
Pssst... het ís op bepaalde tijden trager!
quote:Het is wel sneller, behalve op de momenten dat het langzamer is.Op dinsdag 8 april 2008 22:02 schreef mcDavid het volgende:
Sneller wel. Maar het is meer alsof het probleem zich verplaatst heeft naar DB-foutmeldingen.
Het varieert enorm. Regelmatig gaat het snel, maar regelmatig duurt het lang en krijg je een DB-foutmelding.
Maar goed als Danny/Iteejer weer in het topic te vinden zijn kunnen ze daar best commentaar op geven.Die XSL opzet zou in eerste instantie voor iedereen gelijk zijn... en heeft een geintegreerde FQR
quote:En nu in lekentaal aub?Op dinsdag 8 april 2008 22:12 schreef Skinkie het volgende:
Ik kan alleen daar wat aan doen als 50% van de gebruikers mee gaat naar een XSL opzet
Die XSL opzet zou in eerste instantie voor iedereen gelijk zijn... en heeft een geintegreerde FQR
quote:Boeit niet, het probleem zit hem in het ophalen van de daadwerkelijke data. Dat is alleen op te lossen door een snellere database/webserver opstelling. Of het cachen van de data.Op dinsdag 8 april 2008 22:41 schreef SlimShady het volgende:
ideetje: ipv dat de site het opgeeft, de text-only versie laden van het topic/pagina?
quote:Als ik iedereen aan een snelle versie van Fok krijg die er hetzelfde uitziet als Replique maar dat niet is... dan kan Replique door modjes en admins gebruikt blijven worden. En zijn de n00b users overgeleverd aan alleen de 'reply' functionaliteit van het forum.Op dinsdag 8 april 2008 22:43 schreef Juup© het volgende:
En nu in lekentaal aub?
Dus je hebt alleen met replique te maken als je reageert. Voor de rest zou alles flitsend snel moeten zijn, zelfs als replique traag is. (...je zal dat ook geen veranderingen zien, maar gewoon een snel geladen pagina op het scherm).
quote:...Want die haalt de posts niet uit de database?Op dinsdag 8 april 200822:41 schreef SlimShady het volgende:
ideetje: ipv dat de site het opgeeft, de text-only versie laden van het topic/pagina?
quote:Aha, mijn dankOp dinsdag 8 april 2008 22:46 schreef Skinkie het volgende:
[..]
Als ik iedereen aan een snelle versie van Fok krijg die er hetzelfde uitziet als Replique maar dat niet is... dan kan Replique door modjes en admins gebruikt blijven worden. En zijn de n00b users overgeleverd aan alleen de 'reply' functionaliteit van het forum.
Dus je hebt alleen met replique te maken als je reageert. Voor de rest zou alles flitsend snel moeten zijn, zelfs als replique traag is. (...je zal dat ook geen veranderingen zien, maar gewoon een snel geladen pagina op het scherm).
De laatste tijd als ik inlog, krijg ik direct al een foutmelding. Maar ik zal de enige niet zijn.
quote:8GB is veel te weinig, ik zou voor minstens 16GB gaan en door de grootte van het forum hier zou ik eerder naar 24GB of 32GB kijken... 't Is dat 4GB-modules nog erg duur zijn, anders zou je zelfs alle banken daarmee kunnen vullen (meer is beter tenslotte). En uiteraard ging ik uit van 8-cpu cores. En sowieso 4 uurs support, het is tenslotte wel een nogal belangrijke server.Op dinsdag 8 april 2008 21:21 schreef Kreator het volgende:
Voor 15k koop je minstens 2 HP DL380's (of 1 570) met 4 Xeon (of 2 quadcores) processoren, 8gb geheugen, 2 raid-controllers, een 4uur's carepack en genoeg sas-schijfjes om fok in 10-voud op te slaan.
Verder maak je een denkfout over de schijfcapaciteit. De diskgrootte is namelijk niet zo belangrijk, het aantal beschikbare diskheads wel. Om het maar in hp-termen te houden, ik zou liever - voor onze databases - een MSA70 met 25x36GB schijven hebben dan een MSA20 met 10x146GB schijven.
Magoed, fok zou een wat meer advies en eventueel offerte kunnen opvragen aan Dell van een dell poweredge 1950 of 2950 en daar een md1000 of md3000 aan gekoppeld.
quote:Op woensdag 9 april 200800:26 schreef Dubbeldrank het volgende:
Firefox 3 Beta 5 sneller dan Safari 3.1 op Mac OS X
Ik kan niet wachten tot mijn plugins het doen op Fx3 
quote:Dan zit je nog steeds schaalbaarheid problemen actief te creeeren in plaats van op te lossen... steeds een database keer twee doen omdat je views langzaam zijn, kom op zeg...Op woensdag 9 april 2008 09:23 schreef ACM het volgende:
8GB is veel te weinig, ik zou voor minstens 16GB gaan en door de grootte van het forum hier zou ik eerder naar 24GB of 32GB kijken...
quote:Tuurlijk, het houdt een keer op. De scheiding tussen frontpage en forum is in feite ook weer een verdubbeling van de capaciteit. Maar anderzijds is het vziw een hele gebruikelijke methode om je systeemperformance te verhogen, als de belasting gestegen isOp woensdag 9 april 2008 11:28 schreef Skinkie het volgende:
Dan zit je nog steeds schaalbaarheid problemen actief te creeeren in plaats van op te lossen... steeds een database keer twee doen omdat je views langzaam zijn, kom op zeg...
Jouw oplossing die, op magische wijze, alle belasting omtovert naar enkel nog wat data uit het geheugen lezen en verder als bottleneck enkel nog de netwerkinterface overhoudt is - zelfs als het volledig op de door jou voorgestelde manier blijkt te werken - nog lang niet productieklaar. Bovendien is zo'n zwaar systeem ook bruikbaar nadat de boel gesplitst is of als basis voor jouw oplossing.
quote:Ik hoop volgende week een demo te hebbenOp woensdag 9 april 2008 12:53 schreef ACM het volgende:
Jouw oplossing die, op magische wijze, alle belasting omtovert naar enkel nog wat data uit het geheugen lezen en verder als bottleneck enkel nog de netwerkinterface overhoudt is - zelfs als het volledig op de door jou voorgestelde manier blijkt te werken - nog lang niet productieklaar. Bovendien is zo'n zwaar systeem ook bruikbaar nadat de boel gesplitst is of als basis voor jouw oplossing.
Dan zal ik de hardware specs ook wel bekend maken quote:Eens. Er zitten vlotte periodes bij, maar soms is het echt heel kut.Op woensdag 9 april 2008 16:03 schreef Samson het volgende:
Ik weet het niet hoor, het is nu midden op de dag, heel weinig gebruikers en gasten online en het eerste wat ik zag: momenteel is het te druk, blabla. Er zit toch echt iets helemaal niet goed. De laatste tijd is het echt een drama af en toe
quote:Ik krijg de indruk dat het forum weer vooral rond de hele uren problemen heeft. Zowel om 21:57 als 22:57 werd FOK! hier een minuut of 6 a 7 zeer slecht bereikbaar, en daarna dan wordt het dan wel weer even beter.Op woensdag 9 april 2008 23:03 schreef TheSorrow het volgende:
[..]
Eens. Er zitten vlotte periodes bij, maar soms is het echt heel kut.
quote:Brandweer is ook niet altijd even snel met al die verkeersdrempels tegenwoordig
quote:Daarom. Zolang het maar niet affikt, is alles best!Op woensdag 9 april 2008 23:20 schreef Juup© het volgende:
[..]
Brandweer is ook niet altijd even snel met al die verkeersdrempels tegenwoordig
quote:Klopt, zie het bugforum BUGOp dinsdag 8 april 200823:26 schreef Wickedangel het volgende:
Die trechter in de OP [afbeelding]
De laatste tijd als ik inlog, krijg ik direct al een foutmelding. Maar ik zal de enige niet zijn.
quote:ik kon iig geen verbinding maken..
quote:Ja!..
Ik was maar even wat anders gaan doen! Toen ik terug kwam deed ie 't weer!..
quote:vast welOp zondag 13 april 2008 13:05 schreef PDOA het volgende:
Godsamme, kan het nog trager??
Wel fucking traag weer..
Jammer ook dat als je een post typt en je vergeet hem even te kopiëren dat je hem dan na een foutmelding weer helemaal opnieuw kunt typen
Total loading time: 11.8 seconds
Total objects: 40 (192.6 KB)
External objects: 38 (116.6 KB)
HTML (X)HTML: 1 (69.5KB)
RSS/XML: 0
CSS: 1 (36.1KB)
Scripts: 10 (67.8KB)
Images: 28 (19.2KB)
Plugins: 0
Other: 0
Redirected: 0
Maar daarvoor had ik er een die 26.97 sec duurde
en bijna alles vanaf i.fokzine.net duurt langer dan 2 sec.
Op dit moment zijn de "posticons" zelfs nog aan het laden.
Op alle andere sites waar ik dagelijks kom heb ik dit probleem niet, alleen op Fok.
quote:Als in Cherokee weer op een load van 11... of wat anders?Op zondag 13 april 2008 16:40 schreef HuHu het volgende:
Er was een probleempje met de fileserver, daardoor deden de plaatjes het even niet en was het nog trager. Dat probleem is verholpen.
quote:30Op zondag 13 april 2008 16:42 schreef Skinkie het volgende:
[..]
Als in Cherokee weer op een load van 11... of wat anders?
Ik heb 'm herstart om het te verhelpen.
quote:Breuls gaat mensen klappen gevenOp zondag 13 april 2008 16:43 schreef Breuls het volgende:
[..]
30
Ik heb 'm herstart om het te verhelpen.
quote:Als een herstart het oplost krijg ik het vermoeden dat er langzaam iets volloopt waardoor het na verloop van tijd steeds trager wordt.Op zondag 13 april 2008 16:43 schreef Breuls het volgende:
[..]
30
Ik heb 'm herstart om het te verhelpen.
quote:No shit sherlockOp zondag 13 april 2008 16:46 schreef The_Terminator het volgende:
[..]
Als een herstart het oplost krijg ik het vermoeden dat er langzaam iets volloopt waardoor het na verloop van tijd steeds trager wordt.
quote:Ach ja, het zou ook al wel bekend zijn, echter vraag ik mij af waarom er dan nog stees geen concrete oplossing voor gevonden is.
quote:Trial and error waarschijnlijkOp zondag 13 april 2008 16:49 schreef The_Terminator het volgende:
[..]
Ach ja, het zou ook al wel bekend zijn, echter vraag ik mij af waarom er dan nog stees geen concrete oplossing voor gevonden is.
quote:Tja, dat is juist het vervelende eraan, het doet zich pas na verloop van tijd voor. Echter als het na een herstart weer supersnel is dan zou je zeggen dat de huidige hardware het met gemak zou moeten trekken, en dat het probeem ergens in de database zelf zit. Maargoed, kom er maar eens achter wat het veroorzaakt.
quote:Probeer zal ook in Cherokee zittenOp zondag 13 april 2008 16:57 schreef Anthraxx het volgende:
Of de software is gewoon ruk geconfigureerd / geprogrammeerd / whatever. Ik geloof niet helemaal meer dat het probleem RDE zelf is.
En laat ik hier dan ook nog maar even zeggen dat ik de oplossing voor youtube filmpjes heel erg leuk vind.
Daarnaast natuurlijk deze tweede keer dat dit gebeurd en heb ik het nog een keer mee genomen richting de devcrew van Cherokee. Fok is niet de enige site die op Cherokee draait, maar wel de site die de meeste nieuwe features gebruikt.
quote:Er draait al eeuwen monitoring voor de load, dus ik heb je scriptje niet ingesteld als je het niet erg vindt.Op zondag 13 april 2008 17:22 schreef Skinkie het volgende:
Ik heb aan Breuls/Iteejer gevraagd een scriptje te draaien die de load gaat bijhouden.
quote:misschien op basis van die loadmonitoring automatisch dingen laten gebeuren? Dus in plaats van monitoren dat de load 10 is en dan 20 en dan 30 en dat dan de boel plat ligt tot er iemand op het lumineuze idee komt de server een kontschop te geven dit automatisch te doen? Dus; hej, de load is 10, even een alert naar wat serveradmins. Oeps, de load is 20? Even de server automagisch een rotschop geven zodat de user geen verdere hinder ondervindt.Op zondag 13 april 2008 17:47 schreef Breuls het volgende:
[..]
Er draait al eeuwen monitoring voor de load, dus ik heb je scriptje niet ingesteld als je het niet erg vindt.
Zoiets.
quote:Automatiseren bedoel jeOp zondag 13 april 2008 18:27 schreef Danny het volgende:
[..]
misschien op basis van die loadmonitoring automatisch dingen laten gebeuren? Dus in plaats van monitoren dat de load 10 is en dan 20 en dan 30 en dat dan de boel plat ligt tot er iemand op het lumineuze idee komt de server een kontschop te geven dit automatisch te doen? Dus; hej, de load is 10, even een alert naar wat serveradmins. Oeps, de load is 20? Even de server automagisch een rotschop geven zodat de user geen verdere hinder ondervindt.
Zoiets.
Dat is serieus te krap bemeten
Als de loads laag blijven zit er echt iets fout in de configuratie van het geheel, want een forum als dit (zwaarder dan GoT) zou zeker voor een flinke sloot taken moeten zorgen.quote:(B)locking io hoeft niet voor hoge loads te zorgen... terwijl je toch wacht.Op zondag 13 april 2008 19:48 schreef oshiro het volgende:
Draait heel fok nou nog steeds op die dual Xeon 3,06GHz bak met 6GB ram?
Dat is serieus te krap bemeten
quote:Je zit in principe gewoon vast aan een bepaald aantal transacties die uitgevoerd moeten worden binnen een bepaalde tijd. Als dat niet lukt stapelt de boel zich op.Op zondag 13 april 200819:52 schreef Skinkie het volgende:
[..]
(B)locking io hoeft niet voor hoge loads te zorgen... terwijl je toch wacht.
Ik vraag me ook af of het XSL-idee gaat werken want het enige wat je doet is het verplaatsen van het probleem van de database naar file-IO.
quote:Ik neem aan dat je begrijp dat een block cache in ram dan wel een ramdisk dit probleem totaal niet heeft. Daarbij het aantal actieve topics van een forum als dit met gemak in een reepje geheugen past.Op zondag 13 april 2008 20:29 schreef oshiro het volgende:
Je zit in principe gewoon vast aan een bepaald aantal transacties die uitgevoerd moeten worden binnen een bepaalde tijd. Als dat niet lukt stapelt de boel zich op.
Ik vraag me ook af of het XSL-idee gaat werken want het enige wat je doet is het verplaatsen van het probleem van de database naar file-IO.
oke wat is er aan de hand met fok quote:Dat is al sinds het begin der tijden zoOp maandag 14 april 2008 10:21 schreef admiraal_anaal het volgende:
quote:Ja, en als het een beetje goed in elkaar steekt zat dat deel van de database dus ook al in het geheugenOp zondag 13 april 200820:48 schreef Skinkie het volgende:
[..]
Ik neem aan dat je begrijp dat een block cache in ram dan wel een ramdisk dit probleem totaal niet heeft. Daarbij het aantal actieve topics van een forum als dit met gemak in een reepje geheugen past.
Ik zit me gewoon af te vragen hoe het nou zit. Deze forumsoftware verschilt weinig van enige andere software. Via php worden posts uit een database getrokken en de webservers bouwen dan de pagina op. Bij een miljoen andere fora werkt het, waarom hier dan niet? Waarom moet je het wiel opnieuw gaan uitvinden terwijl het andere idee prima zou moeten werken?
quote:Maar je vergeet dat in de huidige wereld zonder geïntegreerde software voor iedere request een database connect moet worden gedaan door een los 'programmaatje' (in een thread dan wel een fork). En ten opzichte van een (gecachede) filesystem lookup dit gewoon overhead is.Op maandag 14 april 2008 12:01 schreef oshiro het volgende:
Ja, en als het een beetje goed in elkaar steekt zat dat deel van de database dus ook al in het geheugen
quote:We kunnen hier als gebruikers alleen maar raden waarom het hier niet werkt. Als eerste is alle statische content naar 1 server gehaald om de load op het webserver platform naar beneden te halen, wat daarmee ook het NFS verkeer moet hebben verlaagd naar de fileserver. (Resultaat; als de pagina binnen komt, zou de statische content niet lang op zich hoeven laten wachten.)Ik zit me gewoon af te vragen hoe het nou zit. Deze forumsoftware verschilt weinig van enige andere software. Via php worden posts uit een database getrokken en de webservers bouwen dan de pagina op. Bij een miljoen andere fora werkt het, waarom hier dan niet? Waarom moet je het wiel opnieuw gaan uitvinden terwijl het andere idee prima zou moeten werken?
Vervolgens blijken ook andere bottlenecken als adservers en database servers om mysterieuze redenen niet snel genoeg te zijn.
quote:Omdat we anders nog steeds in een T-Ford zouden rijden?Op maandag 14 april 2008 12:01 schreef oshiro het volgende:
Waarom moet je het wiel opnieuw gaan uitvinden terwijl het andere idee prima zou moeten werken?
En je kan ook veel tijd steken in het modificeren van software zodat het wel op jouw wensen aansluit, en er dan achter komen dat na een update de helft niet meer werkt, of je bouwt je systeem zelf, zodat je weet dat het werkt
quote:TrueOp maandag 14 april 200812:43 schreef Skinkie het volgende:
[..]
Maar je vergeet dat in de huidige wereld zonder geïntegreerde software voor iedere request een database connect moet worden gedaan door een los 'programmaatje' (in een thread dan wel een fork). En ten opzichte van een (gecachede) filesystem lookup dit gewoon overhead is.
[..]
We kunnen hier als gebruikers alleen maar raden waarom het hier niet werkt. Als eerste is alle statische content naar 1 server gehaald om de load op het webserver platform naar beneden te halen, wat daarmee ook het NFS verkeer moet hebben verlaagd naar de fileserver. (Resultaat; als de pagina binnen komt, zou de statische content niet lang op zich hoeven laten wachten.)
Vervolgens blijken ook andere bottlenecken als adservers en database servers om mysterieuze redenen niet snel genoeg te zijn.
Op een dag als gister zag je dat eigenlijk alles te langzaam was, maar over het algemeen is het inderdaad vaker zo dat er lang gewacht moet worden op de db-content (als die überhaupt komt ) en de adservers (waarvoor eigenlijk alleen google maar lief aangekeken kan worden denk ik)...En zo kwam ik een beetje uit bij mijn punt over dat een dual 3,06 Ghz Xeon (dus nog niet de Core Xeons) toch eigenlijk wel een beetje zwak is voor een db-server
Dit hangt ook erg af van de HBA en de hoeveelheid geheugen dus.quote:Of je gaat uit van een systeem dat bij iedereen werkt en helemaal niet zo archaisch is (waarom werkt het dan bij de rest wel naar behoren), of je gaat zelf een compleet nieuw systeem ontwikkelen met alle haken, ogen en kinderziektes van dien.Op maandag 14 april 200812:58 schreef qu63 het volgende:
[..]
Omdat we anders nog steeds in een T-Ford zouden rijden?
En je kan ook veel tijd steken in het modificeren van software zodat het wel op jouw wensen aansluit, en er dan achter komen dat na een update de helft niet meer werkt, of je bouwt je systeem zelf, zodat je weet dat het werkt
Overigens was de T-Ford de laatste ècht grote evolutie in de autotechniek, en wordt het grootste deel van de auto's van vandaag nog volgens hetzelfde principe van de productielijn met stations gefabriceerd
quote:Waarom hoor ik je dan alleen over hardware? Een op het vulkaan model gebaseerde database engine is opeens een performance monster?Op maandag 14 april 2008 13:01 schreef oshiro het volgende:
[..]
True
En zo kwam ik een beetje uit bij mijn punt over dat een dual 3,06 Ghz Xeon (dus nog niet de Core Xeons) toch eigenlijk wel een beetje zwak is voor een db-server
Iedereen die hier claimt dat de hardware van die machine te zwak is verklaar ik gewoon voor gek. Er wordt dagelijks niet 6GB aan verschillende data uitgewisseld. En ook niet 5, niet 4, niet 3, niet 2, en waarschijnlijk komt het ook niet boven de 1GB uit. Enig idee hoe fokking veel data 1GB aan tekst is? Even analoog aan e-mail, dat zouden zo'n 500.000 verschillende berichten per dag zijn.
Als alles in 1 neemt, dan kom je wel op een half miljoen in de buurt denk ik.
quote:Maar zo is het toch ook met fok? de basisprincipes zijn nog hetzelfde, alleen ziet het er niet hetzelfde uit als al die andere foraOp maandag 14 april 2008 13:04 schreef oshiro het volgende:
Overigens was de T-Ford de laatste ècht grote evolutie in de autotechniek, en wordt het grootste deel van de auto's van vandaag nog volgens hetzelfde principe van de productielijn met stations gefabriceerd
quote:Het gaat toch niet om sequentiële transfers? Het gaat om accestimes en transacties per seconde en daar kan met verschillende HBA's en schijven een flink verschil in zitten.Op maandag 14 april 200813:43 schreef Skinkie het volgende:
[..]
Waarom hoor ik je dan alleen over hardware? Een op het vulkaan model gebaseerde database engine is opeens een performance monster?
Iedereen die hier claimt dat de hardware van die machine te zwak is verklaar ik gewoon voor gek. Er wordt dagelijks niet 6GB aan verschillende data uitgewisseld. En ook niet 5, niet 4, niet 3, niet 2, en waarschijnlijk komt het ook niet boven de 1GB uit. Enig idee hoe fokking veel data 1GB aan tekst is? Even analoog aan e-mail, dat zouden zo'n 500.000 verschillende berichten per dag zijn.
En verder is het inderdaad zo dat er bij lange na geen 6GB aan DB-traffic gegenereerd zal worden (nu weet ik niet hoe groot de DB van FOK! is, maar dat zal toch wel 40 a 50GB of meer zijn gok ik zo, en dan zou je op een dag dus ruim 10% van de database uitlezen) maar die data die weggeschreven wordt zal zich niet altijd in het cache bevinden. Dus op het moment dat je in je cache gaat zitten ploegen (wat met de bandbreedte van die oude dual xeons toch al niet zo hard gaat) zit er nog wel wat pit in, maar als je vervolgens je schijven gaat benaderen zakt het nog verder in...
En de posts worden toch ook uit de database gelezen? Dat zorgt ook voor een flinke belasting, iig een stuk meer dan het schrijven.
Ik ben geen expert op databasegebied maar ik ben niet dom
Tweakers draait ook op MySQL en dat werkt gewoon goed. Ze hebben daar echter de DB-servers die vergelijkbaar waren met deze zo'n 1,5 jaar geleden ingewisseld voor twee kanonnen van servers.quote:Nee enkel de database, dus enkel de tekst van de posts, met alle data die daar omheen hangt zoals users, fobo, etcetera. De html-code wordt er omheen geplakt door de webservers, die er ook plaatjes tussen zetten van de servers met de statische data.Op maandag 14 april 200814:30 schreef Ulreazj het volgende:
Is dat verkeer voor alles subsites ? Of alleen voor het forum?
Als alles in 1 neemt, dan kom je wel op een half miljoen in de buurt denk ik.
quote:En zo is het toch ook met een Mercedes S-klasse? Die heeft toch ook 4 wielen, een paar zitplaatsen en een motor?Op maandag 14 april 200814:52 schreef qu63 het volgende:
[..]
Maar zo is het toch ook met fok? de basisprincipes zijn nog hetzelfde, alleen ziet het er niet hetzelfde uit als al die andere fora
Net zoals de T-Ford naar de Mercedes is de onderliggende software zoals MySQL en PHP vast wel geüpdate (er staat overigens weer een flinke update van MySQL voor de deur) net zoals de Mercedes verbeterd is ten opzichte van de T-Ford.
Fok ziet er wel anders uit dan de andere fora, maar dat komt door Replique. In principe zijn er best veel gelijkenissen. Alleen bij FOK lukt er iets niet, en we moeten er achter komen waar het nu precies fout gaat
quote:Onder Topix ging het anders prima hoor.Op maandag 14 april 2008 10:33 schreef Mike.Strutter het volgende:
[..]
Dat is al sinds het begin der tijden zo
quote:Het gaat om of dat er data van harddisk naar geheugen moet, of dat al die data al in het geheugen staat en wordt ondersteund door een HBA. (mmap'ing)Op maandag 14 april 2008 14:53 schreef oshiro het volgende:
Het gaat toch niet om sequentiële transfers? Het gaat om accestimes en transacties per seconde en daar kan met verschillende HBA's en schijven een flink verschil in zitten.
quote:Een index op welke plek het op disk staat is direct aan een index op welke plek het in het geheugen staat.En verder is het inderdaad zo dat er bij lange na geen 6GB aan DB-traffic gegenereerd zal worden (nu weet ik niet hoe groot de DB van FOK! is, maar dat zal toch wel 40 a 50GB of meer zijn gok ik zo, en dan zou je op een dag dus ruim 10% van de database uitlezen) maar die data die weggeschreven wordt zal zich niet altijd in het cache bevinden. Dus op het moment dat je in je cache gaat zitten ploegen (wat met de bandbreedte van die oude dual xeons toch al niet zo hard gaat) zit er nog wel wat pit in, maar als je vervolgens je schijven gaat benaderen zakt het nog verder in...
quote:Het mooie van een database met indices dat het eigenlijk gewoon MMIO kan toepassen. En copy-on-write. Kopieer locatie van data[index+1] met lengte data[index].En de posts worden toch ook uit de database gelezen? Dat zorgt ook voor een flinke belasting, iig een stuk meer dan het schrijven.
quote:Mensen moeten eens af van het paradigma dat het beter zou zijn om hardware bij te kopen, ten opzichte van devtijd te willen investeren. In dit geval zijn er tal van betere databases dan MySQL.Ik ben geen expert op databasegebied maar ik ben niet dom
Ik ben het gezeur over database een beetje zat aan het worden. Benchmarks op FOK! die eventueel gedaan worden komen toch niet voor de schermen uit... en het gebruik van database 'als een bestandsyteem' werkt alleen echt goed als het een contante connectie heeft, 90% van het geheugen krijgt en native wordt aangesproken als of het een echt bestandssysteem is, en niet een SQL frontend voor wat data.
Wat betreft implementatie zou WinFS native zijn, SQLFS een wrapper met constante connectie, en gezien http://lobotomy.sourceforge.net/docs/Graphical_SQL-0.2.html is er zelfs iemand zo gek geweest om het laatste te implementeren.
quote:En het blijft dus zo dat het best een flink aantal geheugentransacties is, en wanneer er iets op de schijven staat moet dat ook het geheugen weer in geladen worden, of het nu weinig is of veel. Als de serverconfig op de wiki nog steeds zo is draait de DB-server op een dual 3,06GHz Xeon met een FSB van 533 MHz, met 6GB 266MHz DDR. Deze Xeons zijn gebaseerd op de niet bijster efficiënte Prescott-core, en zijn sowieso bandbreedte-hongerig. En een bus van 533MHz biedt totaal niet veel bandbreedte, aangezien de processors ook zelf met elkaar moeten praten over dezelfde bus. De geheugenlatencies zijn bij deze snelheden ook niet echt geweldig. Als je deze config vergelijkt met een dual-core huis-tuin-en-keuken-bak stelt het allemaal niet erg veel meer voor.Op maandag 14 april 200816:44 schreef Skinkie het volgende:
[..]
Het gaat om of dat er data van harddisk naar geheugen moet, of dat al die data al in het geheugen staat en wordt ondersteund door een HBA. (mmap'ing)
[..]
Een index op welke plek het op disk staat is direct aan een index op welke plek het in het geheugen staat.
[..]
Het mooie van een database met indices dat het eigenlijk gewoon MMIO kan toepassen. En copy-on-write. Kopieer locatie van data[index+1] met lengte data[index].
[..]
Mensen moeten eens af van het paradigma dat het beter zou zijn om hardware bij te kopen, ten opzichte van devtijd te willen investeren. In dit geval zijn er tal van betere databases dan MySQL.
Ik ben het gezeur over database een beetje zat aan het worden. Benchmarks op FOK! die eventueel gedaan worden komen toch niet voor de schermen uit... en het gebruik van database 'als een bestandsyteem' werkt alleen echt goed als het een contante connectie heeft, 90% van het geheugen krijgt en native wordt aangesproken als of het een echt bestandssysteem is, en niet een SQL frontend voor wat data.
Wat betreft implementatie zou WinFS native zijn, SQLFS een wrapper met constante connectie, en gezien http://lobotomy.sourceforge.net/docs/Graphical_SQL-0.2.html is er zelfs iemand zo gek geweest om het laatste te implementeren.
quote:vanaf de andere kant: sinds dat het motto is, loopt de boel kut.Op maandag 14 april 200816:44 schreef Skinkie het volgende:
Mensen moeten eens af van het paradigma dat het beter zou zijn om hardware bij te kopen, ten opzichte van devtijd te willen investeren. In dit geval zijn er tal van betere databases dan MySQL.
Misschien moet er eerst eens wat geinvesteerd worden, om de hardware op pijl te trekken. Zodat die ontwikkelingen op development gebied de groei een stap vóór kunnen blijven in plaats van steeds erachteraan hobbelen.
Knaai alles van de server, en begin met een schone lei
_!!quote:Voor de huidige opzet is ie het gewoon. Daar valt weinig over te bediscussieren lijkt me zo.Op maandag 14 april 2008 13:43 schreef Skinkie het volgende:
Iedereen die hier claimt dat de hardware van die machine te zwak is verklaar ik gewoon voor gek.
quote:Als ik onze eigen cijfers voor Fok mag gebruiken: wij hebben vandaag tot nu toe - aan gewone gebruikers - 26977 verschillende topics geserveerd. Die topics hebben samen 3434256 reacties. De reacties van de eerste 2000 topics (214034 berichten) van die set hebben samen 144628672 karakters tekst, dat geinterpoleerd betekent dus dat we al op 2.2GB aan ascii tekst zitten. Dan komt er uiteraard nog een hoop metadata en indexdata bij die er ook nog bij opgeslagen zit. 't Zou me niets verbazen als de records in totaal voor zo'n 4GB aan on-disk data vertegenwoordigen.Er wordt dagelijks niet 6GB aan verschillende data uitgewisseld. En ook niet 5, niet 4, niet 3, niet 2, en waarschijnlijk komt het ook niet boven de 1GB uit. Enig idee hoe fokking veel data 1GB aan tekst is? Even analoog aan e-mail, dat zouden zo'n 500.000 verschillende berichten per dag zijn.
Dat zijn dan alleen de reacties van de topics, dan heb je nog de userdata, topictitels, diverse vormen van interne metadata, de ruwe versies van de geparste tekstdata, de diffs van edits, etc... En de crawlers die langskomen heb ik dan nog genegeerd, zij hebben natuurlijk ook nog een grote interesse in een vele unieke losse topics.
En aangezien Fok waarschijnlijk nog wat meer pageviews en verschillende topics serveert dan wij, hoewel mogelijk met gemiddeld kortere berichten, zal de score van 4+GB hier ook niet gek ingeschat zijn.
Jouw 1GB is iig in ons geval dus zelfs al puur naar de aan gewone gebruikers geserveerde platte tekst kijkend veel te krap geschat. Zo te zien kwamen we afgelopen dinsdag op iets meer dan 50k unieke topicid's als ik de crawlers meeneem, dus doorgeinterpoleerd zit je dan op 3.4GB aan platte tekstdata...
quote:De 6GB van Fok zal wel wat te krap zijn om de 4GB en overige metadata van enkel het forum al te bevatten, laat staan de data van de frontpage er nog bij.Op maandag 14 april 2008 16:44 schreef Skinkie het volgende:
Het gaat om of dat er data van harddisk naar geheugen moet, of dat al die data al in het geheugen staat en wordt ondersteund door een HBA. (mmap'ing)
quote:Wat InnoDB dan ook doet. Alleen heet het bij hun MVCC.Het mooie van een database met indices dat het eigenlijk gewoon MMIO kan toepassen. En copy-on-write. Kopieer locatie van data[index+1] met lengte data[index].
quote:Eens en oneens. Met devtijd kan je ook niet oneindig dooroptimaliseren, op een gegeven moment is een investering in een nieuw stuk hardware domweg effectiever dan nog weer een maand developmenttijd spenderen.Mensen moeten eens af van het paradigma dat het beter zou zijn om hardware bij te kopen, ten opzichte van devtijd te willen investeren. In dit geval zijn er tal van betere databases dan MySQL.
quote:Aangezien het momenteel de spin in Fok's web is, is dat een beetje een vreemde opmerkingIk ben het gezeur over database een beetje zat aan het worden.
quote:Zolang je niet exact weet welke data je wanneer nodig hebt en in welke vorm, is een sql-interface toch handiger dan een bestandssysteem lijkt me zo. Zeker met de nu bestaande frontend.Benchmarks op FOK! die eventueel gedaan worden komen toch niet voor de schermen uit... en het gebruik van database 'als een bestandsyteem' werkt alleen echt goed als het een contante connectie heeft, 90% van het geheugen krijgt en native wordt aangesproken als of het een echt bestandssysteem is, en niet een SQL frontend voor wat data.
[ Bericht 1% gewijzigd door ACM op 14-04-2008 19:54 ]
quote:Eens.Op maandag 14 april 2008 19:34 schreef ACM het volgende:
Voor de huidige opzet is ie het gewoon. Daar valt weinig over te bediscussieren lijkt me zo.
quote:Dat valt mij bijzonder tegen. Echter Ik denk dat als we een topic van 10 posts op tweakers vergelijken met Fok dat de inhoud een ration kleiner is. En daar ben ik eigenlijk ook vanuit gegaan. Posts als ":')" zijn hier niet ongebruikelijk. En post counter verschilt hier geen 500.000 per dag. Als ik even tussen zaterdag en maandag avond kijk zijn dat niet eens 45.000 posts, komt aardig overeen met tweakers.Als ik onze eigen cijfers voor Fok mag gebruiken: wij hebben vandaag tot nu toe - aan gewone gebruikers - 26977 verschillende topics geserveerd. Die topics hebben samen 3434256 reacties. De reacties van de eerste 2000 topics (214034 berichten) van die set hebben samen 144628672 karakters tekst, dat geinterpoleerd betekent dus dat we al op 2.2GB aan ascii tekst zitten. Dan komt er uiteraard nog een hoop metadata en indexdata bij die er ook nog bij opgeslagen zit. 't Zou me niets verbazen als de records in totaal voor zo'n 4GB aan on-disk data vertegenwoordigen.
quote:De data die je optimaliseert is waarschijnlijk de data die naar een gebruiker toegaat?Dat zijn dan alleen de reacties van de topics, dan heb je nog de userdata, topictitels, diverse vormen van interne metadata, de ruwe versies van de geparste tekstdata, de diffs van edits, etc... En de crawlers die langskomen heb ik dan nog genegeerd, zij hebben natuurlijk ook nog een grote interesse in een vele unieke losse topics.
quote:Ik ga er vanuit dat wat in het XSL topic is gepost hier ook op gaat. De verwatering van topics is groot. En we kunnen alleen een goede discussie voeren over wat er in het geheugen zou moeten staan gelijk is aan 'actieve' topics, bekend is. Het aantal active topics is lager dan het aantal topics wat wordt gemaakt.En aangezien Fok waarschijnlijk nog wat meer pageviews en verschillende topics serveert dan wij, hoewel mogelijk met gemiddeld kortere berichten, zal de score van 4+GB hier ook niet gek ingeschat zijn.
quote:Ik ben met die 1GB uit gegaan wat er op wikipedia stond over e-mails op GMail. En ik kan me persoonlijk ook nogsteeds geen voorstelling maken dat hier de topics groter zijn dan de gemiddelde email. Ik zal vast een enorme rekenfout maken... maar ik kan me niet voorstellen dat er op dit moment 500.000 berichten door de trechter heen gaan, noch dat die als platte tekst meer dan 1GB zouden innemen.Jouw 1GB is iig in ons geval dus zelfs al puur naar de aan gewone gebruikers geserveerde platte tekst kijkend veel te krap geschat. Zo te zien kwamen we afgelopen dinsdag op iets meer dan 50k unieke topicid's als ik de crawlers meeneem, dus doorgeinterpoleerd zit je dan op 3.4GB aan platte tekstdata...
quote:Jup. En de subsites... ik geloof best dat, dat ene beestje het moeilijk heeft. Maar denk wel dat hij fysiek in staat moet zijn om het aan te kunnen.De 6GB van Fok zal wel wat te krap zijn om de 4GB en overige metadata van enkel het forum al te bevatten, laat staan de data van de frontpage er nog bij.
quote:Ik had nog nooit van die term gehoord, maar volgens wikipedia biedt het de data aan aan verschillende processen, dus ik geloof wel dat, dat moet werken. Draait fok InnoDB? (Ik heb echt geen ideeWat InnoDB dan ook doet. Alleen heet het bij hun MVCC.
)quote:Ik heb het niet over alleen zelf gemaakte progsels.Eens en oneens. Met devtijd kan je ook niet oneindig dooroptimaliseren, op een gegeven moment is een investering in een nieuw stuk hardware domweg effectiever dan nog weer een maand developmenttijd spenderen.
quote:En daarover kan ik in ieder geval alleen raden. Heb geen gegevens van fok daaromtrent.Aangezien het momenteel de spin in Fok's web is, is dat een beetje een vreemde opmerking
[..]
Zolang je niet exact weet welke data je wanneer nodig hebt en in welke vorm, is een sql-interface toch handiger dan een bestandssysteem lijkt me zo. Zeker met de nu bestaande frontend.
quote:Weet je dat wel heel zeker?Op maandag 14 april 2008 14:59 schreef Dr.Daggla het volgende:
[..]
Onder Topix ging het anders prima hoor.
Klik
...quote:Op vrijdag 7 mei 2004 12:10 schreef MissyMirjaM het volgende:
hier doet een pagina er ongeveer 1 of 2 minuten over om te laden zodra ik op een link heb geklikt. hoogst iritant. maakt het fokken dus praktisch onmogelijk.
van de week had ik er al een topic over geopend, maar die werd door een paar josti's dichtgebaggerd, zonder dat er gemeld werd waardoor het nu kwam en of het opgelost zou kunnen worden.
zou wel fijn zijn.
quote:Ik heb in de errors die je geregeld voorgeschoven krijgt wel eens MySQL langs zien komen, maar dat weet ik niet heel zeker.Op maandag 14 april 200822:35 schreef Skinkie het volgende:
Ik had nog nooit van die term gehoord, maar volgens wikipedia biedt het de data aan aan verschillende processen, dus ik geloof wel dat, dat moet werken. Draait fok InnoDB? (Ik heb echt geen idee
Hou er ook rekening mee dat een topic hier waarschijnlijk veel vaker gerefreshed wordt dan op GoT, en dan wordt er ook weer data opgevraagd uit de database. Ik denk dat het surfgedrag hier veel meer weg heeft van "even topic bekijken, oh leuk, volgend topic bekijken" etcetera.
quote:Ik was serieus. Is InnoDB de standaard storage engine van MySQL?Op maandag 14 april 2008 22:47 schreef oshiro het volgende:
k heb in de errors die je geregeld voorgeschoven krijgt wel eens MySQL langs zien komen, maar dat weet ik niet heel zeker.
quote:Dat denk ik dus ook, vandaar mijn caching verhaal. Update ratio is volgens mij veel lager.Hou er ook rekening mee dat een topic hier waarschijnlijk veel vaker gerefreshed wordt dan op GoT, en dan wordt er ook weer data opgevraagd uit de database. Ik denk dat het surfgedrag hier veel meer weg heeft van "even topic bekijken, oh leuk, volgend topic bekijken" etcetera.
quote:Volgensmij is dat MyISAM.Op maandag 14 april 2008 23:20 schreef Skinkie het volgende:
[..]
Ik was serieus. Is InnoDB de standaard storage engine van MySQL?
quote:Dus draait fok op InnoDBOp maandag 14 april 2008 23:25 schreef The_Terminator het volgende:
Volgensmij is dat MyISAM.
of heeft de feature die ACM beschrijft niets te maken met de huidige setup?quote:Ik volg het ook even niet meerOp maandag 14 april 200823:55 schreef Skinkie het volgende:
[..]
Dus draait fok op InnoDB
Het begint weer wat minder druk te raken op het forum en de boel loopt weer wat gesmeerder
quote:Ik heb het over het aantal topics dat op een dag opgevraagd werd, niet dat op een dag veranderdeOp maandag 14 april 2008 22:35 schreef Skinkie het volgende:
Dat valt mij bijzonder tegen. Echter Ik denk dat als we een topic van 10 posts op tweakers vergelijken met Fok dat de inhoud een ration kleiner is. En daar ben ik eigenlijk ook vanuit gegaan. Posts als ":')" zijn hier niet ongebruikelijk. En post counter verschilt hier geen 500.000 per dag. Als ik even tussen zaterdag en maandag avond kijk zijn dat niet eens 45.000 posts, komt aardig overeen met tweakers.
quote:Dat hangt van je definitie van 'actief' af. Als je die wat ruim stelt en aanneemt dat alle topics die op een dag zijn opgevraagd actief zijn, dan heb je het dus in ons geval al over 45-50.000 topics (inc. crawler-gedrag). Als je enkel kijkt naar welke topics nieuwe data kregen op een dag, dan is het aantal een stuk lager inderdaad.Ik ga er vanuit dat wat in het XSL topic is gepost hier ook op gaat. De verwatering van topics is groot. En we kunnen alleen een goede discussie voeren over wat er in het geheugen zou moeten staan gelijk is aan 'actieve' topics, bekend is. Het aantal active topics is lager dan het aantal topics wat wordt gemaakt.
De vraag welke interessant is, hangt natuurlijk af van het probleem dat je probeert op te lossen. Bij de bepaling of 6GB ram genoeg is voor de platte tekst van een dagje forummen moet je de views en niet zozeer de edits weten.
quote:Tegelijk niet nee, maar over een hele dag genomen dus veel meer. En omdat je niet weet welke opgevraagd gaat worden, wil je er natuurlijk zo veel mogelijk tegelijk in je geheugen paraat hebben.Ik ben met die 1GB uit gegaan wat er op wikipedia stond over e-mails op GMail. En ik kan me persoonlijk ook nogsteeds geen voorstelling maken dat hier de topics groter zijn dan de gemiddelde email. Ik zal vast een enorme rekenfout maken... maar ik kan me niet voorstellen dat er op dit moment 500.000 berichten door de trechter heen gaan, noch dat die als platte tekst meer dan 1GB zouden innemen.
quote:Voor tabellen die relatief veel wijzigen en tegelijkertijd gelezen worden (topics, berichten, e.a.) moeten ze wel InnoDB gebruiken, MyISAM is daar door zijn full table locks niet bruikbaar voor met deze belasting.Ik had nog nooit van die term gehoord, maar volgens wikipedia biedt het de data aan aan verschillende processen, dus ik geloof wel dat, dat moet werken. Draait fok InnoDB? (Ik heb echt geen idee
quote:Vandaar dat ik naar die van onszelf kijkEn daarover kan ik in ieder geval alleen raden. Heb geen gegevens van fok daaromtrent.
quote:Precies, dat bedoel ikOp dinsdag 15 april 200808:07 schreef ACM het volgende:
[..]
Tegelijk niet nee, maar over een hele dag genomen dus veel meer. En omdat je niet weet welke opgevraagd gaat worden, wil je er natuurlijk zo veel mogelijk tegelijk in je geheugen paraat hebben.
Hoe meer database je in het geheugen hebt hoe beter Dus meer geheugen kan wel degelijk flink winst zijn, en met de geheugenprijzen van tegenwoordig is het nog goedkoop ook En àls er dan een keer van de schijven gelezen moet worden kun je de vertragingen beperken met een sterke HBA, met een snelle IO-processor en een flinke lap cache.
quote:Nou, als het zou kunnen... Maar helaas is dat nog wel een dure configuratie en zal het actieve deel van de database ook niet alle 60GB beslaan. Dus met 16 - 32GB kom je al een heel eind.Op dinsdag 15 april 2008 13:19 schreef SlimShady het volgende:
dus eigenlijk wil je de hele 60GB van de database in het geheugen hebben?
quote:Halve pagina uit het Topix tijdperk, 2.5 pagina's vol sinds deze versie.Op maandag 14 april 2008 22:44 schreef The_Terminator het volgende:
[..]
Weet je dat wel heel zeker?
Klik
Enfin, I rest my case.
.quote:het ligt ook aan jou ja, als we met zn allen fok niet meer gaan gebruiken zal fok er minder last van hebbenOp dinsdag 15 april 2008 16:04 schreef JortK het volgende:
Ligt het aan mij of loopt de boel weer langzaam aan vol?
quote:Er zijn dan ook 5x zoveel users als sinds het Topix-tijdperk. Dus er wordt ook 5x zoveel geklaagd.Op dinsdag 15 april 2008 16:17 schreef Dr.Daggla het volgende:
[..]
Halve pagina uit het Topix tijdperk, 2.5 pagina's vol sinds deze versie.
Enfin, I rest my case.
(db:query:1053:shutdown_in_progress)
Dat krijg ik tot op heden al heel lang en best vaak (vandaag 9 van de 10 keer als ik een subforum wil openen). Ik begrijp dat er hier aan een oplossing wordt gewerkt? Vordert dat?
[ Bericht 8% gewijzigd door JJasperO op 15-04-2008 16:52 ]
quote:Als je de handel met een teringgang wil laten gaan komt het daar wel op neerOp dinsdag 15 april 200813:19 schreef SlimShady het volgende:
dus eigenlijk wil je de hele 60GB van de database in het geheugen hebben?
Wat ACM zegt, 16 tot 32GB zou al een ontzettende boost zijn. En het zou best kunnen dat de server die er nu staat gewoon om kan gaan daarmee, en hij slikt nog DDR2 ook waarschijnlijk... Het zou in ieder geval een goedkope eerste stap zijn om dat hele ding vol te stampen met 4GB geheugenrepen
quote:de dronkelap aan de barOp dinsdag 15 april 2008 23:37 schreef Piles het volgende:
Wat staat er om deze tijd nog te hikken?
quote:heb vandaag al 2x een volledig lege pagina gehadOp dinsdag 15 april 2008 23:37 schreef Piles het volgende:
Wat staat er om deze tijd nog te hikken?
was al eerder een probleem, maar was toen wel gefixed.
quote:Text_only zeker
quote:Paar gehad het afgelopen kwartier ja.Op woensdag 16 april 2008 12:25 schreef JortK het volgende:
Witte pagina's anyone?
.Heb momenteel geen andere keuze
quote:Ik denk dat er iets te weinig mensen Maxthon gebruikenOp woensdag 16 april 2008 13:58 schreef pvc_boer het volgende:
Waarom zie ik in Maxthon geen header?
Heb momenteel geen andere keuze
Of heb ik hiermee gelijk mijn punt
quote:Oeh, strict programmeren, doe niet zo engOp woensdag 16 april 2008 14:20 schreef pvc_boer het volgende:
Beetje webbouwer, maakt iets zo dat het in alle browsers fatsoenlijk loopt.
Of heb ik hiermee gelijk mijn punt
quote:er zijn altijd obscure en nieuwe browsers, je kan dus nooit aan alle eisen voldoen. ik geloof dat zelfs Safari nog maar 1% van alle hits genereerd, laat staan wat die van jou doet.Op woensdag 16 april 2008 14:20 schreef pvc_boer het volgende:
Beetje webbouwer, maakt iets zo dat het in alle browsers fatsoenlijk loopt.
Of heb ik hiermee gelijk mijn punt
quote:Maxthon heeft een ingebouwde adblocker, en aangezien de header van de baggerlayout wordt ingevoegd met het adscript wordt die dan automatisch meegeblokkeerd.Op woensdag 16 april 200814:20 schreef pvc_boer het volgende:
Beetje webbouwer, maakt iets zo dat het in alle browsers fatsoenlijk loopt.
Of heb ik hiermee gelijk mijn punt
Kan dat niet anders? Jawel, heel makkelijk zelfs. Maar dan kunnen we ook weer de ads blokkeren als we dat zouden willen.
Edit: oeps, ik geef de clou weg
quote:Das ook het probleem. De 'usuals' die graag een adblocker gebruiken weten toch wel hoe ze die header accepteren. Terwijl een toevallige voorbijganger die toevallig een adblocker heeft dus een brak forum voor zijn snuffert krijgt. Wat mij betreft zou het beter zijn om in plaats van géén header een header weer te geven met grote letters "steun FOK!, schakel uw adblocker uit!" ofzo. Maargoed das een beleidskwestie die verder niet zoveel met de snelheid te maken heeft.Op woensdag 16 april 200815:53 schreef Timooon het volgende:
Precies. Ff de witte(uitzonderingen) lijst zoeken en http://213.193.208.58/ toevoegen!
Edit: oeps, ik geef de clou weg
quote:Op woensdag 16 april 2008 16:44 schreef Flounder het volgende:
Jezus, wat is Fok! weer traag. Kan er iets aan gedaan worden? Danny, koop ff een paar extra servers?
En dan al maanden roepen dat ze aan de performance werken
quote:Je kunt je ook afvragen waarom mensen die ads willen blocken. Volgens mij doet 99% het om performance redenen.Op woensdag 16 april 2008 16:42 schreef mcDavid het volgende:
[..]
Das ook het probleem. De 'usuals' die graag een adblocker gebruiken weten toch wel hoe ze die header accepteren. Terwijl een toevallige voorbijganger die toevallig een adblocker heeft dus een brak forum voor zijn snuffert krijgt. Wat mij betreft zou het beter zijn om in plaats van géén header een header weer te geven met grote letters "steun FOK!, schakel uw adblocker uit!" ofzo. Maargoed das een beleidskwestie die verder niet zoveel met de snelheid te maken heeft.
en anders klikken ze erop om fok wat centen toe te stoppen.
quote:Voor mij is dat in ieder geval een reden om de light layout te gebruiken.Op woensdag 16 april 200817:52 schreef Pheno het volgende:
[..]
Je kunt je ook afvragen waarom mensen die ads willen blocken. Volgens mij doet 99% het om performance redenen.
Dat danny het niet tof vind als je banners blockt kan ik volledig begrijpen, maar het scheelt idd echt in de performance en de lightlayout heeft maar 1 banner dus dat scheelt gewoon.
+ dat die hele layout lichter is.
continu