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] Writing to an IoSession
Date Tue, 25 Oct 2005 11:47:57 GMT
Hi Trustin,

> Most web applications nowadays uses external resources such as JDBC 
> connection, so this means that MINA-based (NIO-based strictly
speaking) 
> HTTP server can outperform in overload situation.  

This is true... However, most (java) web applications nowadays also use
the servlet API - which is blocking request / response based.
Most also sit on top of frameworks such a struts, spring, et al which
are also blocking.

Hence Im chuking the servlet Api out of the window and starting from
scratch (its just not worth trying to get async behaviour hooked in to
the servlet API - you end up chasing your tail!!).
I don't expect many people in the "main stream" would want to be using
it (no struts etc).
However, if it turns out to be good - then who knows - maybe one day
it'll be the next tomcat :o)
I think the emergence of technologies like AJAX might also increase the
need for this sort of application - so maybe there is a market emerging
:o)

> HTH

Yes - that definitely helps. Thanks! 

Regards,

Dave
________________________________

From: Trustin Lee [mailto:trustin@gmail.com] 
Sent: 25 October 2005 12:38
To: Apache Directory Developers List
Subject: Re: [mina] Writing to an IoSession


Hi Dave,


2005/10/25, Irving, Dave <dave.irving@logicacmg.com>: 

	Its still early days at the moment :o)
	Basically, I work on a product which is used as a gateway in
some
	scenarios (e.g, receive an multi-media message, send it out to
another
	(off-board) application, and return a response to the original
client 
	when we receive a response from the application.
	In this example latency can be high (up to 20 secs per request).
	
	So, what I needed was high-throughput even at high latency.
	In tomcat, this means having a very large number of processor
threads - 
	(which can obviously cause scalability problems).


Most web applications nowadays uses external resources such as JDBC
connection, so this means that MINA-based (NIO-based strictly speaking)
HTTP server can outperform in overload situation.  



	So what Im doing is coming up with a through-and-through
asyncronous API
	for web applications, and a (NIO driven) web server to host such

	applications.
	
	At the moment, its still early days. But I can give you an
example of a
	test I ran this morning:
	
	
	
________________________________________________________________________
	___
	/          | Client Threadds | Server Threads | Requests | 
	Requests/second  \
	
|_______________________________________________________________________
	____|
	|AsyncWeb  |      50         |      21        | 50,000   |
607
	|
	|Tomcat    |      50         |      50        | 50,000   |
471 
	|
	
\_______________________________________________________________________
	____/
	
	Tomcat had a simple Servlet configured which just gave a "hello
world"
	reply to each HTTP request.
	Likewise, AsyncWeb had a simple AsyncHttpService configured
which gave 
	the same "hello world" replies.
	No connection keep alives were used (that comes later...).



The result shows 28.8% throughput improvement with less than half number
of threads.  Sounds cool. 




	Question:
	
	Could you possibly tell me where to look to find out how to
control the 
	number of threads created for processing MINA events? I noticed
that I
	was receiving call-backs from MINA on 21 threads....


Are you using SimpleServiceRegistry?

You have to get an instance of IoThreadPoolFilter and call
setMaximumPoolSize() event: 

ServiceRegistry registry = new SimpleServiceRegistry();

IoThreadPoolFilter threadPoolFilter = ( IoThreadPoolFilter )
registry.getIoAcceptor( TransportType.SOCKET ).getFilterChain().get(
"threadPool" ); 
threadPoolFilter.setMaximumPoolSize( 10 );

HTH,
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