Would it change anything I we reduced the epoll_wait timeouts from 1000 (but effectively from 10ms) to 1ms?
E.g: via this patch:
--- src/comm_epoll.cc.orig 2010-09-15 20:06:11.000000000 +0000
+++ src/comm_epoll.cc 2010-09-15 20:07:32.000000000 +0000
@@ -66,7 +66,7 @@
#include <sys/epoll.h>
static int kdpfd;
-static int max_poll_time = 1000;
+static int max_poll_time = 1;
static struct epoll_event *pevents;
@@ -333,7 +333,7 @@
void
comm_quick_poll_required(void)
{
- max_poll_time = 10;
+ max_poll_time = 1;
}
#endif /* USE_EPOLL */
Thanks,
Martin
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
> Sent: Donnerstag, 16. September 2010 01:02
> To: squid-users@xxxxxxxxxxxxxxx
> Subject: RE: Strange performance effects on squid during off
> peak hours
>
> On Wed, 15 Sep 2010 20:53:04 +0100, Martin Sperl <Martin.Sperl@xxxxxxxxxx>
> wrote:
> > Hi Amos!
> >
> > Thanks for your feedback.
> >
> >> Squid is still largely IO event driven. If the network IO is less than
> >> say 3-4 req/sec Squid can have a queue of things waiting to happen
> which
> >> get delayed a long time (hundreds of ms) waiting to be kicked off.
> >> Your overview seems to show that behaviour clearly.
> >>
> >> There have been some small improvements and fixes to several of the
> >> lagging things but I think its still there in even the latest Squid.
> >
> > Here the Hit/s statistics on this specific server for the time:
> > +------+-------+-------+
> > | h | allHPS| cssART|
> > +------+-------+-------+
> > | 0 | 48.34 | 0.016 |
> > | 1 | 49.80 | 0.015 |
> > | 2 | 49.01 | 0.015 |
> > | 3 | 47.08 | 0.018 |
> > | 4 | 17.34 | 0.024 |
> > | 5 | 4.00 | 0.042 |
> > | 6 | 0.52 | 0.054 |
> > | 7 | 9.02 | 0.034 |
> > | 8 | 7.18 | 0.038 |
> > | 9 | 8.25 | 0.035 |
> > | 10 | 9.45 | 0.034 |
> > | 11 | 14.71 | 0.030 |
> > | 12 | 23.94 | 0.023 |
> > | 13 | 31.04 | 0.021 |
> > | 14 | 35.02 | 0.020 |
> > | 15 | 38.87 | 0.019 |
> > | 16 | 40.92 | 0.019 |
> > | 17 | 43.39 | 0.017 |
> > | 18 | 45.62 | 0.016 |
> > | 19 | 47.58 | 0.017 |
> > | 20 | 51.91 | 0.014 |
> > | 21 | 53.65 | 0.014 |
> > | 22 | 40.87 | 0.016 |
> > | 23 | 47.40 | 0.016 |
> > +------+-------+-------+
> >
> > So to summarize it: we need to keep the number of hits above 30 hits/s
> for
> > squid, so that we get an acceptable Response time.
> >
> > I believe it will need some convincing of management to get this
> > assumption tested in production ;)
> >
> > One other Question: is squid 3.1 "better" in this respect than 3.0?
>
> Than 3.0? I believe so. Though have no data on it.
> The upper req/sec cap where the most effort has gone is 15%-20% higher, I
> have not done any serious testing like this with the lower limits before.
>
> If you are able to it would be very enlightening and helpful for many I
> think.
>
> Amos
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
