> 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 nearly
>> >> 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
>> > tu
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
Queuing"
>> >> 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
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 to
>> > > 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&T about this problem then. It should really
>> > > not block related icmp traffic.
>> >
>> >
>> > Hi Kai, yesterday I switche
>> >> I just remembered that our AT&T 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&T device to the
>> >> Gentoo router but I haven't done that yet as I want to be on-site
>> >> for it
>> >> 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
>> > correspon
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 connections
>>> 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 packe
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 slowdown is
>"TCP
>> Queui
> 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
>>secon
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
Queuing". It loo
14 matches
Mail list logo
