我正在开发一个linux下的应用程序，需要支持大约250个连接，并通过100MB +大小范围内的TCP套接字传输大文件。目的是调整吞吐量而不是延迟。我希望始终保持饱和的2x1Gbit以太网连接。这些将是通道绑定。
预计应用程序将持续繁忙，并且只会尽快丢弃数据。连接将在大多数时间保持通用，因此与HTTP不同，它们不会经常被拆除。
我一直在寻找各种选项，例如epoll，sendfile api等高性能和aio（看起来太不成熟和风险恕我直言）。
我也一直在关注使用下面的epoll的提升asio api。我之前使用过它，但不是这样的高性能应用程序。
我有超过4个处理器核心可用，所以我可以使用它。
但是，我读到由于反应堆设计中的一些锁定，使用多线程的boost asio不是很好。这对我来说可能是一个问题吗？
如果我有很多可用的CPU核心，我应该创建尽可能多的线程或分叉进程并将它们设置为在每个处理器核心上运行吗？
如何锁定等我想要一些设计建议。我怀疑我的主要瓶颈是磁盘I / O但是仍然......我想要一个好的设计，以后再进行大量的返工。
有什么建议吗？
答案 0 :(得分：9)
答案 1 :(得分：2)
sendfile()绝对是您的选择。 epoll()不太可能特别有用 - 当您处理大型数字连接时，它主要有用。 250根本不是很大，所以普通的select()或poll()可能会很好。
答案 2 :(得分：1)
恕我直言，你的主要问题是磁盘I / O - 文件服务通常不受CPU限制，因此许多核心不一定会有太大帮助。如果您提供许多不同的文件，事情会变得更糟糕，因为您似乎暗示;在这一点上，从磁盘同时读取将导致你的主要痛苦。
我会尝试在内存中尽可能多地缓存数据并尝试提供这些数据以加快速度。
答案 3 :(得分：0)
做最简单的事情可能会起作用，因为听起来甚至可能没有您可以在代码中修复的性能问题。
每个客户端一个线程听起来不错，它使编程尽可能简单。理想情况下，根本不要编写自定义文件服务器，而是使用已存在的文件服务器 - http，rsync等。对于许多小文件，Rsync协议适用于支持流水线操作。
拥有250个线程确实没问题 - 实际上，1000也没关系。
根据文件是否适合ram，以及IO的速度，您可能会在网络上出现瓶颈。如果您的网络只有1-2Gbit /秒，那么您的存储似乎可能会在顺序IO上击败它，因此网络将成为瓶颈。