I recently learned about FreeBSD's accept_filter socket option which can allow a worker process to avoid context switching by, for example, waiting until a full HTTP request is received with accf_http:

This is a filter to be placed on a socket that will be using accept() to receive incoming HTTP connections.

It prevents the application from receiving the connected descriptor via accept() until either a full HTTP/1.0 or HTTP/1.1 HEAD or GET request has been buffered by the kernel.

If something other than a HTTP/1.0 or HTTP/1.1 HEAD or GET request is received the kernel will allow the application to receive the connection descriptor via accept().

The utility of accf_http is such that a server will not have to context switch several times before performing the initial parsing of the request. This effectively reduces the amount of required CPU utilization to handle incoming requests by keeping active processes in preforking servers such as Apache low and reducing the size of the file descriptor set that needs to be managed by interfaces such as select(), poll() or kevent() based servers.

My gut feeling is that on modern hardware, serving traffic to clients on high-speed connections (cable modem/DSL speeds or better) this may be a micro-optimization. Given that accf_http can't be used for HTTPS or HTTP/2 connections and accf_data just waits for the first byte, I don't see much advantage here. Maybe they'd save one or two context switches?

Are there any recent (post-2015 maybe?) benchmarks about how much FreeBSD's accept_filter can actually improve performance or throughput/concurrency?

  • 3
    1. accf_http was very useful with preforked server like Apache (waiting to full HTTP request happens inside kernel) and less so with nginx which is likely used in 2018. 2. If client sends request fast there will be no benefit from access filter. Most benchmarks can't emulate slow clients and will not show any difference (wich in theory should be very small if nginx is used).
    – citrin
    Oct 31, 2018 at 22:35
  • That's pretty much what I was thinking @citrin, that today clients send so fast there's not as much benefit provided by accept_filter
    – Josh
    Nov 1, 2018 at 3:36
  • 1
    Nowadays many clients still has slow connection, but nginx and (and some other web servers which use epoll/kqueue based event loop) can handle a lot of concurrent connections efficiently.
    – citrin
    Nov 2, 2018 at 4:22
  • 1
    Most of the search results I'm getting are from around 2011 or older? Doesn't appear to be too relevant today. I wonder if it helps in high load situations?
    – oxr463
    Jun 5, 2019 at 15:58


You must log in to answer this question.

Browse other questions tagged .