4 ms·

[Caddy maintainer here] It's probably faster, because it focuses on only serving static content. Caddy is designed to be general purpose. Caddy uses net/http (G

[Caddy maintainer here] It's probably faster, because it focuses on only serving static content. Caddy is designed to be general purpose. Caddy uses net/http (Go's stdlib implementation), Kawipiko uses "fasthttp" which is a separate library that should be more performant for simple uses. 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 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.

ciprian_craciun 4y ago
The main problem with Go when it comes to raw performance is heap memory allocation. `fasthttp` (and the rest of Kawipiko's code on the main serving path) does all it can to avoid any sort of memory allocation (or "heap escape"). 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.
- avinassh 4y ago
  > The main problem with Go when it comes to raw performance is heap memory allocation. `fasthttp` (and the rest of Kawipiko's code on the main serving path) does all it can to avoid any sort of memory allocation (or "heap escape"). How do they manage to do that? One aspect I can think of is, trying not to use pointers and data structures with dynamic size
  - ciprian_craciun 4y ago
    > How do they manage to do that? One aspect I can think of is, trying not to use pointers and data structures with dynamic size. On the contrary, they do use lot's of pointers (actually byte slices) and structures with dynamic size, however they rely heavily on buffer pooling and carefully appending to such byte buffers instead of allocating new ones.

ciprian_craciun 4y ago

The main problem with Go when it comes to raw performance is heap memory allocation. `fasthttp` (and the rest of Kawipiko's code on the main serving path) does all it can to avoid any sort of memory allocation (or "heap escape"). 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.

avinassh 4y ago
> The main problem with Go when it comes to raw performance is heap memory allocation. `fasthttp` (and the rest of Kawipiko's code on the main serving path) does all it can to avoid any sort of memory allocation (or "heap escape"). How do they manage to do that? One aspect I can think of is, trying not to use pointers and data structures with dynamic size
- ciprian_craciun 4y ago
  > How do they manage to do that? One aspect I can think of is, trying not to use pointers and data structures with dynamic size. On the contrary, they do use lot's of pointers (actually byte slices) and structures with dynamic size, however they rely heavily on buffer pooling and carefully appending to such byte buffers instead of allocating new ones.