Hi all, just to let you know: using the 3 small changes described in the performance posts, and using a join on the filterWrite, the client is now running fine on a machine with a load of 10 (Solaris, 2 CPUs). The trouble happens at a load of 14 or higher. So we can consider that these 3 settings are really needed (should they be default ?).
Thanks for your time. Thanks for you framework! Fred FredAtMina wrote: > > Hi Trustin, > > unfortunately, as this involved some specific server behavior (which is > not accessible), this is not possible. > I ran some few tests, and noticed that in fact, the trouble is not only > for the read, but also for the write (12" sometimes, in my test, between > the filterWrite and the data on the wire), even the idle notification is > late (by 8" in the same case, but this is "normal" as the read is late > within the mina layer), so this may be, helas, only a side effect of the > load on the server (which is not related to the client using mina but to > other processes which can take lots of CPU cycle for a small period of > time). I'm not sure how /if I can improve this. If I look at the logs I > have, I have a "hole" of 10 seconds which means during this time, nothing > happens at the application layer. Is there something at the network layer > or is it only because the process doesn't have much CPU during this short > period of time I don't know. I'll take a look at the performance hints you > gave in some posts to see if this can help. > > Regards, > > --Fred > > > Trustin Lee wrote: >> >> Hi Fred, >> >> I'd like to run the test by myself to track the problem down, because >> it's not really easy to give any advice as you know. >> >> Trustin >> >> On Nov 14, 2007 7:37 AM, FredAtMina <[EMAIL PROTECTED]> wrote: >>> >>> Hi all, >>> >>> during some tests, I noticed that, under heavy load on the physical >>> machine >>> (load of 10 for 2 CPUs), data are entering the machine at time t0 but >>> are >>> available for messageReceived at t0 + N seconds, where N can be more >>> than 10 >>> seconds... >>> The test: >>> - client sending 1 byte and reading some bytes >>> (a) everything is fine when load is under 4 (roughly) >>> (b) when server load is above 4, then delay appears >>> I did a tcpdump to see data at the OS layer (data entering the OS) >>> and common logging to see data at the messageReceived layer >>> >>> For write, delay occurs sometimes during the same period, but with less >>> than >>> 1 second between filterWrite and data being sent by the server. >>> >>> As the data is small (1 byte written, few bytes read), but we have 500+ >>> concurrent connections, is there any customization, through the API, >>> that >>> can be made. >>> >>> Regards, >>> >>> Fred >>> -- >>> View this message in context: >>> http://www.nabble.com/Delay-between-data-reception-by-the-OS-and-by-messageReceived-tf4801019s16868.html#a13736157 >>> Sent from the Apache MINA Support Forum mailing list archive at >>> Nabble.com. >>> >>> >> >> >> >> -- >> what we call human nature is actually human habit >> -- >> http://gleamynode.net/ >> -- >> PGP Key ID: 0x0255ECA6 >> >> > > -- View this message in context: http://www.nabble.com/Delay-between-data-reception-by-the-OS-and-by-messageReceived-tf4801019s16868.html#a13768003 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
