> It turned out this was a combination of two problems which made it
> much more difficult to figure out.
>
> First of all I didn't have enough apache2 processes. That seems like
> it should have been obvious but it wasn't for two reasons. Firstly,
> my apache2 processes are always idle or
>> >> I haven't mentioned it yet, but several times I've seen the website
>> >> perform fine all day until I browse to it myself and then all of a
>> >> sudden it's super slow for me and my third-party monitor. WTF???
>> >
>> > I had a similar problems once when routing through a IPsec VPN
>> >
Am 20.09.2016 um 21:52 schrieb Grant:
My web server's response time for http requests skyrockets every
weekday between about 9am and 5pm. I've gone over my munin
>>> graphs
> and
the only one that really correlates well with the slowdown is
>>> "TCP
Am Wed, 21 Sep 2016 13:47:28 -0700
schrieb Grant :
> >> I haven't mentioned it yet, but several times I've seen the website
> >> perform fine all day until I browse to it myself and then all of a
> >> sudden it's super slow for me and my third-party monitor. WTF???
> >
>
>> >> I haven't mentioned it yet, but several times I've seen the website
>> >> perform fine all day until I browse to it myself and then all of a
>> >> sudden it's super slow for me and my third-party monitor. WTF???
>> >
>> > I had a similar problems once when routing through a IPsec VPN
On Wednesday, September 21, 2016 01:47:28 PM Grant wrote:
> >> I haven't mentioned it yet, but several times I've seen the website
> >> perform fine all day until I browse to it myself and then all of a
> >> sudden it's super slow for me and my third-party monitor. WTF???
> >
> > I had a similar
>> I haven't mentioned it yet, but several times I've seen the website
>> perform fine all day until I browse to it myself and then all of a
>> sudden it's super slow for me and my third-party monitor. WTF???
>
> I had a similar problems once when routing through a IPsec VPN tunnnel.
> I needed
Am Wed, 21 Sep 2016 22:06:37 +0200
schrieb Kai Krakow :
> Am Wed, 21 Sep 2016 12:37:51 -0700
> schrieb Grant :
>
> > [...]
> > [...]
> [...]
> > >
> > > You may want to set the default congestion control to fq-codel
> > > (it's in the
Am Wed, 21 Sep 2016 12:53:17 -0700
schrieb Grant :
> [...]
> [...]
> >>
> >> You may want to set the default congestion control to fq-codel
> >> (it's in the kernel) if you're using DSL links. This may help your
> >> problem a little bit. It is most effective if you
Am Wed, 21 Sep 2016 12:37:51 -0700
schrieb Grant :
> [...]
> [...]
> >>
> >>
> >> Hi Kai, yesterday I switched my Gentoo router over to handling
> >> PPPoE and pings seem to be working properly now. The AT device
> >> is now functioning as a modem only and passing
>> > > If that device behaves badly in router mode by blocking just all
>> > > icmp traffic instead of only icmp-echo-req, this is a good idea.
>> > > You may want to bug AT about this problem then. It should really
>> > > not block related icmp traffic.
>> >
>> >
>> > Hi Kai, yesterday I switched
Am Wed, 21 Sep 2016 21:29:13 +0200
schrieb Kai Krakow :
> Am Wed, 21 Sep 2016 07:30:40 -0700
> schrieb Grant :
>
> > [...]
> > [...]
> [...]
> > >
> > > If that device behaves badly in router mode by blocking just all
> > > icmp traffic
>> >> I just remembered that our AT modem/router does not respond to
>> >> pings. My solution is to move PPPoE off of that device and onto my
>> >> Gentoo router so that pings pass through the AT device to the
>> >> Gentoo router but I haven't done that yet as I want to be on-site
>> >> for it.
Am Wed, 21 Sep 2016 07:30:40 -0700
schrieb Grant :
> [...]
> [...]
> >>
> >>
> >> I just remembered that our AT modem/router does not respond to
> >> pings. My solution is to move PPPoE off of that device and onto my
> >> Gentoo router so that pings pass through the
>> >> It looks like the TCP Queuing spike itself was due to imapproxy
>> >> which I've now disabled. I'll post more info as I gather it.
>> >
>> >
>> > imapproxy was clearly affecting the TCP Queuing graph in munin but I
>> > still ended up with a massive TCP Queuing spike today and
>> >
Am Tue, 20 Sep 2016 06:08:31 -0700
schrieb Grant :
> [...]
> [...]
> >>
> >>
> >> It looks like the TCP Queuing spike itself was due to imapproxy
> >> which I've now disabled. I'll post more info as I gather it.
> >
> >
> > imapproxy was clearly affecting the TCP
On Tue Sep 20 12:52:57 2016, Grant wrote:
> The spikes are taking place on my remote server but they seem to
> roughly coincide with user activity within my own network. My
> technical knowledge of networking internals is weak. Does anyone know
> which tool will tell me more about the
>>> My web server's response time for http requests skyrockets every
>>> weekday between about 9am and 5pm. I've gone over my munin
>>graphs
and
>>> the only one that really correlates well with the slowdown is
>>"TCP
>>> Queuing". It looks like I normally have about 400
On September 20, 2016 4:53:41 PM GMT+02:00, Grant wrote:
>> My web server's response time for http requests skyrockets every
>> weekday between about 9am and 5pm. I've gone over my munin
>graphs
>>>and
>> the only one that really correlates well with the
> My web server's response time for http requests skyrockets every
> weekday between about 9am and 5pm. I've gone over my munin graphs
>>and
> the only one that really correlates well with the slowdown is "TCP
> Queuing". It looks like I normally have about 400 packets per
On September 20, 2016 2:38:03 AM GMT+02:00, Grant wrote:
My web server's response time for http requests skyrockets every
weekday between about 9am and 5pm. I've gone over my munin graphs
>and
the only one that really correlates well with the slowdown is "TCP
My web server's response time for http requests skyrockets every
weekday between about 9am and 5pm. I've gone over my munin graphs and
the only one that really correlates well with the slowdown is "TCP
Queuing". It looks like I normally have about 400 packets per second
>>> My web server's response time for http requests skyrockets every
>>> weekday between about 9am and 5pm. I've gone over my munin graphs and
>>> the only one that really correlates well with the slowdown is "TCP
>>> Queuing". It looks like I normally have about 400 packets per second
>>>
>> My web server's response time for http requests skyrockets every
>> weekday between about 9am and 5pm. I've gone over my munin graphs and
>> the only one that really correlates well with the slowdown is "TCP
>> Queuing". It looks like I normally have about 400 packets per second
>> graphed as
> My web server's response time for http requests skyrockets every
> weekday between about 9am and 5pm. I've gone over my munin graphs and
> the only one that really correlates well with the slowdown is "TCP
> Queuing". It looks like I normally have about 400 packets per second
> graphed as
25 matches
Mail list logo