Professional Web Applications Themes

blocking i/o vs. non-blocking i/o - UNIX Programming

Hi, I'm writing (in linux) a proxy application for rfb protocol (vnc), but i'm not satisfied with it's performance. I'm using blocking i/o and my app just read(...) from source and the write(...) to destination. The performance diference (over a 100mbits lan) between the client directly connected to the server and the client passing thru the proxy is very visible. Does non-blocking i/o solves my problem? Maybe the problem here is the unnecessary(?) wait in (blocking) write(...) function. thank you. obs. sorry about my poor english....

  1. #1

    Default blocking i/o vs. non-blocking i/o

    Hi,
    I'm writing (in linux) a proxy application for rfb protocol (vnc), but
    i'm not satisfied with it's performance. I'm using blocking i/o and
    my app just read(...) from source and the write(...) to destination.
    The performance diference (over a 100mbits lan) between the client
    directly connected to the server and the client passing thru the proxy
    is very visible. Does non-blocking i/o solves my problem? Maybe the
    problem here is the unnecessary(?) wait in (blocking) write(...)
    function.

    thank you.
    obs. sorry about my poor english.
    Andre Guest

  2. #2

    Default Re: blocking i/o vs. non-blocking i/o

    In article <google.com>,
    Andre Kelmanson <net> wrote: 

    I don't think switching to non-blocking is likely to help with performance.
    The waits in read() and write() will simply be replaced by waiting in
    select().

    Note that write() only blocks if you're writing much faster than the remote
    system can read, so that your local socket buffer fills up. If the socket
    buffer is not full, write() simply copies the data to the buffer and
    returns immediately.

    Using non-blocking I/O would allow you to keep calling read() while you
    wait for the send buffer to clear out. But you'll need to find someplace
    to keep all the data you're reading until you're able to write it.

    No matter what you do, your throughput is limited by how fast the receiving
    system can take in data. But that should also be the case when the client
    and server are talking directly to each other. If your proxy is impacting
    performance significantly, it's probably something else. Maybe the proxy
    is advertising a smaller receive window than the real server (try
    increasing SO_RCVBUF).

    --
    Barry Margolin, com
    Level(3), Woburn, MA
    *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
    Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
    Barry Guest

  3. #3

    Default Re: blocking i/o vs. non-blocking i/o


    "Andre Kelmanson" <net> wrote in message
    news:google.com...
     

    How do you do the reads exactly? You have two sockets, how do you decide
    which one to call 'read' on?

    DS


    David Guest

  4. #4

    Default Re: blocking i/o vs. non-blocking i/o

    On Fri, 10 Oct 2003 15:56:24 +0000, Barry Margolin wrote:
     
    >
    > I don't think switching to non-blocking is likely to help with performance.
    > The waits in read() and write() will simply be replaced by waiting in
    > select().[/ref]

    You replace blocking in _either_ read or write, with select/poll/etc.
    which emulates blocking in _both_.
    This can be very significant when one would block and the other wouldn't.
     

    This is a simplification of half of the story. It assumes you are using
    much less than the OS/ethernet/etc. buffer sizes almost all the time, and
    possibly for very short periods you get a burst of data.
    If however you have data moving close to the buffer size for a longer
    period, then _any_ delay is going to backup on the read and the write.
     

    Application memory is _much_ cheaper than kernel socket buffer memory.
     

    No, in this case, it's limited by how fast you receive the data from the
    client and how fast you can send the data to the server. Which is often
    very different.

    --
    James Antill -- org
    Need an efficient and powerful string library for C?
    http://www.and.org/vstr/

    James Guest

  5. #5

    Default Re: blocking i/o vs. non-blocking i/o

    On Fri, 10 Oct 2003 05:48:30 -0700, Andre Kelmanson wrote:
     

    Possibly, see...

    http://www.and.org/texts/network_io.html
    http://www.and.org/texts/network_io.html#doublemove

    ....the text at second link is specifically about the problem you _may_ be
    having, where you can lower the total IO to the minimum of the input or
    the output.

    Also, is there only ever a single connection through the proxy? If not
    then any blocking read or write on a single connection will be blocking
    all other connections. If this is the case then moving to non-blocking IO
    will pretty much be guaranteed to make things better.

    It's also possible that you've introduced some latency, either through
    the extra network connections or internal organization of your proxy code
    (for instance you may be dealing badly with large amounts of data).
    If converting to non-blocking IO doesn't seem to help you much, then you
    should try and qualify what is going wrong, Ie. is it sustained throughput
    that is lower, or is there significantly more latency? (I'd guess the
    later, but numbers talk...)

    --
    James Antill -- org
    Need an efficient and powerful string library for C?
    http://www.and.org/vstr/

    James Guest

Similar Threads

  1. non-blocking io
    By Ara.T.Howard in forum Ruby
    Replies: 2
    Last Post: December 12th, 07:04 PM
  2. Blocking a refer
    By user in forum PHP Development
    Replies: 3
    Last Post: November 10th, 05:29 PM
  3. Will Thread blocking in read() leads to process blocking?
    By Loic Domaigne in forum UNIX Programming
    Replies: 4
    Last Post: July 23rd, 12:36 PM
  4. Pop-Up Blocking
    By TL Willis in forum Windows Setup, Administration & Security
    Replies: 3
    Last Post: July 21st, 06:25 AM
  5. Blocking Refresh
    By Atrax in forum ASP Components
    Replies: 1
    Last Post: July 18th, 09:11 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139