Re: Authentication filter

[peter royal]

On Apr 23, 2007, at 4:47 PM, Brigham Stevens wrote:

Thanks for your answer.

blocking IO on the server until it completes, because the filters are
running in the IoProcessor thread?

If I implemented logging in the filterchain, doesn't that have a chance of

nope... Only filters in the chain *before* the ExecutorFilter are on the IoProcessor's threads. Filters *after* the ExecutorFilter run on its threads.

Speaking of the threading, I am using the CachedThreadPool for my protcol handler. This is an unbounded pool, so If my server gets really busy, it

could end up creating a lot of threads, right?

Yup!

Granted they would be hopefully short lived threads but doesn't this sometimes cause a performance

hit?

absolutely.

Because if we had 1000 connections sending messages to the server simultaneously, it seems that the cached threadpool could end up spawning that number of threads to deal with it, and we may get into cpu thrashing in the context switcher. Or am I wrong, and in practice the life of a message is short enough that you don't end up with so many threads...?

Depends on your environment :) ... if its a burst of 1000, as long as you can keep the data in memory, and process the data "quick enough" so that within a reasonable amount of time (ie, before the next burst) you've done all the work for that burst, you're all set. A burst will just increase latency. So, even with 1000 connections sending data at the same time, should might be able to get away with considerably fewer than 1000 threads to handle the data, as long as all 1000 aren't continually streaming. Unfortunately, this type of tuning generally falls into the "profiling" category of things.

I would be interested to know if in Trustin's load testing with AsyncWeb vs Apache if the IOHandler was using a CachedThreadPool or not, and what was

the max number of threads spwaned at any time if it was.

-pete


--
[EMAIL PROTECTED] - http://fotap.org/~osi

In performance tests I've done, I've used a CachedThreadPool, but with a core size of what i expect to generally use, and a max of what I want to burst up to. After a burst, those threads will time out and the pool will shrink back to the core size.

smime.p7s
Description: S/MIME cryptographic signature