Forum traag

[mr_obb]

Ik heb gisteren de hele middag problemen gehad, dus als het aan de clients ligt, dan zou je mijn IP terug moeten kunnen vinden in die log. Misschien ook een idee om na te kijken of die IP-adressen niet van Google Analytics zijn, want rond de tijd dat T.net bokt, zie ik ook regelmatig dat hij daar op staat te wachten. Ik zie trouwens dat Floppus en Krusher ook melding maken van Google Analytics.

[Spider.007]

Het zou wel redelijk bizar zijn als een Google Analytics request binnen de website tot een request van Google naar die website toe zou leiden bij een hit? Dit klinkt als een mooi moment om een van de webservers uit te rusten met een cron + grep + tcpdump trigger

[gertvdijk]

Ik zou fail2ban afregelen op deze logs, aangezien het een duidelijke niet-standaard request is.

[Verwijderd]

Er was in het verleden toch ook sprake van een rare browser-addon die maffe requests deed en servers op hun knietjes probeerde te brengen (onbedoeld weliswaar)? Ben even ontschoten welke addon dat was.

[AtleX]

Fasterfox, maar die is al een hele tijd geblokkeerd in de robots.txt.

[edit]
En een paar versies van die plaatjes plugin deden dat ook.

[ Voor 33% gewijzigd door AtleX op 24-07-2008 18:37 ]

[gertvdijk]

Verwijderd schreef op donderdag 24 juli 2008 @ 18:23:
Er was in het verleden toch ook sprake van een rare browser-addon die maffe requests deed en servers op hun knietjes probeerde te brengen (onbedoeld weliswaar)? Ben even ontschoten welke addon dat was.

AVG was dat die de boel zo nodig moest versnellen. Maar dat zorgde meer voor een verdeelde belasting en niet voor spikes die we hier zien.

[Kixtart]

AtleX schreef op donderdag 24 juli 2008 @ 18:30:
Fasterfox, maar die is al een hele tijd geblokkeerd in de robots.txt.

[edit]
En een paar versies van die plaatjes plugin deden dat ook.

Misschien daarom: Robots.txt - Unexpected $end

[AtleX]

Nee, want vorige week oid heb ik de Robots.txt van T.net nog bekeken, en toen deed hij het gewoon. De problemen met de 2 UA's die ik noemde zijn al veel ouder.

[Verwijderd]

Semi-offtopic, maar het is eigenlijk te triest voor woorden dat ik nu via een GPRS verbinding dezelfde snelheid ondervind op t.net en GoT als mijn adsl-lijn, die nu down is wegens? een Speedlinq -> telfort omzetting_{geen zin op de helpdesk te bellen, ik zie het morgen wel}

[Verwijderd]

Zit hier in geen geval via wat voor KPN lijn dan ook, en heb de problemen nu weer...

[Verwijderd]

code:

Bezig met het traceren van de route naar gathering.tweakers.net [213.239.15

via maximaal 30 hops:

  1     5 ms     2 ms     1 ms  192.168.1.254
  2     *       24 ms    25 ms  82-169-7-254.ip.telfort.nl [82.169.7.254]
  3    24 ms    23 ms    23 ms  vpn494-telfort.bcsw1.asd-nh.net.tiscali.nl
241.4.178]
  4    25 ms    35 ms    35 ms  20ge-po-1.e600-2.ams7.true.nl [195.69.144.1
  5    23 ms    23 ms    23 ms  gathering.tweakers.net [213.239.154.36]

De trace is voltooid.

Ziet er normaal uit.

[Wiethoofd]

zonet weer de FP waar ik 2 pagina's tegelijk laadde, het forum was wel snel, de FP niet meer

[Erkens]

Verwijderd schreef op donderdag 24 juli 2008 @ 22:21:
Zit hier in geen geval via wat voor KPN lijn dan ook, en heb de problemen nu weer...

Ik heb hier ook problemen met een chello/upc verbinding, terwijl andere mensen die een andere connectie hebben wel snel gaat en zonder packetloss.

[Nielsvr]

Hier extreem veel last er van op dit moment. Safari 3.0.1 / OSX - UPC extreme.

[pven]

Hier helemaal geen last van traagheid, itt gisteren. Heb Speedlinq/Telfort via KPN.

[Noork]

Hier ook veel last met Chello. Kan het misschien een de DNS van Chello liggen?

[Nielsvr]

code:

imac-van-niels-van-renselaar:~ nielsvanrenselaar$ traceroute tweakers.net
traceroute to tweakers.net (213.239.154.35), 64 hops max, 40 byte packets
 1  192.168.0.1 (192.168.0.1)  1.235 ms  0.549 ms  0.496 ms
 2  0.0.0.0 (0.0.0.0)  7.213 ms  5.738 ms  7.658 ms
 3  atm11-0.ah00rt03.brain.upc.nl (212.142.23.97)  8.184 ms  7.390 ms  8.219 ms
 4  p14232085.net.upc.nl (212.142.32.85)  13.797 ms  13.750 ms  14.048 ms
 5  nl-ams05a-ra3-ae-1-0.aorta.net (213.46.183.93)  14.631 ms  13.663 ms  13.330 ms
 6  nl-ams09a-ri1-ge-5-0.aorta.net (213.46.183.81)  16.743 ms  17.333 ms  13.858 ms
 7  213.46.183.226 (213.46.183.226)  14.680 ms  14.444 ms  13.933 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
etc...

[Erkens]

Zo te zien is dit dus gewoon een UPC/Chello probleem
Weinig nut om dat dus nu steeds te herhalen lijkt me.

[moto-moi]

Als 'ie geeneens de e600 laat zien, zit inderdaad het probleem zeker niet bij ons.

[iMars]

code:

marcel-zuidwijks-macbook-pro-15:~ marcel$ traceroute tweakers.net
traceroute to tweakers.net (213.239.154.35), 64 hops max, 40 byte packets
 1  10.0.0.1 (10.0.0.1)  1.900 ms  8.095 ms  1.390 ms
 2  192.168.1.254 (192.168.1.254)  3.587 ms  2.641 ms  2.665 ms
 3  0.0.0.0 (0.0.0.0)  24.533 ms  23.329 ms  24.124 ms
 4  vpn496-telfort.bcsw1.asd-nh.net.tiscali.nl (195.241.4.186)  44.559 ms * *
 5  20ge-po-1.e600-2.ams7.true.nl (195.69.144.171)  41.333 ms  40.222 ms  41.767 ms
 6  * * *
 7  * * *
 8  *^C
marcel-zuidwijks-macbook-pro-15:~ marcel$

[Verwijderd]

pven schreef op donderdag 24 juli 2008 @ 23:04:
Hier helemaal geen last van traagheid, itt gisteren. Heb Speedlinq/Telfort via KPN.

Zal dus de migratie ellende geweest zijn.

[gertvdijk]

Twee dingen zien veel van jullie toch nog echt over het hoofd:

• Traceroutes tonen weinig aan als het mis lijkt te zijn. Zoals ik al eerder postte: het is ICMP verkeer dat veel nodes op het netwerk kunnen droppen danwel veel lager prioritiseren dan ander verkeer (daarom is het mogelijk dat de responsetijd wel eens in een volgende hop lager ligt dan die ervoor). Vooral KPN heeft een security-by-obscurity policy schijnt (droppen), dus dan is het niet gek dat je dit soort traceroutes ook hebt als het wel goed werkt. (Kan ook gelden voor andere serviceproviders hoor!)
• Het met ping of traceroute kunnen bereiken van een host (tweakers.net bijvoorbeeld) zegt niets over de werking van de service (webserver) die mogelijk niet goed werkt op dat moment.

@ admins: Als het geen DDoS is, maar een gewone DoS, dan kan iets als fail2ban toch heel snel de boel oplossen? Bijvoorbeeld 10 malle requests (zoals jullie uit de log postten) per ip toestaan en dan op firewall niveau 10 minuten het ip bannen.

[Osiris]

gertvdijk schreef op vrijdag 25 juli 2008 @ 00:55:
Twee dingen zien veel van jullie toch nog echt over het hoofd:

• Traceroutes tonen weinig aan als het mis lijkt te zijn. Zoals ik al eerder postte: het is ICMP verkeer dat veel nodes op het netwerk kunnen droppen danwel veel lager prioritiseren dan ander verkeer (daarom is het mogelijk dat de responsetijd wel eens in een volgende hop lager ligt dan die ervoor). Vooral KPN heeft een security-by-obscurity policy schijnt (droppen), dus dan is het niet gek dat je dit soort traceroutes ook hebt als het wel goed werkt. (Kan ook gelden voor andere serviceproviders hoor!)

Daar hebben we `traceroute -T -p 80 gathering.tweakers.net` voor, al is T.net denk ik niet blij met al die nutteloze SYN-TCP-pakketjes op poort 80 als het toch al wat minder goed gaat.

[ Voor 9% gewijzigd door Osiris op 25-07-2008 01:26 ]

[gertvdijk]

Osiris schreef op vrijdag 25 juli 2008 @ 01:00:
Daar hebben we `traceroute -T -p 80 gathering.tweakers.net` voor, al is T.net denk ik niet blij met al die nutteloze SYN-TCP-pakketjes op poort 80 als het toch al wat minder goed gaat.

Kan best dat je dan poort 80 checkt of er een service achter draait, maar dat wil nog niet zeggen dat de websites die hij moet serven ook in dezelfde response tijd terugkrijgt. In dit geval is het toch waarschijnlijk de grote hoeveelheid child processes die worden geforked die een ontzettende load geven en de boel traag maken en ik denk niet dat jouw traceroute dat simuleert.

Osiris schreef op vrijdag 25 juli 2008 @ 01:26:
Nee, natuurlijk niet, maar het is in ieder geval wel een 'fatsoenlijke' methode (tegen gedropte ICMP-pakketjes door tussenliggende nodes) om te kijken of de pijplijn een beetje fatsoenlijk werkt

Hmm ja, dat kende ik nog niet. Ik neem aan dat dat een Windows commando is? Wat doet die -T optie eigenlijk? Ik heb die niet op mijn Linux systeempje. Het beestje heeft vast een andere naam in Linux dan bij jou.

[ Voor 28% gewijzigd door gertvdijk op 25-07-2008 01:31 ]

[Osiris]

gertvdijk schreef op vrijdag 25 juli 2008 @ 01:13:
[...]

Kan best dat je dan poort 80 checkt of er een service achter draait, maar dat wil nog niet zeggen dat de websites die hij moet serven ook in dezelfde response tijd terugkrijgt. In dit geval is het toch waarschijnlijk de grote hoeveelheid child processes die worden geforked die een ontzettende load geven en de boel traag maken en ik denk niet dat jouw traceroute dat simuleert.

Nee, natuurlijk niet, maar het is in ieder geval wel een 'fatsoenlijke' methode (tegen gedropte ICMP-pakketjes door tussenliggende nodes) om te kijken of de pijplijn een beetje fatsoenlijk werkt

Kzal ff je puntje 2 uit mn quote verwijderen

[ Voor 3% gewijzigd door Osiris op 25-07-2008 01:26 ]

[Raven]

Erkens schreef op donderdag 24 juli 2008 @ 23:10:
Zo te zien is dit dus gewoon een UPC/Chello probleem
Weinig nut om dat dus nu steeds te herhalen lijkt me.

Nope, hier ook last van, atm wel heel wat minder trouwens...

@homeZiggo

[ACM]

gertvdijk schreef op vrijdag 25 juli 2008 @ 00:55:
@ admins: Als het geen DDoS is, maar een gewone DoS, dan kan iets als fail2ban toch heel snel de boel oplossen? Bijvoorbeeld 10 malle requests (zoals jullie uit de log postten) per ip toestaan en dan op firewall niveau 10 minuten het ip bannen.

't Waren een stuk of 80 verschillende geloof ik, dus strict genomen wel een DDoS als het een DoS was. Maar we gaan zeker naar iets als fail2ban kijken, tot nu toe was het (gelukkig) nooit nodig.

[Wiethoofd]

zonet weer iets nieuws. Forum wel snel, de afbeeldingen om het vak waarin je een uitgebreide reply typt daarentegen kwamen 5 minuten na het bijna af hebben van m'n post nog eens aanzetten.

voetnoot: bij deze post doet hij het wel goed

[Wiethoofd]

Even een kick, ik vanaf 11:55 uur al problemen met GoT, ik moet 6x refreshen, 1x firefox herstarten, computer herstarten voordat GoT weer iets van leven geeft. Er staat niets aan te downloaden, maar toch problemen als ik een post wil quoten, editen of toevoegen.

[MsG]

Ik merk hier ook een vertraging. Al download ik wel met 50kb/s maar ja die andere 275kb/s moet genoeg zijn om tweakers te bezoeken lijkt me .

[RnB]

Hier nergens last van.

[CrankyGamerOG]

RnB schreef op zondag 24 augustus 2008 @ 12:17:
Hier nergens last van.

Ik had er eerder altijd last van , maar sinds een paar dagen is alles ok eigenlijk

[Roelant]

Wiethoofd schreef op zondag 24 augustus 2008 @ 12:04:
Even een kick, ik vanaf 11:55 uur al problemen met GoT, ik moet 6x refreshen, 1x firefox herstarten, computer herstarten voordat GoT weer iets van leven geeft. Er staat niets aan te downloaden, maar toch problemen als ik een post wil quoten, editen of toevoegen.

Als je je computer moet herstarten om het probleem (enigszins) te verhelpen, denk ik dat dat al aangeeft dat het probleem lokaal geeft. Ik zie in de stats in ieder geval nog geen rare dingen en heb zelf de hele morgen nog geen problemen gehad.

[Wiethoofd]

Roelant schreef op zondag 24 augustus 2008 @ 14:02:
Als je je computer moet herstarten om het probleem (enigszins) te verhelpen, denk ik dat dat al aangeeft dat het probleem lokaal geeft.

Ik heb m'n computer herstart om dat dus juist uit te sluiten, zelfs na de reboot deed hij nog steeds traag, inmiddels doet hij het weer 'normaal'.

[Harm]

Ik had om diezelfde tijd last dat 'het internet' raar deed: pagina's openden niet, pagina's leken te openen maar deden dat dan toch niet, klikjes deden niets, et cetera. Dat was zowel op T.net/GoT als op andere websites. Ik gok dus op een ander soort probleem.

[BtM909]

Toch maar besloten om dit topic te kicken ipv een nieuw topic.

Het forum is continue traag door de requests naar http://tweakimg.net. Ik heb het zelf op meerdere locaties (inclusief het buitenland) en ben nieuwsgierig hoe ik het aan mijn zijde kan troubleshooten zodat ik meer en bruikbare info kan leveren

Het gaat er dus om dat het forum wel snel laadt, maar het daadwerkelijk parsen door m'n browser pas wordt gedaan nadat de requests naar tweakimg.net zijn afgerond.

Client: XP & Vista
Browsers: IE6, IE7 en FF

edit:

Nog even wat zinnigs toevoegen:
Het grote grappige plaatjes topic deel 33⅓ geeft mij de eerste keer een mooie grijze achtergrond. Na de reactie van tweakimg.net wordt alles netjes weergegeven. Daarna doet een F5 precies hetzelfde, alleen lijkeen alle plaatjes netjes uit de cache gehaald (de rest van de content is ook gewoon zichtbaar), maar blijft de tracker links weg, zoals hieronder:

[ Voor 32% gewijzigd door BtM909 op 15-04-2009 16:17 ]

[ACM]

BtM909 schreef op woensdag 15 april 2009 @ 16:12:
Ik heb het zelf op meerdere locaties (inclusief het buitenland) en ben nieuwsgierig hoe ik het aan mijn zijde kan troubleshooten zodat ik meer en bruikbare info kan leveren

Zijn er ook overeenkomsten tussen die locaties? Gaan ze allemaal via dezelfde of een vergelijkbare proxy-dienst bijvoorbeeld?

Het gaat er dus om dat het forum wel snel laadt, maar het daadwerkelijk parsen door m'n browser pas wordt gedaan nadat de requests naar tweakimg.net zijn afgerond.

Hoe weet je dat "het forum wel snel laadt"? Waar leidt je dat uit af?

Nog even wat zinnigs toevoegen:
Het grote grappige plaatjes topic deel 33⅓ geeft mij de eerste keer een mooie grijze achtergrond. Na de reactie van tweakimg.net wordt alles netjes weergegeven. Daarna doet een F5 precies hetzelfde, alleen lijkeen alle plaatjes netjes uit de cache gehaald (de rest van de content is ook gewoon zichtbaar), maar blijft de tracker links weg, zoals hieronder:
[afbeelding]

Zie je dan ook javascript-errors?

[BtM909]

ACM schreef op woensdag 15 april 2009 @ 16:49:
[...]

Zijn er ook overeenkomsten tussen die locaties? Gaan ze allemaal via dezelfde of een vergelijkbare proxy-dienst bijvoorbeeld?

Nope. Vast internet (zonder restricties) op kantoor. UPC kabel 120MBit/s thuis en in 't buitenland vast via een proxy (maar ook weleens zonder).

[...]

Hoe weet je dat "het forum wel snel laadt"? Waar leidt je dat uit af?

Zodra het Waiting for tweakimg.net verdwijnt is de pagina direct en volledig zichtbaar. Uiteraard kunnen sommige externe plaatjes nog aan 't laden zijn, maar gathering.tweakers.net content is zichtbaar.

[...]

Zie je dan ook javascript-errors?

Nee, want zodra het Waiting for tweakimg.net verdwijnt verschijnt de tracker. Ik had die printscreen om te illustreren dat ik tijd zat heb om een printscreen te kunnen maken

[ Voor 6% gewijzigd door BtM909 op 15-04-2009 17:14 ]

[Alfredo]

Ik had gisteren hetzelfde. tweakimg.net was niet vooruit te branden en hield het laden van de pagina's tegen (waiting for response of zoiets).

[crisp]

Volgens mij is dit, afgezien van de recente perikelen met de fileserver, geen issue meer