I also doubt that is the source of the contention. How expensive the selection queue depends on the OS and chosen selector. The Windows selector is probably the most expensive. Socket writes are 3x more costly there than on Ubuntu. On Aug 15, 2014 5:28 PM, "Emmanuel Lécharny" <[email protected]> wrote:
> Le 15/08/14 16:06, Jon V. a écrit : > > If you receive 5 bytes then Mina will trigger through the schedule > > mechanism which means it gets queued and a thread wakes up to process > that. > > That wakeup is one of the most expensive parts of the process. How often > > Mina wakes up is defined by how the producer is writing data to the > > socket. > > In fact, the real problem is the processing of the Selector queue. The > smaller the data received, the more often Java has to go through an > expensive processing of a queue of events. Basically, this queue (and > there are more than one in fact) is synchronized, so there is obviously > some kind of contention that occurs. I won't go into details here, > enough said that the selection process is well described in the NIO book > from Ron Hitchens (http://shop.oreilly.com/product/9780596002886.do) > > But here, I'm not sure the problem lies in the processing fo small > chunks of data. > > > > > As for the parsers it is much more simple and cost effective to buffer > the > > XML before processing it. > Sadly, this is not that simple... Typically, how do you know that you > are at the end of a XML block ? The only way is to actually parse the > full XML, and this is why having an stateful event drive parser can > help, as you just parse the content as it comes, stop when it stops and > resume when more bytes are arriving. > >
