Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

FWIW, enabling gzip/zstd compression in your HTTP server could help.


A single core machine already overloaded is going to get even worse introducing the cpu overhead of gzipping response bodies (assuming it’s cpu bound and not IO bound)

Cache control headers will help with return traffic

More cpu cores

If using nginx ensure sendfile is enabled and workers are set to auto or tuned for your setup

Check ulimit file handle limits

Offload static assets to cdn

Since it’s a static html site, you could even host on s3, netlify, etc


It's a static file. You need to compress it only once, not for every response.



Could even host on github pages with a cname.


> A single core machine already overloaded is going to get even worse introducing the cpu overhead of gzipping response bodies (assuming it’s cpu bound and not IO bound)

Unless your CPU is burning due to additional system calls being made.


Only with something like mod_asis (https://httpd.apache.org/docs/2.4/mod/mod_asis.html) to serve already compressed content. Actually running zlib on every request will only make it worse.


> Actually running zlib on every request will only make it worse.

I wouldn't be so sure, given that without zlib HTTP connections take longer, thereby increasing the size of the wait queue and the number of parallel connections.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: