Reacties (45)
De tijd die mozilla nodig heeft om de pagina te laden is hier nog steeds tussen de 5 en 7 seconden (xs4all basic). Hopelijk gaat de betrouwbaarheid er meer op vooruit dan de snelheid.
Volgens mij is het hier in Oldenzaal met een @home verbinding wel sneller geworden. Althans de laadtijden van de frontpage zijn iets minder.... kan ook zijn dat er verbetering in de webservers is? (ze doen het allemaal weer?).
Qua rauwe doorvoer is hij niet veel sneller geworden, maar de ping is weer een stuk omlaag, nu gemiddeld 25ms met Chello. Wat met wel opvalt is dat ik tot gisteravond NIET via de gewone url's op T.net, GoT en Fok! kon komen. Die DNS problemen zijn nu opgelost, en sindsdien is het een perfecte verbinding
.
Ik merk qua snelheid geen verschil, maar ik merk wel dat T.net de laatste tijd slecht bereikbaar was. Ik neem aan dat dit vooral kwam door oude DNS-versies. Dat gaat dus wel over. Verder toch hartstikke fijn voor jullie!
Over het algemeen gezien iets sneller! Ik ben er dan ook iets van 4 hops op vooruit gegaan.
Kabelsloom premium @ IJsselstein, Utr!
Nu de DNS weer werkt is het helemaal geweldig, maar gelukkig dat ik m'n eigen caching dns had
Anders had ik tweakers.net nog veel langer moeten missen
Kabelsloom premium @ IJsselstein, Utr!
Nu de DNS weer werkt is het helemaal geweldig, maar gelukkig dat ik m'n eigen caching dns had
duh..dat maakt geen zak uit...als t.net een ander IP adres krijgt dan heb jij nog steeds dat ouwe adres in je cache staan...Nu de DNS weer werkt is het helemaal geweldig, maar gelukkig dat ik m'n eigen caching dns had Anders had ik tweakers.net nog veel langer moeten missen
In ieder geval is het hier niet echt sneller geworden, vuurwerk was ook ok. Ik hoop alleen idd dat de stabiliteit beter wordt...
Beetje een poll die zichzelf overbodig maakt doordat ie vraagt om nietszeggende antwoord. Ik heb een dikke Chello-pijp en naar ik hier regelmatig mag vernemen heb ik geluk dat ik binnen Nederland consequent en zonder uitzondering de maximale 192K/s uit het ding trek. Dus eerst was het flits en de frontpage stond er, en nu is het flits en de frontpage staat er. Daarentegen zal iemand die bij een ISP zit waar toevallig net enkele servers worden vervangen hier antwoorden dat het stukken langzamer is.
Door dit soort vervuiling (ja ik heb ook gestemd) wordt de poll volkomen nutteloos.
Door dit soort vervuiling (ja ik heb ook gestemd) wordt de poll volkomen nutteloos.
De de reacties hier en op GoT blijkt dat er wel degelijk mensen zijn bij wie het sneller gaat (bij mij ook). Het moet toch echt wel heel toevallig zijn dat de netwerkverbinding van al deze mensen toevallig is geupgrade tegelijkertijd met de verhuizing van de servers.
Naarmate je eigen verbinding sneller is, gaat t.net nu ineens veel sneller. Gisteren (ISDN in NL) was er niet zo veel verschil merkbaar. Nu (TDSL-XXL in Duitsland) is het gewoon schrikken zo snel als het nu gaat. Met name de response op links is een stuk sneller.
De betere performance is volgens mij de combinatie van de recente upgrades en de nieuwe provider. Beide acties waren dus de moeite waard
De betere performance is volgens mij de combinatie van de recente upgrades en de nieuwe provider. Beide acties waren dus de moeite waard

Ik zei niet dat het al of niet sneller gaat, ik legde enkel uit waarom de uitslag van deze poll nutteloos is: er is namelijk teveel vervuiling van de mensen met dikke pijpen of andere externe omstandigheden.
Volgens mij is er weinig misgeweest met de snelheid... stabiliteit is een heel ander verhaal. Waarom wordt er niet in het forum-overload-probleem geinvesteerd? Ja, een discussie die al 100x is gevoerd en toch vraag ik het weer
Dit jaar hebben wij o.a. geupgrade:
- 1 webserver van Athlon 800 naar Tbird 1000
- 2x extra webservers Tbird 1000 en Tbird 1200
- Dbase server Dual PIII-733 naar Dual PIII-1000
- Nieuwe RAID controller voor dbase server
- Tweede dbase server Dual PIII-1000, 2GB RAM dankzij Hardware.nl
- Geheugen upgrade 1e dbase server 1,5 naar 2GB RAM
- 1 APC Masterswitch
- 2x Micronet 16-poorts manageable switches
- 2 800MHz LVS load balancers
Forum-overload hebben we al twee maanden geen last meer van.
- 1 webserver van Athlon 800 naar Tbird 1000
- 2x extra webservers Tbird 1000 en Tbird 1200
- Dbase server Dual PIII-733 naar Dual PIII-1000
- Nieuwe RAID controller voor dbase server
- Tweede dbase server Dual PIII-1000, 2GB RAM dankzij Hardware.nl
- Geheugen upgrade 1e dbase server 1,5 naar 2GB RAM
- 1 APC Masterswitch
- 2x Micronet 16-poorts manageable switches
- 2 800MHz LVS load balancers
Forum-overload hebben we al twee maanden geen last meer van.
offtopic:
Waarom krijg ik dan 's nachts om een uur of half 2 als ik aan het dubben ben om nog op reply's te wachten code 55's? Is er dan onderhoud ofzo?
Waarom krijg ik dan 's nachts om een uur of half 2 als ik aan het dubben ben om nog op reply's te wachten code 55's? Is er dan onderhoud ofzo?
Ja, was onderhoud ivm het aanslingeren van MySQL replication. Ik heb 't nog kort vooraf aangekondigd in mededelingenforum. In dat soort gevalletjes is het ook handig om hier de MySQL status te checken: http://www.tweakers.net/zooi.dsp?Action=Stats .
De snelheid zal wel wat omhoog zijn, maar het belangrijkste: we worden noooooit meer geslashdot
Yeah, right. Dacht je echt dat het 'geslashdot' worden inhield dat de verbinding van vuurwerk vol zat? De servers trekken het echt al LANG niet meer, voordat die lijn echt merkbaar vol wordt.
En dat probleem blijft bij TS bestaan. Hoewel het met Loadbalancing en meer servers uiteraard wel minder wordt
En dat probleem blijft bij TS bestaan. Hoewel het met Loadbalancing en meer servers uiteraard wel minder wordt
Of issut misschien sneller omdat ik ondertussen geswitched ben van kcma naar fast xs4all
.
Heb iig geleerd om tijdens opbouw van m'n linuxbak tweakers *niet* te gebruiken om te kijken of masquerading/forwarding nu eindelijk werkt
.
Heb iig geleerd om tijdens opbouw van m'n linuxbak tweakers *niet* te gebruiken om te kijken of masquerading/forwarding nu eindelijk werkt
44 seconden duurt het hier (kabelfoon->westland).
Op dit item kan niet meer gereageerd worden.