On 3/24/10 9:48 PM, Erinc Arikan wrote:
Hi;
I just started working on a project where I will be required to deal with as
much as 40 - 50 requests per second.
Not that much.
These requests are sync requests which
might take up to a second to process
That's a lot ...
and I will have to return response when
processing is complete. I am using MINA 2.0.0.RC1. I used Mina for some time
with lower traffic, With all due respect I don't have a complete picture of
the thread model of MINA and there's really limited resources in project web
page and I am not quite sure how far I can extend it. I know that I can add
executorfilter to provide n-threaded approach. What I am wondering is "is
NioSocketAcceptor() totally independent of executor filter?" so If I
initialize it like:
final IoAcceptor acceptor = new NioSocketAcceptor();
Will there still be only one acceptor thread regardless of how many threads
are available?
Yes.
As far as I understand, acceptor is single entry point where
a request comes in fairly faster(compared to processing it), it branches the
requests to threads and each thread takes care of each request by passing it
to the handler.
It's a bit more complicated. The acceptor is just in charge of
"accepting" the incoming connection request. It does not process at all
any message. In fact, the messages processing is delegated to an
IoProcessor.
Now, the good thing is that you can have more than one IoProcessor for a
single Acceptor. What you have to understand is that the IoProcessor is
associated with a selector(), that a session is linked to a IoProcessor,
so if a new connection comes, it's spreaded to a IoProcessor using a
round robin mechanism.
Let's say you have 1000 clients, 10 IoProcessors, then each processor
will process 100 clients.
The ExecutorFilter is a different beast : as long as a IoProcessor can
deal with more than one client, the request will be ensqueued and
processed one by one. So if a request takes a second to be processed,
you may have N requests waiting to be processed. If you add a
ExecutorFilter in the chain, then you can spread the processing further
on more threads, eliminating the initial bottleneck.
As nothing is perfect, you have to understand that you are trading the
wait on an IoProcessor for a potentially high number of thread executing
on the JVM.
So things should be good, as long as application has free threads, but what
if application receives way too many requests than it can handle and all
threads are busy at the time, what happens to that request? does acceptor
store it in a queue somewhere, or does it simply drop request?
In any case, whether you use MNA or some other stack, you still have to
deal with such a scenario. Your server won't be able to sustain a normal
execution when the number of client climb to the roof, with processing
lasting seconds, and a limited memory. Even if the requests are
enqueued, the queue can't be unlimited.
As long as my processing is fast, single entry point for requests shouldn't
be a problem for the application, but I still wonder if there should be
some other design considerations that I should be aware of to maintain
scalability.
If scalability enters in the equation, then I would say : buy more
servers, buy a load balancer appliance, it will cost you less money than
the time you will spend trying to figure out the best tuning for MINA.
Those days, a server worth 4 days of a 5 years experienced developer,
and this should be part of the equation.
That being said : stateless is the key word. If your application does
not hold a state, then you will be scalable. If the protocol is complex,
that mean you will have to build a layered system : one layer to handle
the protocol, then deffer the costly processing to another layer.
I hope I have brought a bit of light about how MINA works, and other few
things. It may be a bit off side, but Im just trying to give you some
elements of systems I already had to work with.
Hope it helps...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
