71–80 of 100 posts
Maybe just write an nginx config generator instead?
It's also interesting that the actual config looks quite a lot like nginx config.
Looking at the graphs, I would recommend it would have been better to market it as "just as performant as nginx and htproxy" instead of "faster than all ...". While highlighting the simplicity as the added benefit above those all.
I did the reverse proxy benchmarks for NGINX, when someone opened a GitHub issue about missing NGINX benchmarks, and asked about benchmark comparisons. It turned out that yeah, Ferron is close to NGINX's reverse proxy performance.
> Any feedback is welcome! Read https://www.joelonsoftware.com/2006/12/09/simplicity/ and ask yourself if you are truly solving anyone's problem or if you are just looking for a way to rationalize the amount of time you are spending on a hobby.
Earlier quoted context omitted.
Wow, what a harsh comment. You make it sound like we should squeeze any form of efficiency out of people or you're wasting time
> like we should squeeze any form of efficiency The complete opposite. It's OP that's trying to "optimize the web server for reverse proxying and static file serving", when what we have out there is more than enough . > or you're wasting time "Wasting time" is not a problem. If OP is doing working on things because it brings them pleasure and they are hoping to learn from it, more power for them. What bugs me about t…
I have optimized it, so it would be faster than the original server I have been working on.
> (...) give some warning like this might be interesting to you but it's not solving any real pain point. Keep that in mind when deciding if work on this will be worthwhile.
If you feel the project isn't solving a real pain point for you, you don't have to use it! I was showcasing my web server to interested people on Hacker News.
Great to see! Would love to try it, but I depend on graceful updates of configuration (i.e. adding and removing backends primarily). I can't find anything about that. Is it supported, either through updating configs or through API?
I was previously waiting for River https://github.com/memorysafety/river/ to take off, it's built on top of previously open-sourced library by Cloudflare for revese-proxying, but just like many other "grant-based" projects it just died when funding stopped. I really like the spirit and simplicity of Ferron, will try it out when I have a chance. Been waiting for gradually throw out nginx for a while now, nothing click…
I wrote my own web server from scratch last year the exact same reasons: starting from scratch with Apache and NGINX is too painful for my needs. Here are my learnings: * TLS (HTTPS) can be easily enabled by default, but it requires certificates. This requires a learning curve for the application developer but can be automated away from the user. * The TLS certs will not be trusted by default until they are added to…
> TLS (HTTPS) can be easily enabled by default, but it requires certificates. This requires a learning curve for the application developer but can be automated away from the user.
Yeah, these certificates can be obtained from Let's Encrypt automatically.
> Everything executes faster when WebSockets are preferred over HTTP. An HTTP server is not required to run a WebSocket server allowing them to run in parallel. If the server is listening for the WebSocket handshake message and determines the connection to instead be HTTP it can allow both WebSocket and HTTP support from the same port.
Oh, seems like an interesting observation!
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…
> 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.
Hey! Sorry, I didn't get the chance to test it yet (like I promised when you launched), but can you say more about the rewrite? The title made me think you're porting it from Rust to another language :-).
Hey really cool. Am proficient in Rust if you need any help.