Hi Trustin,
I am not an expert, so whatever stupidity I wrote,
just take it from a "standard" user... ;-)
as an open discussion, from which I will surely learn something.
On 1) nothing great to say, your point seems obvious.
On 2) I agree ConcurrentLinkedQueue can be bad comparing
to queue with synchronized. However, as you mentioned,
it probably depends on the number of threads.
So there are probably different kinds of situations:
- where we can be sure not too many threads occurs => synchronized
- where we can't be sure (number of threads in regard of active message for
instance)
=> Concurrent
Also, what would be the default behaviour in Mina ?
This would imply to take care of a special web page on optimiziation of Mina
according to several "standard" situations.
And perhaps another point : concurrent functions improve in every
version of JVM (specially in V6, I read something about it I believe).
So, creating our own "Concurrent" LinkedQueue could be
a waste in the long term... ?
Using standard object improve the number of users able to read
and write something for the software...
3 and 5) I can't say something smart on it.
4) As 2 in last comment, creating or own executor can be
in long term not so efficient, or at least not so obviously
efficient ?
Of course, pragmatism should be keep in mind,
and if you point those issues, it should be obviously
for serious reasons and pragmatic performance reasons.
So you probably are true in these choices.
This was just my thought...
Frederic
----- Original Message -----
I did some profiling and found some bottlenecks (in the order of
importance both in terms of API stability and performance):
1) Too many system calls on session creation.
1a) MINA calls all Socket.setProperty() methods even if they are all
same with the default values.
- We need to change how the configuration works. For example, we
could use non-primitive types such as Integer to allow null, which
means default.
1b) MINA calls Socket.getProperty() methods immediately on session
creation (e.g. Socket.getLocalAddress())
- Lazy initialization?
2) ConcurrentLinkedQueue
- It performs bad comparing to synchronized CircularQueue when the
number of accessing threads are very small. We could allow a user to
change the queue implementation for each operation (e.g. accepting a
new session and write request).
3) IdleSessionChecker.addService() and removeService()
- It creates and destroys a thread too often when there's only one
connection. We could refactor it so IdleSessionChecker is not a
singleton and the service (e.g. DatagramConnector) can control its
life cycle. It will be a daemon thread anyway just in case a user
forgot to call dispose().
4) ThreadPoolExecutor.execute()
- Even if ThreadPoolExecutor is used to minimize the overhead of
thread creation, ThreadPoolExecutor.execute() has some inevitable
overhead comparing to direct system call.
5) Readiness selection model (NIO / epoll) itself
- It's non-blocking and requires an additional signaling and
notification between two threads. It causes inevitable latency which
looks relatively big when the number of managed connections is small.
I think we don't need to fix this anyways.
Fixing #1-3 is not that difficult but need some changes in the API.
I'd like to get some feed back before I proceed.
I don't have specific solution for #4; we need more investigation if
it's really big overhead. Probably we could measure again after
fixing #1-3.
Thanks for the feed back in advance,
Trustin
On Jan 9, 2008 3:19 AM, Mike Heath <[EMAIL PROTECTED]> wrote:
> Thank you for the benchmarks. This is very valuable information.
> Unfortunately, we haven't done a lot of performance turning on MINA UDP.
> This is something that we should address in MINA 2.0. Wilson, would
> you please log a JIRA issue with your benchmarks so that we can schedule
> time to work on this?
>
> -Mike
>
>
> Wilson Yeung wrote:
> > I benchmarked Mina 2.0's NioDatagramConnector vs java.net.DatagramSocket on
> > a
> > Linux 2.6 kernel.
> >
> > Mina 2.0 NioDatagramConnector, connect(), future.addListener(),
> > session.close()
> > 100,000 iterations
> > ~20 seconds
> > ~5,000 per second
> >
> > java.net.DatagramSocket, connect(), disconnect(), close()
> > 100,000 iterations
> > ~2-3 seconds
> > ~30,000 to 50,000 per second
> >
> >
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
