I'm seeing some pretty bad performance which I suspect can be pinned on
SocketServer. What is strange here is that the transaction rate I'm
seeing is identical regardless of the number and disposition of the
parameters passed/returned. It's always 12.5/sec, 80ms per operation.

I've attached a trivial example that replicates what I am seeing on
Linux w/ OpenJDK 1.6

I'm happy to open a bug report, I just wanted to ping the list first to
see if this is known issue or rings any bells.

Thanks,

--
Eric Evans
[EMAIL PROTECTED]

80ms sounds like two round trips without SO_NODELAY. Does the socket server
set this socket option?

-Todd

On Sun, Jan 3, 2010 at 11:35 AM, Eric Evans <[EMAIL PROTECTED]> wrote:

>
> I'm seeing some pretty bad performance which I suspect can be pinned on
> SocketServer. What is strange here is that the transaction rate I'm
> seeing is identical regardless of the number and disposition of the
> parameters passed/returned. It's always 12.5/sec, 80ms per operation.
>
> I've attached a trivial example that replicates what I am seeing on
> Linux w/ OpenJDK 1.6
>
> I'm happy to open a bug report, I just wanted to ping the list first to
> see if this is known issue or rings any bells.
>
> Thanks,
>
> --
> Eric Evans
> [EMAIL PROTECTED]
>

On Sun, 2010-01-03 at 12:01 -0800, Todd Lipcon wrote:
> 80ms sounds like two round trips without SO_NODELAY. Does the socket
> server set this socket option?

Nope, it doesn't look like it, but I modified SocketServer and
SocketTransceiver locally to setTcpNoDelay(true), and it didn't make any
difference.

> On Sun, Jan 3, 2010 at 11:35 AM, Eric Evans <[EMAIL PROTECTED]>
> wrote:
>        
>         I'm seeing some pretty bad performance which I suspect can be
>         pinned on
>         SocketServer. What is strange here is that the transaction
>         rate I'm
>         seeing is identical regardless of the number and disposition
>         of the
>         parameters passed/returned. It's always 12.5/sec, 80ms per
>         operation.
>        
>         I've attached a trivial example that replicates what I am
>         seeing on
>         Linux w/ OpenJDK 1.6
>        
>         I'm happy to open a bug report, I just wanted to ping the list
>         first to
>         see if this is known issue or rings any bells.
--
Eric Evans
[EMAIL PROTECTED]

On Sun, Jan 3, 2010 at 7:02 PM, Eric Evans <[EMAIL PROTECTED]> wrote:

> On Sun, 2010-01-03 at 12:01 -0800, Todd Lipcon wrote:
> > 80ms sounds like two round trips without SO_NODELAY. Does the socket
> > server set this socket option?
>
> Nope, it doesn't look like it, but I modified SocketServer and
> SocketTransceiver locally to setTcpNoDelay(true), and it didn't make any
> difference.
>
>
Hm, do you have a tshark trace of the RPC conversation? Would be interesting
to see what the delay between packets looks like.

-Todd
>  > On Sun, Jan 3, 2010 at 11:35 AM, Eric Evans <[EMAIL PROTECTED]>
> > wrote:
> >
> >         I'm seeing some pretty bad performance which I suspect can be
> >         pinned on
> >         SocketServer. What is strange here is that the transaction
> >         rate I'm
> >         seeing is identical regardless of the number and disposition
> >         of the
> >         parameters passed/returned. It's always 12.5/sec, 80ms per
> >         operation.
> >
> >         I've attached a trivial example that replicates what I am
> >         seeing on
> >         Linux w/ OpenJDK 1.6
> >
> >         I'm happy to open a bug report, I just wanted to ping the list
> >         first to
> >         see if this is known issue or rings any bells.
>
>
> --
> Eric Evans
> [EMAIL PROTECTED]
>
>

On Sun, 2010-01-03 at 19:12 -0800, Todd Lipcon wrote:
> > On Sun, 2010-01-03 at 12:01 -0800, Todd Lipcon wrote:
> > > 80ms sounds like two round trips without SO_NODELAY. Does the
> socket
> > > server set this socket option?
> >
> > Nope, it doesn't look like it, but I modified SocketServer and
> > SocketTransceiver locally to setTcpNoDelay(true), and it didn't make
> any
> > difference.
> >
> >
> Hm, do you have a tshark trace of the RPC conversation? Would be
> interesting to see what the delay between packets looks like.

Attached.
--
Eric Evans
[EMAIL PROTECTED]

On Sun, 2010-01-03 at 12:01 -0800, Todd Lipcon wrote:
> 80ms sounds like two round trips without SO_NODELAY. Does the socket
> server set this socket option?

Actually, this is exactly what it is. I had used setTcpNoDelay(true) on
client and server sockets, but apparently I fat fingered something
between making the change and getting it built and in-place.

I'll submit a bug report and patch later today.

Thanks for your help Todd.

--
Eric Evans
[EMAIL PROTECTED]

On Mon, Jan 4, 2010 at 3:46 PM, Eric Evans <[EMAIL PROTECTED]> wrote:

> On Sun, 2010-01-03 at 12:01 -0800, Todd Lipcon wrote:
> > 80ms sounds like two round trips without SO_NODELAY. Does the socket
> > server set this socket option?
>
> Actually, this is exactly what it is. I had used setTcpNoDelay(true) on
> client and server sockets, but apparently I fat fingered something
> between making the change and getting it built and in-place.
>
> I'll submit a bug report and patch later today.
>
> Thanks for your help Todd.
>
>
Sure thing. With NODELAY we should make sure that appropriate buffering
happens to avoid having tons of itty-bitty packets, which can also kill
performance.

C has access to the lovely TCP_CORK option, sadly not available to Java :(

-Todd