Mailing List Archive

2011/12/6 Matt Austin <mail@mattaustin.me.uk>
>
> I recently set up front-line cache for a uwsgi application in Cherokee
> 1.2.101 on Ubuntu 10.04.3 i686.
>
> It has done wonders for the CPU usage on the server, and it is now
> able to handle a lot more traffic. Fantastic!
>
> However, when accessed with certain tools (lynx, ab) it takes ~60
> seconds before the response is completed.
> We use the pingdom.com monitoring service, and it also reports timeouts.
>
> However accessing in my desktop browser or using wget response time is
> as expected.
>
> Any ideas - have I missed some configuration?
>
>
> Thanks,
>
> --
> Matt
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee


Could you try with ab -k (Keep-Alive)
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

On Tue, Dec 6, 2011 at 20:17, Mehmet Ali Sahin <mehmetalisahin@gmail.com> wrote:
> Could you try with ab -k (Keep-Alive)


Great, that did the trick - thanks! So my next question is, why is
this needed? Can I disable this requirement, or will that result in a
performance drop?

I'd like to be able to continue using the Pingdom monitoring service
if possible, but if not then the benefits of front-line cache win.
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

How many concurrent connections are you using with ab (which I assume is
ApacheBench)? There's a chance that the server could be running out of
available sockets if it's high enough (maybe 250 or 500 or 1000 concurrent
connections, depending on server config). Servers have a limit to how many
sockets can be opened at any one time. When a socket is closed (ie. when a
request finishes), it sits in the TIME_WAIT state for somewhere between 1 -
4 minutes (see http://developerweb.net/viewtopic.php?id=2941) before
actually being closed, and during this time it's not possible to reuse the
socket. If enough connections are opened, the server reaches its socket
limit, and will stop accepting incoming connections until some sockets are
available.

This means that things like stress testing using ApacheBench may
potentially have lasting effects for a few minutes after the benchmarking
is done (there'll be a lot of sockets sitting in TIME_WAIT). In the mean
time, if there's no sockets available, all other requests will fail. I'd
strongly suggest doing performance testing like this on a clone of the live
environment (like a staging environment) so as to not affect your live
server. This'd apply to all server apps; it's not specific to Cherokee.

Interesting that Lynx takes a long time to receive a reply. Does this occur
every time? If so, maybe sniff the traffic (with Wireshark or similar) to
see what the difference is between a request from Lynx and a request from
wget. Maybe there's some header causing the request to stall. Very odd.

On Wed, Dec 7, 2011 at 1:11 AM, Matt Austin <mail@mattaustin.me.uk> wrote:

> On Tue, Dec 6, 2011 at 20:17, Mehmet Ali Sahin <mehmetalisahin@gmail.com>
> wrote:
> > Could you try with ab -k (Keep-Alive)
>
>
> Great, that did the trick - thanks! So my next question is, why is
> this needed? Can I disable this requirement, or will that result in a
> performance drop?
>
> I'd like to be able to continue using the Pingdom monitoring service
> if possible, but if not then the benefits of front-line cache win.
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>

On Wed, Dec 7, 2011 at 19:51, Daniel Lo Nigro <lists@dan.cx> wrote:
> How many concurrent connections are you using with ab (which I assume is
> ApacheBench)?

The long response time occurs with just one request to an idle server,
so I think this is due to keep-alive rather than sockets/processes.

> Interesting that Lynx takes a long time to receive a reply. Does this occur
> every time? If so, maybe sniff the traffic (with Wireshark or similar) to
> see what the difference is between a request from Lynx and a request from
> wget. Maybe there's some header causing the request to stall. Very odd.

Yes, if I get some spare time this week I'll try sniffing the network
traffic to see whats happening.

Interestingly, Pingdom have replied to my support request and asked if
I can configure a custom monitoring test, with the option "Connection"
and "Close" in their control panel. Not sure exactly what this does,
but I'll try this out when I am back in the office tomorrow.

Matt.
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee