4 ms·

We solved it 2 decades ago but then decided to use javascript on the server ...

• wmf 10mo ago
  Node.js is actually pretty good at C10K but it failed at multicore and C10M.
• _9vpl 10mo ago
  Node.js uses libuv, which implements strategy 2. mentioned on the linked webpage. "libuv is a multi-platform C library that provides support for asynchronous I/O based on event loops. It supports epoll(4), kqueue(2)"
  • marcosdumay 10mo ago
    Except that it wastes 2 or 3 orders of magnitude in performance and polls all the connections from a single OS thread, locking everything if it has to do extra work on any of them. Picking the correct theoretical architecture can't save you if you bog down on every practical decision.
    • _9vpl 10mo ago
      I'm sure there is plenty of data/benchmarks out there and I'll let that speak for itself, but I'll just point out that there are 2 built-in core modules in Node.js, worker_threads (threads) and cluster (processes) which are very easy to bolt on to an existing plain http app.
      • IgorPartola 10mo ago
        So think of it this way: you want to avoid calling malloc() to increase performance. JavaScript does not have the semantics to avoid this. You also want to avoid looping. JavaScript does not have the semantics to avoid it. If you haven’t had experience with actual performant code JS can seem fast. But it’s is a Huffy bike compared to a Kawasaki H2. Sure it is better than a kid’s trike but it is not a performance system by any stretch of the imagination. You use JS for convenience, not performance.
        • jauntywundrkind 10mo ago
          [flagged]
          • mystraline 10mo ago
            [flagged]
            • jauntywundrkind 10mo ago
              Architecture is far more important than runtime speed. (People are so easily swayed by "JS SUCKS LOL" because of experiences with terrible & careless client-server architectures, far more than js itself being "slow".) The people ripping into js suck up the interesting energies, and bring nothing of value.
              • dilyevsky 10mo ago
                Nothing about current js ecosystem screams good architecture it’s hacks on hacks and a culture of totally ignoring everything outside of your own little bubble. Reminds me of early 2000s javabeans scene
                • cap11235 10mo ago
                  Reminds me of early 2000s JS scene, in fact. Anything described as "DHTML" was a horrid hack. Glad to see Lemmings still works, though, at least in Firefox dev edition. https://www.elizium.nu/scripts/lemmings/ https://www.elizium.nu/scripts/lemmings/
                  • jauntywundrkind 10mo ago
                    Unqualified broadscale hate making no assertions anyone can look at and check? This post is again such wicked nasty Dark Side energy, fueled by such empty vacuous nothing. It was an incredible era that brought amazing aliveness to the internet. Most of it was pretty simple & direct, would be more intelligible to folks today than today would be intelligible & legible to folks from them. This behavior is bad & deserves censure. The hacker spirit is free to be critical, but in ways that expand comprehension & understanding. To classify a whole era as a "horrible hack" is injurous to the hacker spirit.
      • drogus 10mo ago
        Worker threads can't handle I/O, so a single process Node.js app will still have the connection limit much lower than languages where you can handle I/O on multiple threads. Obviously, the second thing you mention, ie. multiple processes, "solves" this problem, but at a cost of running more than one process. In case of web apps it probably doesn't matter too much (although it can hurt performance, especially if you cache stuff in memory), but there are things where it just isn't a good trade-off.
      • hinkley 10mo ago
        And I have confirmed to my own satisfaction that both PM2 and worker threads have their own libuv threads. Yes very common in node to run around one instance per core, give or take.
  • hinkley 10mo ago
    Libuv now supports io_uring but I’m fuzzy on how broadly nodejs is applying that fact. It seems to be a function by function migration with lots of rollbacks.
  • nine_k 10mo ago
    It's mostly RAM allocated per client. E.g. Postgres is very much limited by this fact in supporting massive numbers of clients. Hence pgbouncer and other kinds of connection pooling which allow a Postgres server to serve many more clients than it has RAM to allow connecting. If your Node app spends vety little RAM per client, it can indeed service a great many of them. A PHP script that does little more than checking credentials and invoking sendfile() could be adequate for the case of serving small files described in the article.
• drob518 10mo ago
  FFS, yep. Sigh.
• eternityforest 10mo ago
  I'm surprised there's not a lot more work on "backend free" systems. A lot of apps seem like they could literally all use the same exact backend, if there was a service that just gave you the 20 or so features these kinds of things need. Pocketbase is pretty close, but not all the way there yet, you still have to handle billing and security yourself, you're not just creating a client that has access to whatever resources the end user paid for and assigned to the app via the host's UI.
  • xnx 10mo ago
    Yes. Most Saas are a tiny bit of business logic with a substantial helping of design and code framework bloat.