【问题标题】:C# begin*() method vs threadpool for a serverC# begin*() 方法与服务器的线程池
【发布时间】:2009-02-19 19:31:32
【问题描述】:

用C#制作一个可伸缩的多用户服务器,这两种服务器哪一种效率更高?您可以看到使用 begin* 方法(如 beginaccept、beginsend)here 和线程池实现 here 的异步服务器示例。

我知道线程池是什么以及它是如何工作的,所以我非常了解该实现是如何工作的。但是异步服务器呢?这会为每个发送、接收和连接事件生成一个线程吗?与线程池相比,它的效率如何?

我所说的效率只是指速度和内存使用的总体平衡。

编辑:

有人建议我使用 begin() 方法,但是当它们产生一个新线程来处理发送、接收或连接事件时,它们不会产生开销吗?还是他们最终使用某种内部线程池?如果没有,有没有办法让它使用线程池,或者我应该滚动我自己的异步套接字服务器?

【问题讨论】:

    标签: c# networking sockets


    【解决方案1】:

    TcpServer 实现会更好,因为它将利用 I/O 完成端口来执行异步工作,而线程池实现通常需要烧掉一个线程来等待连接被接受。

    一般来说,在文件、数据库、套接字(对它们具有底层非托管实现的事物)等事物上使用异步方法,因为它们将利用 I/O 完成端口进行工作,这通常比移动代码到线程池。但是,这会增加代码的复杂性,因此您必须考虑到这一点。

    【讨论】:

    • 难道它最终不会触发一个线程来实际执行异步工作吗?从中创建/销毁线程不会比线程池产生更多开销吗?
    【解决方案2】:

    如果您所说的可扩展性是指真正的大量连接,那么除了使用线程池之外,您还应该考虑许多其他方面。

    1) 如果您使用的是 .NET3.5,请考虑使用 SocketAsyncEventArgs 而不是 BeginXXX/EndXXX。该方法在MSDN Magazine 中进行了描述。这些允许更有效地调度和处理底层异步 i/o。

    2) 考虑您的memory usage very carefully。为异步 i/o 分配的 Byte[] 缓冲区被固定,迫使 GC 在压缩阶段绕过它们,这反过来可能导致碎片和负载不足的 OutOfMemoryExceptions。此外,您还考虑了异步 i/o 的较低级别的本机问题,例如非分页池中的可用内存。

    一些可用的技术是对所有待处理的接收使用单个共享的零字节缓冲区,并将池缓冲区(来自未压缩的内存 - LOH 或本机堆)用于实际传输数据的 I/O。

    【讨论】:

      【解决方案3】:

      更好的方法可能是使用 Jeffery Richter 的AsyncEnumerator。它是Wintellect PowerThreading Library 的一部分。您可以watch a video presentation 了解它在第 9 频道的工作原理。

      我在两个项目中使用它,它的好处是它允许您在许多请求之间共享线程池的有限资源,因此它不会为每个请求占用线程。两全其美。

      【讨论】:

        【解决方案4】:

        关于您的编辑,开始/结束调用通常不会产生线程。这几乎就是它们存在的原因。它们允许您以最有效的方式启动预期异步运行的操作。对于套接字,为什么要产生一个线程?当套接字上发生某些事情时,操作系统会通知您,因此也不需要线程在监听中徘徊。

        【讨论】:

          【解决方案5】:

          我更喜欢线程池,因为它可以帮助我管理我在系统级别约束的线程数。

          您需要澄清效率的含义:

          1. 内存更少
          2. 速度
          3. 响应时间/吞吐量

          你需要做出决定

          1. 使用该程序的平均用户数
          2. 硬件

          在进行设计选择之前首先确定基本要求。

          【讨论】:

          • 他的问题的关键词是“可扩展的多用户”。线程池无法扩展,因为线程池中可用的线程数量有限。
          猜你喜欢
          • 2010-12-18
          • 2013-11-15
          • 2018-09-03
          • 2011-07-14
          • 2010-11-29
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多