Chris,
I am inclined to agree with you on many of your points. Let me just add some context here. The part of the application where I'm using MINA is a sort of middleman between two endpoints that are transmitting audio/video streams. The "fun" part is that clients A and B don't have the same audio/video codecs so when I receive data from A in the Main Server (MS), I must "translate" (transcode) it to something that B can understand and vice-versa. This is done by passing the packets by a Transcoder Server (TS), which, for scalability and availability purposes, is kept running in a separate process or machine. So the route for a given packet from clients A to B is A -> MS -> TS -> MS -> B. At first I was using ObjectSerializationCodecFactory. It did great, the performance is nice and it really got me set up fast. When I came back for some performance improvements, I decided to write my own CODEC, since MINA makes it a breeze. While the first results of the custom codec were promising in terms of speed and size reduction (using that totalTestTime / numberOfPackets approach), when I set up that codec in the production server, the system I had for per-packet tracking - measures times for packets in a given set of checkpoints - was telling me that I had no real gain - packets used to last an average of 10ms in the route A -> MS -> TS -> MS -> B and now there were still taking just about as long (ok, a wee-bit less) in there. While the size reduction alone is more than enough to justify this improvement, I was expecting to see better results in terms of speed - first, due to the fact that less data was being (de)serialized and second, because I trust that it's simply faster to parse a couple of bytes, shift some bits and create a new object than to dump some bytes to the ClassLoader and get an instance back. That brings us to that little LifetimeIssues.java, which was just a way to describe, with code, the issue that I was experiencing. > The calculated average lifetime is a reasonably fairer value, since the > counter keeps running for the whole time packets are send and > received...however this also means it will include a lot more > overhead...which generally won't matter but in the case of these minimal > numbers will. The fact that I am insisting so much on the individual calculations is that if an audio packet lives 10ms inside the system, it's ok - actually, it's great! - but if it takes 100 or 200ms in there, then it becomes a problem. So you see, even though throughput is interesting, what *really* matters here is individual latency. Before sending the first email, I isolated that part of the application (the MS -> TS -> MS part) and ran some tests with some "real" (faked in content, but with sizes matching real data) packets and this effect holds true, even in different machines; it's as if MS chokes when sending alot of data to TS - calling write() in a loop with little-to-no interval. After some careful measuring, I reached the conclusion that the problem lies with data leaving MS - it takes about 2ms in TS between messageReceived() and write(...).join(), and almost nothing to get back to MS, so the bottleneck is MS -> TS part. Sorry for the long email, I hope this sheds a better light on this case ;) Best regards, Bruno On Fri, Jul 24, 2009 at 8:33 PM, Christopher Popp<[email protected]> wrote: > Ah, > > I'm going to have to agree with Emmanuel on this one. The resolution of time > measurement (regardless of whether it is timeinMillis() or nanoTime()) is > just not accurate enough to do this sort of measurement, particularly when > you're sending the packets localhost, since the handling time is miniscule. > When set to display the time per packet with a 4 ms sleep, 99 of the packets > had a time of 0 ms, and one had a time of 16 ms. All of those packets with a > time of 0 ms of course had some time value greater than 0, but is was not > taken into account when averaged to yield the individual average lifetime. > > The calculated average lifetime is a reasonably fairer value, since the > counter keeps running for the whole time packets are send and > received...however this also means it will include a lot more > overhead...which generally won't matter but in the case of these minimal > numbers will. > > Based on the numbers, it does seem like mina will handle packets spaced out > with a sleep better than a ton of packets thrown at it at once, > however...that does not seem too astounding of a conclusion to make. As for > the note about individual lifetime being greater than the global average; it > could have something to do with the fact that the the calculated average will > benefit from parallelism of requests. This would be mostly notable when the > time it takes to handle requests is greater than the sleep between packets > though, since in that case it would be a serial process. > > I like numbers and statistics though and am interested in the performance of > Mina, so it sounds like you have a nice project. It depends what you're > particular goal is...but you may want to try things like increasing the size > of your message, or sending them between two physical computers instead of > localhost, so that the time per packet is greater and weights heavier against > the error in the system time keeping. > > Chris > > > > ________________________________ > From: Bruno de Carvalho <[email protected]> > To: [email protected] > Sent: Friday, July 24, 2009 12:21:04 PM > Subject: Re: Message processing issue with MINA > > Chris, > > > Thanks for your attention and time. > It is in fact reasonable but if you increase the sleep time - say, > like 4ms - you will notice that the individual lifetime average goes > lower than that those 5ms. > What I'm trying to understand is why that individual lifetime is > greater than the global average. It may even be normal, I'm just > trying to get a proper and convincing explanation - these results will > go in a thesis, so you see why I need that explanation ;) > > Still, those are pretty good results, I can't get any better than an > average of 40ms with a core 2 duo lappy @ 2Ghz, both windows and > linux. > > > Best regards, > Bruno > > >
