Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>What do a benefit from changing from blocking to non-blocking sockets? </p> </blockquote> <p>Increased speed, availability, and throughput (from my experience). I had an IndySockets client that was getting about 15 requests per second and when I went directly to asynchronous sockets the throughput increased to about 90 requests per second (on the same machine). In a separate benchmark test on a server at a data-center with a 30 Mbit connection I was able to get more than 300 requests per second.</p> <blockquote> <p>Will I be able to detect client disconnects (non gracefully)?</p> </blockquote> <p>That's one thing I haven't had to try yet, since all of my code has been on the client side.</p> <blockquote> <p>What component suite has the best product? By best product I mean: fast, good support, good tools and easy to implement.</p> </blockquote> <p>You can build your own socket client in a couple of days and it can be very robust and fast... much faster than most of the stuff I've seen "off the shelf". Feel free to take a look at my asynchronous socket client: <a href="http://codesprout.blogspot.com/2011/04/asynchronous-http-client.html" rel="nofollow">http://codesprout.blogspot.com/2011/04/asynchronous-http-client.html</a></p> <p><strong>Update:</strong><br> (Per Mikey's comments)</p> <blockquote> <p>I'm asking you for a generic, technical explanation of how NBS increase throughput as opposed to a properly designed BS server.</p> </blockquote> <p>Let's take a high load server as an example: say your server is supposed to handle 1000 connections at any given time, with blocking sockets you would have to create 1000 threads and even if they're mostly idle, the CPU will still spend a lot of time context switching. As the number of clients increases you will have to increase the number of threads in order to keep up and the CPU will inevitably increase the context switching. For every connection you establish with a blocking socket, you will incur the overhead of spawning of a new thread and you eventually you will incur the overhead of cleaning up after the thread. Of course, the first thing that comes to mind is: why not use the ThreadPool, you can reuse the threads and reduce the overhead of creating/cleaning-up of threads. </p> <p>Here is how this is handled on Windows (hence the .NET connection): sure you could, but the first thing you'll notice with the .NET ThreadPool is that it has two types of threads and it's not a coincidence: user threads and I/O completion port threads. Asynchronous sockets use the IO completion ports which "allows a single thread to perform simultaneous I/O operations on different handles, or even simultaneous read and write operations on the same handle."(<a href="http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx" rel="nofollow">1</a>) The I/O completion port threads are specifically designed to handle I/O in a much more efficient way than you would ever be able to achieve if you used the user threads in ThreadPool, unless you <a href="http://int64.org/tag/io-completion-ports" rel="nofollow">wrote your own kernel-mode driver</a>.</p> <p>"The com­ple­tion port uses some spe­cial voodoo to make sure only a spe­cif­ic num­ber of threads can run at once — if one thread blocks in ker­nel-​mode, it will au­to­mat­i­cal­ly start up an­oth­er one."(<a href="http://int64.org/2009/05/13/high-performance-io-on-windows" rel="nofollow">2</a>)</p> <p>There are other advantages also: "in addition to the nonblocking advantage of the overlapped socket I/O, the other advantage is better performance because you save a buffer copy between the TCP stack buffer and the user buffer for each I/O call." (<a href="http://support.microsoft.com/kb/181611" rel="nofollow">3</a>)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload