Trustin, Could you provide more information on the way in which you test and profile MINA. I would like to set up a test environment, but am curious as to how others set theirs up. As for the profiler, I use YourKit and have been really happy with it.
The only comment I have is for #2. Could we let the user pass in their own Queue implementation? This is done in different programs/API's I have seen. Case in point, ThreadPoolExecutor; it allows the user to pass in an instance of a BlockingQueue. Just my $.02 Mark On Tue, Mar 11, 2008 at 10:11 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote: > 1a) has been resolved: > > https://issues.apache.org/jira/browse/DIRMINA-546 > > Performance has been significantly improved for short-living > connections. > > I didn't resolve '1b)' because these getter calls are essential in most > case. For example, they are usually used for logging. > > 3) also has been resolved: > > https://issues.apache.org/jira/browse/DIRMINA-547 > > Now frequent connection attempt shouldn't cause any overhead comparing > to blocking I/O. > > I'm still not sure how much we will gain by fixing 2) and 4), so I > didn't fix them yet. > > 2008-01-17 (목), 12:26 +0900, Trustin Lee 쓰시길: > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > Trustin Lee - Principal Software Engineer, JBoss, Red Hat > -- > > > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- -------------------------------- Talent hits a target no one else can hit; Genius hits a target no one else can see.
