Socket performance

[Navkirat Singh]

Hey Everyone,

I had a question, programming sockets, what are the things that would
degrade performance and what steps could help in a performance boost?
I would also appreciate being pointed to some formal documentation or
article.

I am new to this.

Warm regards,
Nav

 

[Lawrence D'Oliveiro]

In message

I had a question, programming sockets, what are the things that would
degrade performance and what steps could help in a performance boost?

Remember the old saying, “premature optimization is the root of all evilâ€.

Have you actually got some code working properly first, before worrying
about how good or bad its performance is?

 

[Navkirat Singh]

In message


Remember the old saying, “premature optimization is the root of all evil”.

Have you actually got some code working properly first, before worrying
about how good or bad its performance is?

I agree with you, it was just for the sake of knowledge. Its always good to have a map right?

 

[John Nagle]

Hey Everyone,

I had a question, programming sockets, what are the things that would
degrade performance and what steps could help in a performance boost? I
would also appreciate being pointed to some formal documentation or
article.

1. When writing to a TCP socket, write everything you have to write
with one "send" or "write" operation if at all possible.
Don't write a little at a time. That results in sending small
packets, because sockets are "flushed" after each write.

2. Wait for input from multiple sources by using "select". (But
be aware that "select" doesn't work for Windows pipes.)

John Nagle

 

[Roy Smith]

1. When writing to a TCP socket, write everything you have to write
with one "send" or "write" operation if at all possible.
Don't write a little at a time. That results in sending small
packets, because sockets are "flushed" after each write.

There's nothing that guarantees that a single write won't be split into
multiple packets, nor that multiple writes won't be coalesced into a
single packet. Or any combination of splitting and coalescing that the
kernel feels like.

That being said, for any sane implementation, what John says is true
most of the time, and is indeed a reasonable optimization. Just don't
depend on it being true all the time. The most common case where it
will not be true is if you're trying to send a large amount of data and
exceed the MTU of the network. Then you are certain to get
fragmentation.

Depending on what you're doing, this can be a point of networking
trivia, or it can be the difference between your application working and
not working. If you're just streaming data from one place to another,
you don't have to worry about it. But, if you're doing some sort of
interactive protocol where you send a command, wait for a respond, send
another command, etc, you really do need to be aware of how this works.

Let's say you're writing something like a HTTP client. You send a bunch
of headers, then expect to get back something like "200 OK\r\n", or "404
Not Found\r\n". You can't just do a read() on the socket and then
examine the string to see if the first three characters are "200" or
"404", because (regardless of how the server sent them), it is legal for
your read() to return just a single character (i.e. "2"), and then for
the next read() to get "00 OK\r\n". You need to do buffering inside
your application which keeps doing read() until you find the "\r\n" (and
stops there, even if the read() returned more data beyond that).

 

[Navkirat Singh]

There's nothing that guarantees that a single write won't be split into
multiple packets, nor that multiple writes won't be coalesced into a
single packet. Or any combination of splitting and coalescing that the
kernel feels like.

That being said, for any sane implementation, what John says is true
most of the time, and is indeed a reasonable optimization. Just don't
depend on it being true all the time. The most common case where it
will not be true is if you're trying to send a large amount of data and
exceed the MTU of the network. Then you are certain to get
fragmentation.

Depending on what you're doing, this can be a point of networking
trivia, or it can be the difference between your application working and
not working. If you're just streaming data from one place to another,
you don't have to worry about it. But, if you're doing some sort of
interactive protocol where you send a command, wait for a respond, send
another command, etc, you really do need to be aware of how this works.

Let's say you're writing something like a HTTP client. You send a bunch
of headers, then expect to get back something like "200 OK\r\n", or "404
Not Found\r\n". You can't just do a read() on the socket and then
examine the string to see if the first three characters are "200" or
"404", because (regardless of how the server sent them), it is legal for
your read() to return just a single character (i.e. "2"), and then for
the next read() to get "00 OK\r\n". You need to do buffering inside
your application which keeps doing read() until you find the "\r\n" (and
stops there, even if the read() returned more data beyond that).

Thanks John, Roy. I really appreciate your valuable input. I have made a note of what you have said and will implement keeping the same in mind : )

Nav