On 2/10/11 4:06 PM, adi milis wrote:
Probably because your client has disconnected. There is no way for the
TCP stack to know that a client brutally shutdown its computer. You have to
deal with idle connections on the server side.
It's not actually computer, it's rather a handset device. But I got your
point.
in sessionIdle() we have the client removed after 60 seconds of inactivity.
the protocol have ping / heartbeat to make sure the connection is still
active.
Fine.
step #2 is related with database, we find the average time required is
very
acceptable (less than 100ms)
100ms ?? Whaooohhh. This is incredibly high ! I would expect a DB to be
able to process a request in less than 10ms...
Actually a lot lesser than 100ms, maybe close to 10ms. I'm just being humble
:)
Ok, much better...
Concurrent users != concurrent requests. How many request per second are
you trying to process when the problem occurs ?
Most of the user only perform heartbeat every 30 sec.
at best it's only 20 request per sec, worst 600 doing ping at the same time
(unlikely tough) ?
Adding sending message and other request .. it's likely average 30 request /
sec.
Am I doing my calculation right ?
If you have 600 handset being pinged at the same time, then you'll have
600 req/s :)
What is important here is to determinate the time it takes to process
one single request multiplied by the number of threads you have to
process those requests. Let's say you use 10 threads, and that a
requests costs 50 ms to be processed, then on your server you'll be
maxed at around (1s/0.05ms)*10threads = 200 req/s. For pings, the time
needed to process the request is most certainly sub-ms, so there is no
trouble.
FYI, I'm able to process up to 4500 LDAP requests per second on my
laptop, the LDAP server being written in Java on top of MINA. There is a
wide margin if your application does something simpler than a LDAP
server :)
Also how many IoProcessor do you use, how many core do you have on your
server, what is the internal network bandwith ?
I'm using this code to create my socketAcceptor.
chatAcceptor = new
NioSocketAcceptor(Runtime.getRuntime().availableProcessors() + 1)
The server is quad core with gigabit ethernet (only one interface connected
to network carrier, the other interface serve for LAN)
Just fine. You should have something like 9 IoProcessors, so you are golden.
The first step is to discover where is your bottleneck. Is it the DB ?
MINA ? Your application ?
I think my application is the bottleneck. For your explanation above,
related with the executor chain. What i should do in order to improve the
number of request for each IoProcessor ? I admit my understanding for MINA
and Executor is still basic. I'll spend more time to read that section after
this.
The MINA executor is nothing but a pool of threads. When an incoming
requests arrives into the Executor filter, it select a free thread in
the pool and ask it to process the request. If you pool is bounded, then
you will be only able to process as many requests as your pool have threads.
Be aware that adding an executor have deep potential impact on your
code, depending on may factors (are the sessions shared, etc)
Now, there is one thing you should do, it's to profile your application
to see where exactly you have a bottleneck. If it's the DB, then using
some cache could help.--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
