This content has been discussed many times in cnblogs. I have read some information in the past two days and saw some simple performance indicators and discussed it with everyone.
Socket + Threads/ThreadPool
Approximate performance: less than 1500 connections.
Implementation: Accept a Socket and leave it to a thread to manage. It is relatively stupid, but it is also more effective. Because it is a synchronous method, it is very convenient to control. The more advanced thing is to hand it over to a thread pool for management. The thread pool is automatically hosted by the system, saving the time of overhead threads. For general small projects, this is completely sufficient and development is simple. But be aware that if several Sockets occupy threads in the thread pool for a long time and there are many other connections, it is easy to get a prompt saying that you do not have enough threads to use. Haha, it is a good idea to let Socket do less work and take up less time. Changing to a faster CPU is a good way. In addition, if there are some better third-party thread pool components, you can also choose to use them, such as SmartThreadPool.
Socket+Select
Approximate performance: Performance decreases after more than 1500 connections.
Implementation: Select is a very commonly used model. It is to poll one or more Sockets in the blocking function, and put the Socket to be processed into an IList. When the Select polling is completed, we will then process the Socket in this IList ourselves. For specific usage, please refer to MSDN. The efficiency of Select cannot be said to be high, because when there are many Sockets to be processed in the queue, processing the last few Sockets is equivalent to traversing all the previous Sockets, which is very uneconomical.
Socket+Asynchronous
Approximate performance: about 7500 client connections
Implementation: BeginXXXX, EndXXXX, we are all familiar with it. In the final analysis, asynchronous Socket still uses thread pool technology, using thread pool to handle asynchronous IO. This raises another question, what implementation method is used for .NET's thread pool? I have seen someone say before that .NET's thread pool is implemented using completion ports. I don't know if this is correct. There is no way to confirm it from the information I found (I hope a friend can tell me this). Asynchronous Socket is much more complicated than synchronous program processing flow, and the control of asynchronous callback functions is not as intuitive as the synchronous method. But one thing I think should be noted is that the callback function should be used lightly and should not handle too many transactions. The processing of the transferred data should be left to other threads for processing.
IOCP (completion port)
Approximate performance: about 20,000~50,000 client connections
. Implementation: There are some pseudo-IOCPs under .NET. You can search for them. I have not seen any open SOCKET examples implemented using these pseudo-IOCPs. The 20,000~50,000 client connections I am talking about refer to the situation of development under C++. In this case, the basic technologies that need to be used include memory pools, query algorithms, etc.
There is no information to check the maximum number of connections that pseudo-IOCP can achieve. If anyone knows, you can discuss it. In addition, many of the data mentioned above are excerpted from some information. I have not tried it myself. I am just bringing it out for discussion with everyone. I think that a high-performance server program may require technology that is not only what model to use, but also many details that need to be paid attention to, such as memory processing, what algorithm to use, etc. Of course, this is only in terms of software cost. There will definitely be investment in hardware.