Re: JERI vs. JRMP performance penalties

Dan Creswell <[email protected]> Wed, 12 Dec 2007 13:04:40 +0000
Newsgroups gmane.comp.java.sun.jini
Message-ID <[email protected]>
Mark Brouwer wrote:
> Hi Martin,
> 
> Cornelius, Martin (DWBI) wrote:
>> Hi again, Mark
>>
>>> Could you tell a bit more about the kind of invocations you are
>>> making and whether these took place concurrently, etc. 
>>
>> Essentially, i send a large buffer of data from a single client, no
>> concurrency at all. This scenario may be somewhat unusual, but it is
>> realistic in our application.
> 
> That was what I was expecting, maybe Peter Jones wants to chip in why in
> this case Jini ERI performs that worse compared to JRMP. The only thing
> I can think of has to do with the inbound, outbound ration which is set
> to a default of 32 KB, but here I start really guessing.
> 
> for an explanation of the inbound, outbound ration see
> http://java.sun.com/products/jini/2.1/doc/api/net/jini/jeri/connection/doc-files/mux.html
> 
> 
>>> Also I'm curious whether you had GC logging enabled to see whether
>> there
>>> are some anomalies between the 2 tests and whether you monitored the
>>> load of your systems for both tests
>>
>> Actually, being still a java newbie, i don't even now how to enable GC
>> logging. I monitored the load of my system by looking at the output of
>> my graphical KDE system monitor, it was about 100% in both tests. To
>> have my results not influenced by DGC, i disabled DGC in the JERI case
>> (unfortunately not possible for RMI)
> 
> Have a look at
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html, but it
> comes to adding -Xloggc:<file> to the command that starts your Java
> application.
> 
>> If i run JERI with useNIO, throughput increases to 24Mbyte/sec, what
>> means factor 6. The total system load caused by the test (viewed with
>> top) was 100% in all cases, *roughly* 60%user and 40%system.
>>
>>> One last question is what would the typical usage be in the field you
>> want > to utilize it?
>>
>> The primary task of the system i have to design is distribution of
>> high-res images (Size of one image from 2 up to 100 Mbyte) in a large,
>> partly fragile network. For this reason, it is really crucial that the
>> throughput of the transport for large data chunks (and the system load
>> caused by this) is in the order of using TCP sockets directly (factor 2
>> would be acceptable).
>>
>> To make my observations retraceable, here is the test i used: The client
>> and the implementation is the same for both tests, just the exporting
>> server is different. (The setting of useNIO is commented out below for
>> server and client)
> 
> Thanks for adding the code, takes away a lot of guessing. I noticed you
> send data in chunks of ~10MBytes which is rather huge. I have done file
> transfer as a service as well and I used chunks of around 64KBytes,
> but in my case the files were around a few MBytes and that way I could
> show a progress bar about the completion.
> 
> With regard to your requirements, nothing will be beat a tuned dedicated
> socket protocol with regard to speed. I don't know whether in the final
> system you need all the other features of Jini (discovery, lookup, etc.,
> security) and that you want to create proper business interfaces for
> your services instead of defining a raw protocol.
> 

I've had success with using a Jini proxy do most of the service work
whilst uploading/transfering over http or ftp.  The proxy can do all
sorts of useful things like handle the initial request for transfer,
e.g. setting up leases, ensuring space is available for the transfer and
the like.

There are a number of http/ftp server implementations that you can embed
inside of your service and you can usually have the client-side stuff
downloaded as part of codebase saving the client a bloated classpath....

> If the answer to some of those is yes, you could still decide to use a
> raw socket protocol for the file transfer itself but you won't get some
> of the features part of Jini ERI for free. Jini doesn't require RMI for
> the proxy to server communication.

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]