--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
> Agree. I meant that after a spike of requests there will be left large amount of
> threads in idle state, that might never be used again. Creation of threads on
> demand should be there anyway. Or do you mean fixed number of threads?
> Idle threads still consume resources (stack at least) so I think its good to
> timeout them after some idletime. I believe Apache does something like that
> also.
I suppose an idle timeout might be worthwhile. But then again, squid
has peaks in load, so why not keep them around. They may chew up some memory
unneccessarily during low demand loads, but unless you're killing the machine
for other tasks during that time, do you care if there's say 1MB of swap
being used to account for idle threads?
Fixed numbers of threads is not what I meant. I meant creating threads
as required if there weren't any spare. So yes, a spike of creations, then
falling into a lull. You'll find that bound threads under Solaris work this
way too (even if they quit, they don't really, they just stay idle in the
background until a new thread is required again).
> Perhaps due to my lack of appropriate coding experience.. I'm basing my
> thoughts on "common sense" ;) and instead of knowing it works, I can't
> see from here how it works and is efficient. Please don't judge me hard
> for my ignorance. I would love to see some working code with this model
> to get an idea.
Looks at my asyncio stuff in squid 1.2 alpha. Some people say it
works, some say it doesn't. I'm not working on 1.2 at the moment, but the
patches were submitted copies of our code here that work fine. We're on
Solaris 2.5.1.
Cheers,
Stew.
-- Stewart Forster (Traffic and Web Proxy Cache Administrator) connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust. Email: slf@connect.com.au Phone: +61 3 9251-3684 Fax: +61 3 9251-3666 --MimeMultipartBoundary--Received on Tue Jul 29 2003 - 13:15:43 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:27 MST