4 ms·

The paper makes it clear they were evaluating languages based upon efficiency. The rust implementation was more efficient than the JS one. A CPU bound service

by Quenty 8y ago

The paper makes it clear they were evaluating languages based upon efficiency. The rust implementation was more efficient than the JS one. A CPU bound service of course is bottlenecked at the CPU, and this benefits from efficiency. At scale, it makes sense to replace this with Rust. Javascript did the job, but did not provide the same efficiency as Rust.

tyingq 8y ago
I'm not clear on why this is particularly CPU heavy, though: "the authorization service that determines whether a user is allowed to, say, publish a particular package"
- Filligree 8y ago
  Lots of users. Anything will be CPU-heavy if you give it enough work. Except the things that end up being memory-bound instead, but the NPM database isn't large enough for that.
  - Dylan16807 8y ago
    > Anything will be CPU-heavy if you give it enough work. Not in a relative sense. If authorization is 5% of the work, scaling it leaves it at 5% of the work, and it's never a bottleneck. Authorization was being a significant bottleneck, not a tiny percent, and that is somewhat surprising.
    - andy_ppp 8y ago
      Obviously authorisation will be a huge overhead compared to sendfile + nginx right? Am I misunderstanding what npm does?
      - Dylan16807 8y ago
        I mean, to use sendfile you need to open the file, and that does a permission check too...
        andy_ppp 8y ago
        No I'm talking about private NPM right. The perms on the file system are not equal to (or as costly as) the auth I need to have to access my private NPM repo.
  - yawaramin 8y ago
    Couldn't you implement the authorization logic in, say, Redis? Then the npm service is I/O-bound again, and everyone is doing the job they're optimized for.
    - Filligree 8y ago
      Authorization checks aren't that expensive. The overhead of using an external service might well make it take up more hardware overall.
- Thaxll 8y ago
  It's not clear either, it makes sens to use Rust for CPU heavy task, but a CRUD service that do authentication would be fine in Nodejs since every low level crypto are using C. So I'm not sure exatly what they mean, tbh the paper is very light on details.
  - nwlieb 8y ago
    Some CPU heavy operations like crypto are not put in a threadpool. While it may be running C code, it will block the main thread while executing. See https://github.com/nodejs/node/issues/678 https://github.com/nodejs/node/issues/678 Perhaps the new worker threads may alleviate this, but I'm not sure (it's still an experimental API).
- throwaway66666 8y ago
  My gut feeling is that the user keys are not random generated, but actually encrypted strings that contain the permission values. Decrypting them with modern encryption algorithms (like ChaCha) is pretty CPU intensive.
0815test 8y ago
"Javascript did the job", but not very well apparently. They specifically say that they "were able to forget about the Rust service because it caused so few operational issues". Add to that the increased CPU- and RAM-efficiency that generally comes with a rust implementation, and that rust rewrite looks like a no-brainer.

by Quenty 8y ago

tyingq 8y ago

I'm not clear on why this is particularly CPU heavy, though: "the authorization service that determines whether a user is allowed to, say, publish a particular package"

Filligree 8y ago
Lots of users. Anything will be CPU-heavy if you give it enough work. Except the things that end up being memory-bound instead, but the NPM database isn't large enough for that.
- Dylan16807 8y ago
  > Anything will be CPU-heavy if you give it enough work. Not in a relative sense. If authorization is 5% of the work, scaling it leaves it at 5% of the work, and it's never a bottleneck. Authorization was being a significant bottleneck, not a tiny percent, and that is somewhat surprising.
  - andy_ppp 8y ago
    Obviously authorisation will be a huge overhead compared to sendfile + nginx right? Am I misunderstanding what npm does?
    - Dylan16807 8y ago
      I mean, to use sendfile you need to open the file, and that does a permission check too...
      - andy_ppp 8y ago
        No I'm talking about private NPM right. The perms on the file system are not equal to (or as costly as) the auth I need to have to access my private NPM repo.
- yawaramin 8y ago
  Couldn't you implement the authorization logic in, say, Redis? Then the npm service is I/O-bound again, and everyone is doing the job they're optimized for.
  - Filligree 8y ago
    Authorization checks aren't that expensive. The overhead of using an external service might well make it take up more hardware overall.
Thaxll 8y ago
It's not clear either, it makes sens to use Rust for CPU heavy task, but a CRUD service that do authentication would be fine in Nodejs since every low level crypto are using C. So I'm not sure exatly what they mean, tbh the paper is very light on details.
- nwlieb 8y ago
  Some CPU heavy operations like crypto are not put in a threadpool. While it may be running C code, it will block the main thread while executing. See https://github.com/nodejs/node/issues/678 https://github.com/nodejs/node/issues/678 Perhaps the new worker threads may alleviate this, but I'm not sure (it's still an experimental API).
throwaway66666 8y ago
My gut feeling is that the user keys are not random generated, but actually encrypted strings that contain the permission values. Decrypting them with modern encryption algorithms (like ChaCha) is pretty CPU intensive.

0815test 8y ago

"Javascript did the job", but not very well apparently. They specifically say that they "were able to forget about the Rust service because it caused so few operational issues". Add to that the increased CPU- and RAM-efficiency that generally comes with a rust implementation, and that rust rewrite looks like a no-brainer.