directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <dave.irv...@logicacmg.com>
Subject RE: [mina] Multiple IO processors?
Date Tue, 08 Nov 2005 17:38:01 GMT
Hi Trustin,
 
Wow - this is interesting.
I've just hacked SocketIoProcessor and SocketSession to use a
configurable number of selector loops (SocketIoProcessor#Workers).
In my environment (8 CPU HP-UX), I get just under a 30% overall
throughput boost by using two workers instead of one (and obviously this
is only worthwhile doing if the environment makes it beneficial).
 
The test went as follows:
    - 5000 client connections (all doing HTTP keep-alives - no
connection churning)
    - Each client does request / response cycles as fast as possible
down its connection
    - Overall throughput is measured at the server
 
With one selector loop, I was hitting an average of 5.5k request /
response cycles a second. 
With two, I was hitting an average of 7k.
 
 
I must point out very strongly that this is just a hack job as a "proof
of concept" - and the code would definately need to be cleaned up quite
a bit before it was concidered even remotely ready (e.g, at the moment I
steal the number of workers to use from a Sys property, and the "Worker"
class changes are very hacky).
The bits which would need some serious refactoring before being
concidered for inclusion are marked with "TODO"s.
 
Basically, the prototype code does this:
 
1) Pushes all the queues from SocketIoProcessor in to
SocketIoProcessor.Worker.
2) Each SocketIoProcessor.Worker now has its own Selector
3) A number of Workers are created upfront (one for each selector loop)
4) As a new session is added using SocketIoProcessor#addSession, it is
assigned a worker in a "round-robin" fashion
5) SocketSession has been updated to hold the Worker associated with the
session
6) When SocketIoProcessor wants to work on a selector, it asks the
session for its Worker and performs the task w.r.t to that worker
 
As I said above, its very hacky right now, but just wanted to let you
know the results of my prototyping.
I've attached the associated files (based on mina 0.8 release).
 
Let me know what you think,
 
Cheers,
 
Dave
 
 
 

________________________________

From: Trustin Lee [mailto:trustin@gmail.com] 
Sent: 08 November 2005 11:36
To: Apache Directory Developers List
Subject: Re: [mina] Multiple IO processors?


Hi Dave,


2005/11/8, Irving, Dave <dave.irving@logicacmg.com>: 

	I know this is a long shot - but is there any way to set up more
than one underlying IO processor?


Not yet, but we'll have to experiment if multiple I/O processors can
boost the performance in a multi-processor machine.  I'm busy now
implementing StartTLS for ApacheDS, so it would be great if you can
modify SocketIoProcessor a little bit.  I think the modification should
not be that hard.  (~1 hr task) 



	Im currently working on an 8 CPU box: Overall cpu usage isn't
getting anywhere near the limit, but after profiling, Im seeing the
selector loop thread getting hit with quite a bit of starvation. Would
there be any benifit in having more than one selector loop in
environments with a large number of cpus?


AFAIK, there's no much benefit, but we have to experiment and let users
choose the number of selector loops if it can bring them any performance
gain.



	Oh - just to keep you up to date with my tests: Im getting
throughput of around 6k HTTP requests per second and see very stable
behaviour right up in to the 7k simultaneous connections Im currently
testing with. Thanks again for such a stable and easy to use framework!


This is great!  It would be also great if we can compare Apache 2.1.x,
Tomcat 5.5.x, and your MINA HTTP codec and announce the performance in
my ApacheCon US 2005 session. 

Thank you for continuing contribution!
Trustin

-- 
what we call human nature is actually human habit
--
http://gleamynode.net/ 


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

Mime
View raw message