3 ms·

How does this compare to Caddy?

ciprian_craciun 4y ago
[Kawipiko's author here] Caddy, and Nginx, Apache, etc., are general purpose web servers that either serve content directly from the file-system or reverse proxy requests to other backends. Meanwhile Kawipiko has only one purpose: serve resources from an embedded key-value database, namely the venerable CDB <https://cr.yp.to/cdb.html https://cr.yp.to/cdb.html>. 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.
- cosmotic 4y ago
  I guess I'm curious how all the theoretical benefits pan out in the end and if the benefit is worth the separate project.
  - ciprian_craciun 4y ago
    For example in one production deployment, Kawipiko is used to serve a snapshot of a former dynamic web-site that is now conserved. That snapshot has around 600K files and would eat around 12 GiB of storage; but with Kawipiko all that is bundled to just one single file of ~3.5 GiB that can easily be moved around and deployed essentially anywhere.
francislavoie 4y ago
[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.

[Kawipiko's author here] Caddy, and Nginx, Apache, etc., are general purpose web servers that either serve content directly from the file-system or reverse proxy requests to other backends. Meanwhile Kawipiko has only one purpose: serve resources from an embedded key-value database, namely the venerable CDB <https://cr.yp.to/cdb.html https://cr.yp.to/cdb.html>. 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.

cosmotic 4y ago
I guess I'm curious how all the theoretical benefits pan out in the end and if the benefit is worth the separate project.
- ciprian_craciun 4y ago
  For example in one production deployment, Kawipiko is used to serve a snapshot of a former dynamic web-site that is now conserved. That snapshot has around 600K files and would eat around 12 GiB of storage; but with Kawipiko all that is bundled to just one single file of ~3.5 GiB that can easily be moved around and deployed essentially anywhere.

francislavoie 4y ago

[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.