Speed ​​/ Performance Blocking features versus non-blocking winsock

Question

Is there any difference in the speed or performance of locking and non-blocking Winsock TCP Sockets? I could get differences in both sockets, but there is no detailed comparison of performance between the two types.

Answer 1

Because it’s not about speed. The write and read operations are just copying memory . All they do is copy data to the kernel and vice versa. That is, they actually do not send or receive anything .

The lock and non-lock function asks: do you prefer these operations to be locked until completed, or to return -1 and EAGAIN if they cannot be executed immediately? For example, you are reading from a socket, but there is nothing in the receive buffer. Do you prefer recv hang until something appears or -1 EAGAIN ?

Answer 2

In my experience, non-blocking winsock operations are a bit slower, but much more scalable. The fact is that you need to make two system calls plus some scheduling at the application level when you perform non-blocking I / O (with IOCP) and one system call if you use blocking I / O. If you have many concurrent connections, non-blocking I / O is much faster due to the more scalable architecture if it is well implemented.

If you need to transfer data from point to point with maximum throughput, use blocking I / O. If you need to handle many concurrent client connections, use non-blocking I / O. Do not expect too much from any of them.

In general, we are talking about a "server architecture controlled by events and flows", and then "lock against non-blocking". In any situation, there is no universal server architecture. It depends on the application.