FreeBSD accept_filter 在现代世界中实际上提高了多少性能?

FreeBSD accept_filter 在现代世界中实际上提高了多少性能?

我最近了解了 FreeBSD 的accept_filter套接字选项这可以允许工作进程避免上下文切换,例如通过等待,直到收到完整的 HTTP 请求accf_http

这是一个放置在套接字上的过滤器,它将使用 accept() 接收传入的 HTTP 连接。

它会阻止应用程序通过 accept() 接收连接的描述符,直到内核缓冲了完整的 HTTP/1.0 或 HTTP/1.1 HEAD 或 GET 请求。

如果收到除 HTTP/1.0 或 HTTP/1.1 HEAD 或 GET 请求之外的其他内容,内核将允许应用程序通过 accept() 接收连接描述符。

accf_http 的实用性使得服务器在执行请求的初始解析之前无需多次切换上下文。通过保持预分叉服务器(如 Apache)中的活动进程较少,并减少需要由基于 select()、poll() 或 kevent() 的服务器等接口管理的文件描述符集的大小,这有效地减少了处理传入请求所需的 CPU 利用率。

我的直觉是,在现代硬件上,通过高速连接(有线调制解调器/DSL 速度或更高)向客户端提供流量,这可能是一个微优化。鉴于它accf_http不能用于 HTTPS 或 HTTP/2 连接,而accf_data只是等待第一个字节,我看不出这有什么好处。也许他们会节省一两次上下文切换?

有没有最近的(可能是 2015 年之后?)基准测试来了解 FreeBSDaccept_filter实际上可以将性能或吞吐量/并发性提高多少?

相关内容