Caddy behaviour on higher-latency file systems

Hi, I’d like to ask how Caddy technically does syscalls (on Linux) and consequently about its behaviour on higher-latency systems, like network-mounted NFS or CephFS.

In, Cloudflare points out that in Nginx read() syscalls can be put on thread pools (using aio threads;) instead of happenning in the epoll() event loop, such that a single slow read() (e.g. blocking for 500 ms) cannot block other syscalls.

However, they also point out that Nginx cannot currently do it for open(), which is a pain point. Cloudflare submitted an Nginx patch for that to be done in threads as well, but it was never merged upstream (last email here).

How does Caddy fare here? How is file system access implemented?


1 Like

Hi @nh2, welcome to the Caddy community.

I’m not able to speak to the finer points of optimization here but I might be able to point you in the right direction to inspect how it’s handled yourself.

In the static file server module, Caddy relies pretty heavily on the Go standard library.

Files are opened in this code:

Later, after some manipulation they are served to the client as appropriate:

All the magic happens in the ServeHTTP function (caddy/staticfiles.go at 3af15c0725605162dc8dad0c6ab241e2dc4553c6 · caddyserver/caddy · GitHub).

The Golang os.Open functionality is here: os package - os -

Its implementation varies depending on the operating system.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.