In fact, there is one ticket open on `fasthttp` about HTTP/2 support, however (as I've also commented on this issue), I don't think that's the way to go for the intended use-cases: <https://github.com/valyala/fasthttp/issues/144>
My current opinion is this: HTTP/2, and especially HTTP/3, are mainly meant for CDN's and highly performant HTTP load-balancers (like HAProxy), meanwhile HTTP/1.1 is the best solution for the backend.
The focus is on the performance, yet "kawipiko is at least on-par with NGinx". NGinx does require file open-read-close, but with the OS cache, I think the cost is very small. And Nginx is much more compliant, battle-tested and versatile. For example it can send the right pre-compressed file that suits the Accept-encoding header of the request, something that kawipiko does not support.
So I guess the selling feature is that the web server is just a single static executable. It's probably useful in some cases, but I can't imagine them, even for a doc server embedded in hardware.
On the other hand with Kawipiko there aren't many configuration knobs; it is already tuned for a single particular use-case: serving static content for websites (with small resources).
Also, a particular use-case where Kawipiko can shine over NGinx, is for a website with lots of small resources (as with my Leaflet tiles example). NGinx can't decide where those resources are placed on disk, thus the OS file-system caching and read-ahead can't help too much here. Meanwhile with Kawipiko, where everything is bundled together, it receives a lot of help from the OS in this regard.
As with regard to the "battle-tested and versatile", Kawipiko uses <https://github.com/valyala/fasthttp> as its HTTP engine, which itself is used in quite a lot of Go-based products, thus one could state that it's "battle-tested enough". :)
With regard the "even for a doc server embedded in hardware", why don't you think Kawipiko is a good fit in that case? (In fact this was one of its main use-cases.)
In fact, benchmarking it over wireless + Wireguard with 128 concurrent connections yielded around ~2K requests/second and the overall CPU stayed under 1% (for the server process). (Granted the main issue was latency, but the average was well under 25 ms.)
Thus for a portfolio site that you take with you at conferences / meetings it works very well.
On the other hand, for the intended use-cases (mostly static contents behind a CDN), a 60 minute caching period is still acceptable and thus the default.
this sound like lots of headache as it doesn't support `Accept-Encoding` header.
* bundle two separate archives, one with compression and one without (provided it fits in 4 GiB), and use something like HAProxy to choose between the two backends based on the Accept-Encoding header;
* (most likely) use a CDN service (like CloudFlare) that would do caching and re-encoding based on what the actual client supports;
* choose to just support compressed contents, based on the next observation;
Any "modern enough browser" (say since 2018, and here I include things like Netsurf), does support even Brotli compression, let alone gzip. Indeed Lynx (the console browser) doesn’t support Brotli, but it still does support gzip.
Thus, for all "real clients" out there, serving straight compressed contents is not an issue, thus one could choose to just ignore the Accept-Encoding header.
That is cool! I use CDB in some projects and love it.
That "somewhere" can either be another cloud service dedicated to static sites such as Netlify, GitHub Pages, CloudFlare Pages; a general purpose storage service such as AWS S3; a "serverless" service running on something like AWS Lambda or Fly.io; or even a self-hosted Linux server (running on hardware or as a VM in a IaaS provider such as Linode).
Kawipiko tries to solve the last two scenarios, when one wants to serve the content from a self-hosted VM.
But of course, do your own benchmarking, for your own usecase, and see which one works best for your needs. IMO benchmarking webservers is usually misleading because everyone has slightly different needs and since webservers are designed to be configurable.
All that said, with the upcoming release, Caddy will support being built with an embedded filesystem with https://pkg.go.dev/embed so your static content can ship with your Caddy binary and get served from memory. We haven't done much testing to see how fast this is in general, but it should be pretty fast in theory.
On the other hand, Go's `net/http` uses quite a bit of heap allocation, thus it will never beat `fasthttp` in terms of raw performance.
That being said, the numbers are pointless... From what I remember Go's `net/http` is able to serve a few tens of thousands of requests per second, thus it won't be the main bottleneck.
While general purpose web servers use open-(read+send)*-close syscalls (and other tricks such as `sendfile`) for each request, Kawipiko uses a single memory-mapped database for all requests, thus all the I/O is mediated (and cached) by the OS.
Thus, one could say that Kawipiko serves a well defined niche, heavily optimizing for that particular use-case, meanwhile the other servers although can do lots of other things, they can't be optimized for any of those use-cases.
