On 4/5/07, yann Blazart <[EMAIL PROTECTED]> wrote:
Thanks ! My use case is to provide a framework to make a replacement of Rmi for internal use in entreprise (RAD) without the f... problems of registry SecurityManager and codebase and Remote interface.... , based on Mina (very fun framework you've done !)
If you just want a replacement for RMI you should take a look at the Spring Remoting options: http://www.springframework.org/docs/reference/remoting.html They make it very easy to remote a POJO and solve a lot of the problems of RMI. But if scalability is your main concern, MINA will probably be a better solution :-) Maarten I will try to improve my framework (called Roc), code a specific codec and
make a bench under heavy loading against Rmi, I will send to this list the conclusions of my benches. Thanks a lot ! On 4/5/07, Vinod Panicker <[EMAIL PROTECTED]> wrote: > > On 4/5/07, yann Blazart <[EMAIL PROTECTED]> wrote: > > Hi thanks for your answer, but I 've tried to set the tcpNoDelay to > false on > > each side and I didn't saw any really performance improvment. > > The first problem is that if I test by only sending message but not > waiting > > for response, mina take 0.12 ms per call, aigainst Rmi that take 0.16ms > per > > call with the response. Is NIO slower than BIO, but more robust ? > > I guess you can say that NIO is more efficient that BIO in most cases. > Usually servers need to handle lots of concurrent connections and > that is where NIO really shines. In your use case, if you have just a > single server and client and if there is no cpu starvation for the > threads, it is not at all surprising to see better performance from > BIO. In fact, due to recent OS level improvements, using a > thread-per-connection model with BIO for a server seems to work pretty > well for quite a few use cases. > > If your client and server are over the internet, do remember to factor > in I/O wait times that will occur if you use BIO. If you can tell us > what your use case is, we can provide better suggestions. > > HTH, > Vinod. >
