Userbase

Users United
https://test-goztow.userbase.be/forum/

UB was (even) kapot?

https://test-goztow.userbase.be/forum/viewtopic.php?t=43787

Pagina 1 van 1

UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:22
door on4bam
Daarstraks een timeout op UB, later een SQL error (too many connections).
Gelukkig is alles terug in orde :-D

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:26
door theduvelking
Waarschijnlijk iemand die op den draad stond zeker ... :roll:

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:30
door on4bam
theduvelking schreef:Waarschijnlijk iemand die op den draad stond zeker ... :roll:
Mogelijk.. en ze staan nog te trappelen. Nu en dan een langere tijd wachten eer een pagina opent. UB vliegt hier normaal.

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:30
door ubremoved_15739
Of een nieuwe gebruiker die creatief was met zijn nickname?

Afbeelding

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:32
door Joe de Mannen
Ik heb dat de laatste week wel meer voor, timeouts.
J.

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:35
door on4bam
Joe de Mannen schreef:Ik heb dat de laatste week wel meer voor, timeouts.
Hier nooit. UB zit natuurlijk op EDPnet servers en dat is dan ook de reden dat een trace hier max 30ms bedraagt.

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:36
door Sub Zero
Yup, we zijn er ons van bewust. Alleen heb ik de oorzaak nog niet gevonden. Plots maakt apache 32509509 child processen aan om de load te kunnen verwerken (en je dus ook too many MySQL connections krijgt). 'k Heb alleen nog niet gevonden waar de requests vandaan komen om dit te veroorzaken.

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:37
door Sub Zero
on4bam schreef:Hier nooit. UB zit natuurlijk op EDPnet servers en dat is dan ook de reden dat een trace hier max 30ms bedraagt.
30ms is veel hoor ;)

Code: Selecteer alles

12 packets transmitted, 12 received, 0% packet loss, time 11016ms
rtt min/avg/max/mdev = 6.516/11.975/64.918/15.971 ms
En dit is omdat er eentje van 64ms tussen zit. De rest zit allemaal onder de 8ms.

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:40
door on4bam
Ik zeg toch MAX :angel:

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:42
door selder
Dzju, bij mij net boven de 8ms...

Code: Selecteer alles

--- userbase.be ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12012ms
rtt min/avg/max/mdev = 8.340/8.686/8.860/0.118 ms
selder@derelict:~$

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:44
door ubremoved_15739
Vanaf een Proximus lijntje:

Code: Selecteer alles

20 packets transmitted, 20 received, 0% packet loss, time 19027ms
rtt min/avg/max/mdev = 32.605/38.949/65.646/9.667 ms
Vanaf een Telenet lijntje:

Code: Selecteer alles

20 packets transmitted, 20 received, 0% packet loss, time 19029ms
rtt min/avg/max/mdev = 10.185/11.366/13.918/0.947 ms

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 10:52
door FunkStar
Ik dacht toch dat het ICMP-protocol niet iets is waar je de snelheid kan uit afleiden omdat het geen high priority protocol is?

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 11:05
door ubremoved_15739
't Is gewoon "een feature" van een VDSL lijntje. :lol:
Ook VoIP bijvoorbeeld geeft vergelijkbare resultaten...
De MOS score is nochtans hoger via Proximus.

Een YouTube filmpje gaat meestal veel vlotter op het Proximus lijntje dan op het Telenet lijntje (zeker in de drukke uren).

Ik heb ook eens maandenlang query's liggen uitvoeren (24/24, 7/7) op eenzelfde host via zowel een Proximus lijntje als een Telenet lijntje.
Via het Proximus lijntje had ik uiteindelijk meer query's kunnen uitvoeren.
Dus, 't ja, het ligt er maar aan hoe je het bekijkt.

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 11:30
door thomasv
Wie heeft er hier LoadImpact losgelaten op UB? :nono:

Re: UB was (even) kapot?

Geplaatst: 21 jan 2015, 13:42
door MClaeys
eternum schreef:Een YouTube filmpje gaat meestal veel vlotter op het Proximus lijntje dan op het Telenet lijntje (zeker in de drukke uren).
Proximus heeft caching servers, dus dat kan daar wel aan liggen.

Re: UB was (even) kapot?

Geplaatst: 26 jan 2015, 14:18
door Sub Zero
En bij deze hebben we ze gevonden: http://www.ubermetrics-technologies.com/ :nono:
Hun crawler staat iets te straf afgesteld en lanceerde dik 160 HTTP HEAD requests op 1-2 seconden, waardoor de server zich even verslikte. Meon heeft lief aan die mensen gevraagd om hun crawler wat rustiger af te stellen, maar tot er een antwoord komt worden al hun requests dropped op de firewall. To be continued!

Re: UB was (even) kapot?

Geplaatst: 26 jan 2015, 19:45
door thomasv
Luistert die bot niet naar robots.txt?

User-agent: ubermetrics
Disallow: /

Wel geen idee hoe hun user-agent eruit ziet.

En anders in plaats van hun helemaal te blokkeren kan je hun limiteren (bijvoorbeeld 5 seconden per request)

User-agent: ubermetrics
Crawl-delay: 5

Re: UB was (even) kapot?

Geplaatst: 26 jan 2015, 22:00
door meon
Ik heb al contact gehad met hun CTO, ze gingen onze logfiles analyseren, want dit gedrag was niet de bedoeling.
@thomasv : goeie tip; niet bij stilgestaan. Misschien ook rate limiting op IP overwegen?

Re: UB was (even) kapot?

Geplaatst: 28 jan 2015, 19:41
door thomasv
Uit mijn ervaring luisteren zowat alle spiders wel naar robots.txt, dus dat lijkt me misschien overbodig.

Je vindt zeker en vast een lijstje met crawlers en dan kan je eventueel meerdere crawlers een crawl-delay toekennen, just to be safe :)
(voeg gewoon een regel toe per User-agent)

Code: Selecteer alles

User-agent: ubermetrics
User-agent: googlebot
Crawl-delay: 5
of, misschien beter, alle crawlers limiteren:

Code: Selecteer alles

User-agent: *
Crawl-delay: 5

Re: UB was (even) kapot?

Geplaatst: 30 jan 2015, 21:19
door Sub Zero
Dat is wel waar, maar het is niet de bedoeling dat een bot een webserver plat trekt - afhankelijk van settings en de inhoud van robots.txt.
Alle tijden zijn UTC+02:00
Pagina 1 van 1

Powered by phpBB® Forum Software © phpBB Limited

Nederlandse vertaling door phpBB.nl.