# How I improved Ferron 3 static file serving performance

**URL:** <https://discuss.ferron.sh/t/how-i-improved-ferron-3-static-file-serving-performance/12>\
**Category:** Core Development & Architecture\
**Created:** [September 3, 2026, 7:13am UTC](https://discuss.ferron.sh/t/how-i-improved-ferron-3-static-file-serving-performance/12 "2026-09-03T07:13:12Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![dorianniemiec](https://discuss.ferron.sh/user_avatar/discuss.ferron.sh/dorianniemiec/32/14_2.png) [@dorianniemiec](https://discuss.ferron.sh/u/dorianniemiec)\
**Post date:** [September 3, 2026, 7:13am UTC](https://discuss.ferron.sh/t/how-i-improved-ferron-3-static-file-serving-performance/12/1 "2026-09-03T07:13:12Z")

</div>

I was thinking of improving static file serving performance of Ferron 3 to be more in par with NGINX, and searching for performance optimizations.

I used `strace` logs to investigate why Ferron was slower than NGINX. It turns out that `zincio`, the asynchronous Rust runtime used by Ferron 3, made unnecessary `epoll_wait` system calls with zeroed timeout.

So I ended up modifying the I/O driver code of `zincio`, so it does `epoll_wait` with zeroed timeout (“flush”) only when there are I/O operations to poll. The “flush” exists to mitigate I/O starvation, but “flushing” even when there’s nothing to flush is just system call overhead.

I was so satisfied! 😄

So I measured the web server performance, and found out that on `localhost` benchmarks, it’s getting close to NGINX if using `epoll` (`io_uring` had lower throughput, that’s why I switched to `epoll` to be new default for Ferron 3).

I also measured performance over a local network to update the benchmarks page for Ferron 3 website variant with, and found that Ferron 3 has high throughput, that I was wondering if I’m 😮 …

 ![screenshot-2026-09-03_09-11-46](https://discuss.ferron.sh/uploads/default/original/1X/0e7e6f120df908eddd0ac175e45ea8c47ca1c505.png)