river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cornelius, Martin (DWBI)" <Martin.Cornel...@smiths-heimann.com>
Subject Re: [jira] Created: (RIVER-280) make JERI MUX protocol impl maxFragmentSize configurable
Date Thu, 20 Dec 2007 08:32:53 GMT

Hi Bob,

i'd like to note, that the initial goal when i built my little test was,
to find out how JERI and JRMP (and CORBA as well) compare with regard to
*CPU* usage when large data chunks are transferred. Hence, i started
server and client on the same, otherwise unloaded machine. I became a
little alarmed when i noticed, that in this test the throughput with
JERI was below the theoretic capacity of a 100Mbit network, although the
2Ghz CPU was 100% utilized by just shipping the data. In fact, this
would state a knockout against JERI as 'general purpose' transport in
our applications. Thus, i was really happy to find out this is just a
matter of adding 1 line of code to make the fragment size configurable. 

BTW, with a fragment size of 8K and unlimited ration, i also get roughly
the same througput (at 100% CPU) with JERI and JRMP when server and
client are on the same machine.

Another BTW: Do you think that unlimited ration has the consequence that
the deadlock-avoidance feature of JERI Multiplexing is compromised ?

Kind regards, Martin


 
************************************************
The information contained in, or attached to, this e-mail, may contain confidential information
and is intended solely for the use of the individual or entity to whom they are addressed
and may be subject to legal privilege.  If you have received this e-mail in error you should
notify the sender immediately by reply e-mail, delete the message from your system and notify
your system manager.  Please do not copy it for any purpose, or disclose its contents to any
other person.  The views or opinions presented in this e-mail are solely those of the author
and do not necessarily represent those of the company.  The recipient should check this e-mail
and any attachments for the presence of viruses.  The company accepts no liability for any
damage caused, directly or indirectly, by any virus transmitted in this email.
************************************************

Mime
View raw message