Thanks for the great explanation, so If I have 2 dual core processors,(number of processors + 1) IOProcessors which is 5 IoProcessors in my case.
Only way I can configure number of IOProcessors is as follows: So I can either use: SimpleIoProcessorPool pool = new SimpleIoProcessorPool<NioSession>(NioProcessor.class,5); final IoAcceptor acceptor = new NioSocketAcceptor(pool); or final IoAcceptor acceptor = new NioSocketAcceptor(5); but I guess since I have only one IoAcceptor in my server class, I shouldn't use SimpleIoProcessorPool at all and I should go with: final IoAcceptor acceptor = new NioSocketAcceptor(5); So this means that I will have 5 IoProcessors for a single IoAcceptor, so hopefully that will give me some performance increase. On top of this if I have an executorfilter with 40 threads, I feel like I can deal with 40 requests per second. Because each IoProcessor will have 8 requests queued up which individually takes 1 second to complete unless there's a race condition somewhere, it should be possible to process 40 requests per second, am I wrong? Erinc On Wed, Mar 24, 2010 at 10:09 PM, Emmanuel Lecharny <[email protected]>wrote: > 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 > > >
