Mat*_*att 3 linux performance multithreading boost
我正在开发一个linux下的应用程序,需要支持大约250个连接,并通过TCP套接字在100MB +大小范围内传输大文件.目的是调整吞吐量而不是延迟.我希望始终保持饱和的2x1Gbit以太网连接.这些将是渠道保税.
预计应用程序将持续繁忙,并且将尽快丢弃数据.连接将在大多数时间保持不变,因此与HTTP不同,它们不会经常被拆除.
我一直在寻找各种选项,如epoll,sendfile api等高性能和aio(看起来太不成熟和风险恕我直言).
我也一直在寻找使用下面的epoll的提升asio api.我之前使用过它,但不是像这样的高性能应用程序.
我有超过4个处理器核心可用,所以我可以利用它.
但是,我读到由于反应器设计中的一些锁定,使用多线程的boost asio不是很好.这对我来说可能是一个问题吗？
如果我有很多可用的CPU核心,我应该创建尽可能多的线程或分叉进程并将它们设置为在每个处理器核心上运行吗？
怎么样锁定等我想要一些设计建议.我怀疑我的主要瓶颈是磁盘I/O但是仍然......我想要一个好的设计,以后再进行大量的返工.
有什么建议？
我正在开发一个linux下的应用程序,需要支持大约250个连接,并通过TCP套接字在100MB +大小范围内传输大文件.目的是调整吞吐量而不是延迟.我希望始终保持饱和的2x1Gbit以太网连接.这些将是渠道保税.
磁盘IO通常比网络慢.250个客户端对现代CPU来说毫无用处.
大文件的大小并不重要.真正的问题是数据的总量是否适合RAM - 并且可以扩展RAM以使数据适合它.如果数据适合RAM,那么不要打扰过度优化:哑单线程服务器sendfile()就可以了.
应考虑使用SSD进行存储,尤其是在优先读取数据时.
预计应用程序将持续繁忙,并且将尽快丢弃数据.连接将在大多数时间保持不变,因此与HTTP不同,它们不会经常被拆除.
"尽可能快"是一场灾难.我负责至少一个这样的多线程灾难,由于它导致的磁盘数量,它无法扩展.
通常,您可能希望每个存储器具有很少(例如4个)磁盘读取线程,这些线程将调用read()或sendfile()非常大的块,以便OS有机会优化IO.由于人们希望乐观地认为某些数据可以并行地从OS的IO缓存中提供,因此很少需要线程.
别忘了还设置大套接字发送缓冲区.在您的情况下,轮询插槽的可写性也是有意义的:如果客户端无法以您可以读取/发送的速度接收,则读取没有意义.服务器上的网络通道可能很胖,但客户端NIC /磁盘不是这样.
我一直在寻找各种选项,如epoll,sendfile api等高性能和aio(看起来太不成熟和风险恕我直言).
现在几乎所有FTP服务器都使用sendfile().Oracle使用AIO和Linux是他们的主要平台.
我也一直在寻找使用下面的epoll的提升asio api.我之前使用过它,但不是像这样的高性能应用程序.
IIRC仅适用于插座.IMO任何便于处理插座的实用程序都很好.
我有超过4个处理器核心可用,所以我可以利用它.
NIC加速TCP,磁盘IO主要由控制器本身完成.理想情况下,您的应用程序将处于空闲状态,等待磁盘IO.
但是,我读到由于反应器设计中的一些锁定,使用多线程的boost asio不是很好.这对我来说可能是一个问题吗？
检查libevent作为替代方案.您可能只需要的有限数量的线程sendfile().并且数量应该是有限的,否则你会用磁盘搜索来消除吞吐量.
如果我有很多可用的CPU核心,我应该创建尽可能多的线程或分叉进程并将它们设置为在每个处理器核心上运行吗？
不是.磁盘受搜寻影响最大.(我是否重复了足够的时间？)如果您有许多自主读取线程,您将失去控制发送到磁盘的IO的可能性.
考虑最糟糕的情况.所有read()s必须转到磁盘==更多线程,更多磁盘搜索.
Consider the best case. All read()s are served from the cache == no IO at all. Then you are working at speed of the RAM and probably do not need threads at all (RAM is faster than network).
What about locking etc. I'd like some design suggestions. I suspect my main bottleneck is going to be Disk I/O but nonetheless...
That is a question with very very long answer which isn't going to fit here (nor I have the time to write). And it also depends largely how much data you are going to serve, what kind of storage you are using and how you access the storage.
If we take SSD as a storage, then any dumb design (like starting a thread for every client) would work fine. If you have real spinning media in the back-end, then you have to slice and queue the IO requests from clients, trying to avoid starving clients on one side and on another side schedule IO in a way to cause least possible amount of seeks.
我个人本想开始使用简单的单线程设计,在主循环中使用poll()(或boost.asio或libevent).如果数据被缓存,则无法启动新线程.如果必须从磁盘中提取数据,单线程将确保我避免搜索.使用读取数据填充套接字缓冲区并更改等待POLLOUT模式以了解客户端何时使用了数据并准备好接收下一个块.这意味着我在主循环中至少有三种类型的套接字:监听套接字,客户端套接字我正在等待请求,客户端套接字我正在等待再次变为可写.
我想要一个好的设计,以后要做太多的返工.
啊...甜蜜的梦......