If memory serves, it's best to make the buffer sizes as close to the TCP payload packet size as possible. Depending on your OS, there are some settings you can tweak which will make your network sub-system take your data and try to "fill up" the TCP packets (thus sending fewer, but larger, packet), or send off a new packet with every 'chunk' of data.
Unless something very off is going on, I'd expect the socket approach to be pretty quick (in relation to the RMI approach) without have to do any lower level tweaking. I'm a bit hazy on the details, so take the above with a decent pinch of salt. On Fri, Sep 17, 2010 at 2:56 PM, Silas De Munck <[email protected]>wrote: > On Friday 17 September 2010 14:22:43 Patrone, Dennis S. wrote: > > Are you buffering your naïve streams? I not sure if RMI buffers > internally, > > but I suspect it does. Depending on the size of the objects you are > > serializing, buffering could make a big difference. > > I tried putting BufferedInput/OutputStreams around the socket streams, but > this > does not seem to make a difference. > > Would it be necessary to tweak the socket receive and send buffer sizes? > > Thanks, > > Silas > > > > > -----Original Message----- > > From: Tom Hobbs [mailto:[email protected]] > > Sent: Friday, September 17, 2010 7:51 AM > > To: [email protected] > > Subject: Re: Jini RMI vs TCP throughput > > > > Hi Silas, > > > > A brief look on the web throws a couple of links which suggest that RMI > > should be *slower* that a Socket implementation. > > > > See; http://java.sun.com/developer/technicalArticles/ALT/sockets/ > > > > I would suggest that the problem lies with your "(naive) socket > > implementation". As to what the problem could be, I'm afraid that I'm > not > > an expert in that area - especially without seeing any code. > > > > My personal approach might include; > > - Decide that my RMI approach was fast enough and leave it alone > > - Use something like Wireshark and test both approaches to see if it's > the > > transmission or the de/serialisation which is taking the time > > > > Have you considered re-asking this question on something like Stack > > Overflow? > > > > Sorry I can't be more help. > > > > Tom > > > > On Fri, Sep 17, 2010 at 12:28 PM, Silas De Munck > <[email protected]>wrote: > > > Hello, > > > > > > In the context of a distributed discrete event simulation, I need to be > > > able > > > to send objects at a high rate between program instances on different > > > hosts. > > > Initially I implemented this using remote calls to an object instance > > > living > > > on the other side. This performs fairly well, but because essentially I > > > only > > > need a one-way stream-connection with asynchronous sending, I thought > > > using the RMI mechanism for this was not the best solution. Therefore I > > > added a TCP > > > implementation using Sockets and ObjectStreams. > > > > > > Now comparing the RMI and the socket implementation, the results are > > > somewhat > > > strange. I expected the sockets to perform better because of the > reduced > > > overhead, but this isn't the case. My (naive) socket implementation > only > > > reaches about 25% of the througput rate of the RMI implementation. > > > > > > Does RMI use a different (faster) serialization implementation, > compared > > > to the > > > serialization used with ObjectInput/Output-stream? > > > Are there any other differences that could explain the performance > > > difference? > > > > > > Any pointers on where to start investigate this issue would be very > much > > > appreciated. > > > > > > Regards, > > > > > > Silas > > > > > > > > > > > > > > > -- > > > > > > Silas De Munck > > > PhD Student > > > > > > Computational Modeling and Programming (COMP) > > > University of Antwerp > > > Middelheimlaan 1 > > > 2020 Antwerpen, Belgium > > > G2.07, Department of Computer Science and Mathematics > > > > > > e-mail: [email protected] > > -- > > Silas De Munck > PhD Student > > Computational Modeling and Programming (COMP) > University of Antwerp > Middelheimlaan 1 > 2020 Antwerpen, Belgium > G2.07, Department of Computer Science and Mathematics > > e-mail: [email protected] >
