Socket performance

Discussion in 'Python' started by Navkirat Singh, Jul 24, 2010.

  1. 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
     
    Navkirat Singh, Jul 24, 2010
    #1
    1. Advertising

  2. In message
    <>, Navkirat Singh wrote:

    > 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?

    --
    Lawrence
    trying not to say “performant†:)
     
    Lawrence D'Oliveiro, Jul 25, 2010
    #2
    1. Advertising

  3. On 25-Jul-2010, at 6:45 AM, Lawrence D'Oliveiro wrote:

    > In message
    > <>, Navkirat Singh wrote:
    >
    >> 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?
    >
    > --
    > Lawrence
    > trying not to say “performant” :)
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    I agree with you, it was just for the sake of knowledge. Its always good to have a map right?
     
    Navkirat Singh, Jul 25, 2010
    #3
  4. Navkirat Singh

    John Nagle Guest

    On 7/23/2010 5:06 PM, Navkirat Singh wrote:
    > 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
     
    John Nagle, Jul 25, 2010
    #4
  5. Navkirat Singh

    Roy Smith Guest

    In article <4c4bd0b1$0$1624$>,
    John Nagle <> wrote:

    > 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).
     
    Roy Smith, Jul 25, 2010
    #5
  6. On 25-Jul-2010, at 5:52 PM, Roy Smith wrote:

    > In article <4c4bd0b1$0$1624$>,
    > John Nagle <> wrote:
    >
    >> 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).
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    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
     
    Navkirat Singh, Jul 25, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Laszlo Nagy
    Replies:
    1
    Views:
    5,019
    Mark Wooding
    Jan 27, 2009
  2. Jean-Paul Calderone
    Replies:
    0
    Views:
    1,014
    Jean-Paul Calderone
    Jan 27, 2009
  3. Laszlo Nagy
    Replies:
    0
    Views:
    584
    Laszlo Nagy
    Feb 1, 2009
  4. Steve Holden
    Replies:
    0
    Views:
    702
    Steve Holden
    Feb 1, 2009
  5. Steve Holden
    Replies:
    1
    Views:
    746
Loading...

Share This Page