On Thu, Mar 1, 2012 at 9:54 AM, Mark Thomas <ma...@apache.org> wrote:
> On 01/03/2012 17:13, Filip Hanik - Dev Lists wrote: > > Mark, what buffer size are you referring to increase for the web socket > > tests to all pass? > > Sorry, should have been clearer about that. > > In o.a.c.websocket.MessageInbound > > // 2MB - like maxPostSize > private int byteBufferMaxSize = 2097152; > private int charBufferMaxSize = 2097152; > > I normally multiple those by 16. The buffers need to be 16M plus a bit > for the headers so I allow a large margin ;) > I hope neither 2M or 16M will be allocated by default - that's the limit on growth ? I'm curious, did you do any load test - and what's the max number of websocket connections that can be kept alive with APR/NIO ? Costin > > Mark > > > > > Filip > > > > On 3/1/2012 9:42 AM, Mark Thomas wrote: > >> On 01/03/2012 15:03, Filip Hanik - Dev Lists wrote: > >>>> I have a draft patch [1] that seems to fix this. A similar change > would > >>>> be required for the Comet part of Poller.processKey() > >>>> > >>>> Thoughts and/or comments? Not knowing the NIO code very well, there > >>>> might be a better way to achieve the same result that I haven't seen. > >>>> > >>>> Mark > >>>> > >>>> [1] > >>>> > http://people.apache.org/~markt/patches/draft/2012-03-01-trunk-nio.patch > >>>> > >>> I took a look at the patch. IMHO it's not the right way to go. > >> That doesn't surprise me. You know the NIO code better than I do. > >> > >>> You're adding in flags to compensate for the state machine in the > >>> selector. > >> Yep. On that topic, I couldn't find any decent information on the state > >> machine in the selector. Do you know of any? There was a fair amount of > >> guess work involved investigating this issue and a clearer picture of > >> the state machine would help develop a better patch. > >> > >>> And by doing so, you will have the selector run more than it needs to > >> Yep. > >> > >>> cause you have read interest turned on, > >> Yep. > >> > >>> on sockets that you are already processing, > >> Yep. Agree with you completely up to this point. > >> > >>> wasting CPU cycles. > >> This part I wasn't so sure of. There is a problem here that affects > >> WebSocket badly and Comet intermittently and fixing that problem may > >> well require the trade off of additional processing. I compared the NIO > >> blocking figures I have and the NIO non-blocking figures to see if there > >> was a noticeable performance difference. > >> > >> The patch does impact performance. Typically it is<3% but for large > >> numbers of small packets it can be as high as ~15%. On this basis my > >> patch is clearly far from ideal. I look forward to seeing what insights > >> you have on how best to solve this for both WebSocket and Comet. > >> > >> Interestingly, I don't recall anything that suggests that this problem > >> affects HTTP although it isn't impossible that there is a very slim > >> window somewhere where HTTP may be affected. > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
