Woops I had a typo......
# > Thanks for your answer.
# > If I implemented logging in the filterchain, doesn't that have a
# > chance of blocking IO on the server until it completes, because the
# > filters are running in the IoProcessor thread?
#
I meant to say implement Authentication ("Login", not logging) in the
filterchain... This would be before the ExecutorFilter (which is last) and
will be making DB requests... Those requests could potentially block the
IOProcessor thread because those filters are running in it. So I didn't
really think it would be a good idea to implement authentication in a Filter
as the FAQ suggests. It is working fine in my IoHandler, I just have a few
more states in it.
Thanks for your answers... So it sounds like you are using a
ThreadPoolExecutor that you have configured properly... not one created by
Executors.createCachedThreadPool(). I think I will switch over to that so I
don't burst beyond our theoretical max... Well really my requirements are
max 1000 connections :) wish me luck. I have Dual Core AMD Opteron 1212 on
100mbs pipe and I'm writing the load testing client right now.
# 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.
#
# 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.
#
# -pete
#
#
# --
# [EMAIL PROTECTED] - http://fotap.org/~osi
#
#
#
#
