3 ms·

I just figured any savings where savings can be made is a good thing, especially if there are zero downsides, plus it means very low CPU usage as it's literally

I just figured any savings where savings can be made is a good thing, especially if there are zero downsides, plus it means very low CPU usage as it's literally just pulling from RAM without any CPU usage. It also precaches gzipped and brotli'd versions of sensible files so that it can accept-encoding for a variety of browsers.

rofldang 3y ago
[flagged]
pvg 3y ago
Couldn't the extra memory copies end up being an actual downside? I.e. the sort of thing that inspired sendfile(2) usage in some servers?
- antihero 3y ago
  I’m not so sure, if you’re serving massive files this is not perhaps the option you want. If your SPA is so big you can’t handle a container that has its app code and assets in RAM perhaps it’s also too large. I see it as a pragmatic trade off between speed and RAM. Even free tier EC2 instance should have enough RAM to handle pretty much any SPA even if the text content is duplicated (compressed) especially seeing as with a unikernel you have no RAM used up by Linux processes.
  - pvg 3y ago
    I think the argument is the same for files that fit in memory. This sort of thing is fairly well-trodden (if unsettled, to mix up the metaphors) ground, for yet another take there's varnish and Poul-Henning Kamp's strident writings about it.
    - ngrilly 3y ago
      For anyone else wanting to read about it: https://varnish-cache.org/docs/trunk/phk/notes.html https://varnish-cache.org/docs/trunk/phk/notes.html
traverseda 3y ago
Linux already caches files in ram, you're probably just doing something that your OS is already doing, but worse. If you're really concerned you can MMAP the file instead, and do a read every once in a while to keep it cached. There are a lot of cases where this kind of functionality could cause big problems, and very few where it has more than a marginal improvement over what your OS is already doing. Just read the file every once in a while to keep it in memory cache.
- antihero 3y ago
  This doesn’t necessarily have to run on Linux.

rofldang 3y ago

[flagged]

pvg 3y ago

Couldn't the extra memory copies end up being an actual downside? I.e. the sort of thing that inspired sendfile(2) usage in some servers?

antihero 3y ago
I’m not so sure, if you’re serving massive files this is not perhaps the option you want. If your SPA is so big you can’t handle a container that has its app code and assets in RAM perhaps it’s also too large. I see it as a pragmatic trade off between speed and RAM. Even free tier EC2 instance should have enough RAM to handle pretty much any SPA even if the text content is duplicated (compressed) especially seeing as with a unikernel you have no RAM used up by Linux processes.
- pvg 3y ago
  I think the argument is the same for files that fit in memory. This sort of thing is fairly well-trodden (if unsettled, to mix up the metaphors) ground, for yet another take there's varnish and Poul-Henning Kamp's strident writings about it.
  - ngrilly 3y ago
    For anyone else wanting to read about it: https://varnish-cache.org/docs/trunk/phk/notes.html https://varnish-cache.org/docs/trunk/phk/notes.html

traverseda 3y ago

Linux already caches files in ram, you're probably just doing something that your OS is already doing, but worse. If you're really concerned you can MMAP the file instead, and do a read every once in a while to keep it cached. There are a lot of cases where this kind of functionality could cause big problems, and very few where it has more than a marginal improvement over what your OS is already doing. Just read the file every once in a while to keep it in memory cache.

antihero 3y ago
This doesn’t necessarily have to run on Linux.