Re: network effeciently
From: Chris Uppal (chris.uppal_at_metagnostic.REMOVE-THIS.org)
Date: 05/12/04
- Next message: Chris Uppal: "Re: ForLoop Performance / Algorithm question"
- Previous message: Liz: "Re: java help"
- In reply to: Parker Thompson: "Re: network effeciently"
- Next in thread: Yu Song: "Re: network effeciently"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 12 May 2004 09:32:59 +0100
Parker Thompson wrote:
> > This would be sensible and intelligent advice -- except that you haven't
> > noticed that he's wrapping the raw networking streams in
> > Buffered{Out/In}putStreams.
>
> A question on this point: does the buffer size have an impact?
Whatever effect it may have, it's unlikely to explain what you are seeing.
I haven't checked the code, but I thing it would be quite difficult to persuade
a BufferedOuputStream to send very small IP packets, at least if you are in a
tight loop trying to write to the network. For instance, if you created the
stream with a 1-byte buffer -- surely the worst possible case -- then went into
a loop trying to send data through it, then
- Each byte would be sent to the underlying
Java network code individually.
- The underlying code would /probably/ have no
internal buffering and so would send each byte
directly to the OS.
- The OS would buffer up the data using "Nagle's
algorithm" and so end up putting it on the wire in
full sized IP packets anyway.
("Nagle's algorithm", is the process where the OS doesn't send data out
immediately if that data would not fill an IP packet, but instead waits for a
short time (a few millisecs I think) to see if the application will add any
more data. It's controlled by one of the socket options, but is turned on by
default).
That would have considerable overhead from all the extra system calls, which
would definitely slow things down, but not to the extent where it was taking
around 100 microseconds to go round each iteration of your loop.
> I'm
> unclear how the in/out stream buffers affect the size of the tcp packets.
Unless you disable Nagle's algorithm, it's very difficult to control the size
of the packets. Unless you have an application that needs to control /when/
the data is sent with a granularity of less than a few millisecs (which is rare
but not unheard of -- I needed it once) then Nagle is your friend.
> Should I be setting a non-default buffer size, or perhaps just skip
> buffering alltogether so I know what's going on?
These are both options that you may want to consider *after* you've found and
fixed whatever is causing the problems you are seeing. The way you have the
code now (judging by the extracts you posted) is fine as is. It is clear and
simple and should be reasonably efficient. As with all optimisation, you do it
*after* the code is working and in response to an /actual, measurable/
performance problem. You don't go writing complicated code just for the hell
of it (though it would seem that some of the other posters in this thread don't
agree ;-) The measurements I posted earlier indicate that it highly unlikely
that the use of single-byte writes into a buffered stream can cause the kind of
problems you are seeing (remember *four orders of magnitude* !), so I think you
have to look elsewhere. The advice Andy Fish posted about checking to see
what's maxed-out is good.
Still, if you want to see what's going on the network then get yourself a copy
of ethereal (free at <www.ethereal.com>). It may help you focuss on the real
problem. If it turns out that you /are/ sending tiny packets then it's
probably a bug in your code for setting up the buffering. If not then you will
be able to look elsewhere without distracting yourself with packet sizes.
-- chris
- Next message: Chris Uppal: "Re: ForLoop Performance / Algorithm question"
- Previous message: Liz: "Re: java help"
- In reply to: Parker Thompson: "Re: network effeciently"
- Next in thread: Yu Song: "Re: network effeciently"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
