AW: JERI vs. JRMP performance penalties

Hi Mark, thanks again for answering my questions.

> 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

Having read that documentation, i now understand better why performance of JERI for 'big buffer' transfers deviates from simple JRMP significantly, as JERI in turn offers significant enhancements in case of multiple concurrent connections. Once i get time for that, i'll try to investigate if increasing of the 'rations' will help to improve performance in this special case. 

> 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.

At the moment, we are mainly looking for a general remote method invocation mechanism that might replace CORBA/iiop. However, we are in an analyzing state and will have to look at the other Jini features with a lot more more detail.

Martin

> -----Ursprüngliche Nachricht-----
> Von: Mark Brouwer [mailto:[email protected]]
> Gesendet: Freitag, 7. Dezember 2007 16:29
> An: Cornelius, Martin (DWBI)
> Cc: [email protected]
> Betreff: Re: JERI vs. JRMP performance penalties
> 
> 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.
> 
> 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.
> --
> Mark
> 
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

 
************************************************
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.
************************************************

--------------------------------------------------------------------------
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]