超高性能Socket服务器-实现细节
我已经完成了我的研究，我知道实现高性能套接字服务器的最佳方法通常如下:使用异步套接字操作(专门的SocketAsyncEventArgs/Operations以获得最佳性能)，在异步回调上，将请求推送到由线程池管理的处理队列。
我对这个处理模型的问题--要有最好的性能：
1)套接字的End操作应该在什么时候调用(例如EndAccept或EndReceive)？在对请求进行排队之前，是否应该在回调线程(IOCP)上调用它？或者在请求从队列中取出并得到处理时调用(工作线程)？
2)这个问题取决于#1的答案。下一个"Begin“操作应该在什么时候调用？我们应该在调用EndOperation之前调用它，还是应该在EndOperation之后立即调用它(在排队/处理请求之前)？
3)处理队列可以简单地作为.NET线程池吗？与推出自己的同步处理队列相比，使用.NET线程池有什么优点/缺点？
任何帮助都是非常感谢的。
回答 1
Stack Overflow用户
发布于 2011-10-15 05:43:39
1)在异步回调中，首先要做的是EndReceive。实际上，在调用EndReceive之前，您不能在回调中做太多其他事情，因为这就是给您提供接收到的数据的东西。请参阅Socket.EndReceive上的示例。
同样的事情也适用于EndAccept，因为它为您提供了将与之通信的套接字。
2) EndAccept后应尽快调用BeginAccept。否则，如果accept回调处理时间太长，则可能会丢失连接请求。当然，如果您的accept回调花费了很长时间来做任何事情，那么您就做错了。同样，同样的事情也适用于BeginReceive：在EndRead之后尽快调用它，以避免丢失数据。或者，如果您的通信协议是请求/响应模型，在这种模型中，客户端在发送更多数据之前需要一个响应，您可以等到发送响应之后再调用BeginRead。
3)处理可以是.NET线程池，不过如果你打算使用它，你应该考虑使用任务并行库。使用TPL的优点是它非常“一发即忘”，或者可能是“一发即发，完成后就会回调”。使用TPL的缺点是您的应用程序更难知道哪些任务是挂起的。如果您创建了自己的同步处理队列，您将始终知道哪些作业处于挂起状态，并且有可能检查队列、取消作业等。如果您希望使用第三方编程语言完成这些操作，则最终将创建一个必须管理的任务集合，因为存在no way to get the the list of pending tasks。
但是，如果您不需要查看挂起的任务，那么TPL应该可以很好地工作。
这里的相关问题有一些很好的信息。
https://stackoverflow.com/questions/7773677
复制相似问题
腾讯云开发者
