Re: [squid-users] Too many queued redirector requests

From: Deepa D <deepndharma@dont-contact.us>
Date: Mon, 31 May 2004 12:51:59 +0100 (BST)

Hi,
   Thanks for the response.
   Cache takes a considreable amt of memory which our
system cannot afford, hence the choice of disbling the
cache.
   The redirector that I am using is a self made one
for content filtering. It communicates with a remote
server to obtain the details of the content of the
url. This communication alone could take a max of
2000msecs.
I cannot avoid this though. What is the average time
for a redirector?
   What is the maximum queue length for the
redirectors ? Is this a configurable parameter? I have
seen FATAL errors being thrown for 22 on 10
redirectors. Isn't this a very small number?
   Plz tell me if I can change this parameter some
place and correct the problem.
   Regards and TIA,
      Deepa

--- Hendrik_Voigtländer <hendrik@voigtlaenders.net>
wrote: > Hi,
>
> > I have been following this thread of mails and
> I
> > have a problem with the number of redirectors too.
> > I am using squid-2.5.STABLE5 configured to
> work
> > with caching disabled.
> Just curious: Any reason to disable caching?
>
> > I am using a redirector that
> > does some url filtering using a local database.
>
> What is the purpose? Filtering offending content?
> Selfmade redirector? What kind of database?
>
> > I have
> > timed the redirector - it takes anywhere between
> 42
> > msecs to 2000 msecs at times to process. I am
> running
> > squid on a system with the configuration -
> > Linux-2.4.18-14, P4, 512 MB RAM. We have other
> > applications like a web server, etc that are also
> > running on this system.
>
> 2000msecs? Thats a lot...
>
> > You had mentioned in ur earlier mail that ur
> > system is so configured that 80% of the requests
> are
> > handled by the first redirector, 10% by the second
> and
> > so on. Could you kindly elaborate as to how
> this
> > done - or is it the way squid works? If this is
> the
> > case, then adding more redirectors shd not solve
> my
> > problem.
>
> The number of requests handled by each redirector as
> described in the
> posts is more a phenomenon, not a configuration
> issue.
> - Squidguard is very fast and IMHO the request are
> not distributed round
> robin, but to the first idle redirector
> - light load - the first redirector is always ready
> to serve the
> request, all the others have never a chance to
> answer.
> - increased load - sometime the first redirector is
> busy, some requests
> are answered by the 2nd redirector
> - even higher load - sometime both 1st and 2nd
> redirectors are busy,
> the 3th gets a chance to do some work - and so on
> with the others if
> load increases.
> - load peak - all redirectors get something to do,
> some request are
> queued and the warning message occurs, but never a
> FATAL error as the
> queue lenght never gets high (long?) enough.
>
> I think your problem is different as your
> redirectors are quite slow,
> the queues are growing to long which causes the
> fatal error.
> Increasing the number of redirectors should help a
> bit in your case, but
> probably the database is to slow to handle all the
> requests. If the
> database is the problem, increasing the no of
> redirector means
> increasing the processing time as well - this means
> the number of
> request which can be processed in a given amount of
> time will not
> increase much.
>
> > I tried conducting some simple load tests with
> > squid using the redirectors.
> > 1 redirector worked fine for 5 simultaneous
> browser
> > clients(that is w/o throwing a FATAL error and
> > restarting),
> > 2 redirectors worked fine for 14 browser
> clients
> > but subsequent tests showed that even with 5
> > redirector clients,20 browser clients cud not be
> > handled simultaneously. I don't want to enable
> > redirctor bypass though.
> > I am failing to understand this behaviour. I
> would
> > be thankful if u cud spare some time to explain
> what
> > cud be happening here and tell me a solution for
> it.
> > Regards and TIA,
> > Deepa
> >
> >
> > --- Hendrik_Voigtländer
> <hendrik@voigtlaenders.net>
> > wrote: > Hi,
> >
> >>E250 with how many processor of what type?
> >>Probably you have an performance problem with the
> >>sleepycat berkeley-db.
> >>If all your processors are busy all the time
> >>increasing the number of
> >>redirectors won't help.
> >>
> >>In this case I would switch over to Linux with an
> >>Intel machine. We have
> >>replaced our old E450 with an HP/Compaq ML370
> >>(decent machine, but not
> >>high end) with a significant improve in squid
> >>perfomance. I gave up on
> >>compiling squidguard on solaris, to much hassle
> and
> >>to much load
> >>probably as well for the 168MHz(!) processors.
> >>With debian no problem at all, 'apt-get install
> >>squidguard' and done...
> >>
> >>I really like the idea of using multiple cheap
> >>machine with
> >>loadbalancing and failover, but IMHO you need to
> use
> >>automatic proxy
> >>configuration to achieve this. I would use server
> >>hardware for this, but
> >>something cheaper than HP/Compaq, for instance
> >>Supermicro.
> >>
> >>Get cachemgr.cgi running, it is really useful to
> >>look at squid &
> >>squidguards status.
> >>
> >># TAG: redirector_bypass
> >># When this is 'on', a request will not go
> >>through the
> >># redirector if all redirectors are busy.
> If
> >>this is 'off'
> >># and the redirector queue grows too large,
> >>Squid will exit
> >># with a FATAL error and ask you to increase
> >>the number of
> >># redirectors. You should only enable this
> if
> >>the redirectors
> >># are not critical to your caching system.
> If
> >>you use
> >># redirectors for access control, and you
> >>enable this option,
> >># then users may have access to pages that
> >>they should not
> >># be allowed to request.
> >>#
> >>redirector_bypass on
> >>
> >>As you may have noticed it is impossible to filter
> >>100% of all unwanted
> >>stuff, bypassing in high load situations won't
> make
> >>things much worse.
> >>
> >>Keep an eye on the redirector stats in cachemgr
> how
> >>many requests are
> >>actually bypassing squidguard. In our setup it is
> >>less than 1%.
> >>
> >>Regards, Hendrik.
> >>
> >>
> >>Merid Tilahun wrote:
> >>
> >>>Thanx Hendrik
> >>>I am running squid on solaris 8, sun enterprise
> >>
> >>250
> >>
> >>>machine. I have more that 500 users connect at
> >>
> >>peak
> >>
> >>>hour.
> >>>I never got around to configure cachemanager.cgi,
> >>
> >>I
> >>
> >>>will look in to that.
> >>>I use squidguard to filter porn, and it seems to
> >>
> >>be
>
=== message truncated ===

________________________________________________________________________
Yahoo! India Matrimony: Find your partner online. http://yahoo.shaadi.com/india-matrimony/
Received on Mon May 31 2004 - 05:52:03 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Jun 01 2004 - 12:00:02 MDT