|
|
|
|
|
|
by yincong0822
238 days ago
|
|
|
That’s awesome — congrats on reaching the release candidate stage!
I’m curious about the performance improvements you mentioned. Did you benchmark against other Go web servers like Caddy or fasthttp?
Also really like that you’ve made automatic TLS the default — that’s one of those “quality of life” features that make a huge difference for users. I’m working on an open-source project myself (AI-focused), and I’ve been exploring efficient ways to serve streaming responses — so I’d love to hear more about how your server handles concurrency or large responses. |
|
|
> Did you benchmark against other Go web servers like Caddy or fasthttp?
I have already benchmarked Ferron against Caddy! :)
> so I’d love to hear more about how your server handles concurrency or large responses.
Under the hood, Ferron uses Monoio asynchronous runtime.
From Monoio's GitHub repository (https://github.com/bytedance/monoio):
> Moreover, Monoio is designed with a thread-per-core model in mind. Users do not need to worry about tasks being Send or Sync, as thread local storage can be used safely. In other words, the data does not escape the thread on await points, unlike on work-stealing runtimes such as Tokio. > For example, if we were to write a load balancer like NGINX, we would write it in a thread-per-core way. The thread local data does not need to be shared between threads, so the Sync and Send do not need to be implemented in the first place.
Ferron uses an event-driven concurrency model (provided by Monoio), with multiple threads being spread across CPU cores.