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
