c# - 使用 SocketAsyncEventArgs 每秒接收 20 次

Question

TCP 服务器是使用 SocketAsyncEventArgs 开发的，它是作为 Windows 服务的异步方法。我在 Main 的开头有这两行代码:

ThreadPool.SetMaxThreads(15000, 30000);
ThreadPool.SetMinThreads(10000, 20000);

并且都返回 true(记录返回值)。现在有 2000 到 3000 个客户端开始向该服务器发送消息，它开始接受连接(我计算了连接数，正如预期的那样——有一个连接池)。服务器进程的线程数将增长到 ~2050 到 ~3050。到目前为止一切顺利!

现在有一个 Received 方法，它将在 ReceiveAsync 返回 true 后或由 SocketAsyncEventArgs 的 Completed 事件调用。

问题从这里开始:无论有多少客户端连接以及它们发送了多少消息，Received 将在一秒钟内最多被调用 20 次!随着客户数量的增加，这个数字 (20) 下降到大约 10。

环境:在同一台机器上模拟 TCP 服务器和客户端。我在两台机器上测试了代码，一台有 2 核 CPU 和 4GB RAM，另一台有 8 核 CPU 和 12GB RAM。没有数据丢失(还)，有时我在每次接收操作中收到超过 1 条消息。没关系。但是如何才能增加接收操作的数量呢？

关于实现的附加说明:代码很大，包含许多不同的逻辑。总体描述是:我有一个 SocketAsyncEventArgs 用于接受新连接。它很好用。现在，对于每个新接受的连接，我创建一个新的 SocketAsyncEventArgs 来接收数据。我将这个(为接收创建的 SocketAsyncEventArgs)放在池中。它不会被重用，但它的 UserToken 被用于跟踪连接；例如，那些断开连接或 7 分钟内未发送任何数据的连接将被关闭和处置(SocketAsyncEventArgs 的 AcceptSocket 将被关闭(两者)、关闭和处置，SocketAsyncEventArgs 对象本身也是如此)。这是一个执行这些任务的 Sudo 类，但删除了所有其他逻辑、日志记录和错误检查以及任何其他内容以使其简单明了(也许这样更容易发现有问题的代码):

class Sudo
{
    Socket _listener;
    int _port = 8797;

    public Sudo()
    {
        var ipEndPoint = new IPEndPoint(IPAddress.Any, _port);
        _listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        _listener.Bind(ipEndPoint);

        _listener.Listen(100);

        Accept(null);
    }

    void Accept(SocketAsyncEventArgs acceptEventArg)
    {
        if (acceptEventArg == null)
        {
            acceptEventArg = new SocketAsyncEventArgs();
            acceptEventArg.Completed += AcceptCompleted;
        }
        else acceptEventArg.AcceptSocket = null;

        bool willRaiseEvent = _listener.AcceptAsync(acceptEventArg); ;

        if (!willRaiseEvent) Accepted(acceptEventArg);
    }

    void AcceptCompleted(object sender, SocketAsyncEventArgs e)
    {
        Accepted(e);
    }

    void Accepted(SocketAsyncEventArgs e)
    {
        var acceptSocket = e.AcceptSocket;
        var readEventArgs = CreateArg(acceptSocket);

        var willRaiseEvent = acceptSocket.ReceiveAsync(readEventArgs);

        Accept(e);

        if (!willRaiseEvent) Received(readEventArgs);
    }

    SocketAsyncEventArgs CreateArg(Socket acceptSocket)
    {
        var arg = new SocketAsyncEventArgs();
        arg.Completed += IOCompleted;

        var buffer = new byte[64 * 1024];
        arg.SetBuffer(buffer, 0, buffer.Length);

        arg.AcceptSocket = acceptSocket;

        arg.SocketFlags = SocketFlags.None;

        return arg;
    }

    void IOCompleted(object sender, SocketAsyncEventArgs e)
    {
        switch (e.LastOperation)
        {
            case SocketAsyncOperation.Receive:
                Received(e);
                break;
            default: break;
        }
    }

    void Received(SocketAsyncEventArgs e)
    {
        if (e.SocketError != SocketError.Success || e.BytesTransferred == 0 || e.Buffer == null || e.Buffer.Length == 0)
        {
            // Kill(e);
            return;
        }

        var bytesList = new List<byte>();
        for (var i = 0; i < e.BytesTransferred; i++) bytesList.Add(e.Buffer[i]);

        var bytes = bytesList.ToArray();

        Process(bytes);

        ReceiveRest(e);

        Perf.IncOp();
    }

    void ReceiveRest(SocketAsyncEventArgs e)
    {
        e.SocketFlags = SocketFlags.None;
        for (int i = 0; i < e.Buffer.Length; i++) e.Buffer[i] = 0;
        e.SetBuffer(0, e.Buffer.Length);

        var willRaiseEvent = e.AcceptSocket.ReceiveAsync(e);
        if (!willRaiseEvent) Received(e);
    }

    void Process(byte[] bytes) { }
}

Answer 1

它变慢的原因是因为这些线程中的每一个都需要上下文切换，而这是一个相对昂贵的操作。您添加的线程越多，您的 CPU 的百分比就越大，只是花在上下文切换上，而不是花在实际代码上。

您以一种相当奇怪的方式遇到了每个客户端一个线程的瓶颈。服务器端异步的全部意义在于减少线程数量——每个客户端没有一个线程，但理想情况下系统中的每个逻辑处理器只有一个或两个线程。 p>

您发布的异步代码看起来不错，所以我只能猜测您的 Process 方法中有一些容易被忽略的非异步、阻塞 I/O，即数据库或文件访问。当 I/O 阻塞时，.NET 线程池会检测到这一点并自动启动一个新线程——它基本上在这里失去控制，Process 中的 I/O 成为瓶颈。

异步管道确实需要 100% 异步才能从中获得任何显着优势。 Half-in 会让您编写复杂的代码，其性能与简单的同步代码一样差。

如果您绝对不能使 Process 方法完全异步，您可能会伪装它。让事情在队列中等待，以供小型、有限大小的线程池处理。