4 ms·

2400 rps on this hardware on hello world application - isn't it kinda bad? And we trading performance for what exactly? Code certainly didn't become any simple

2400 rps on this hardware on hello world application - isn't it kinda bad? And we trading performance for what exactly? Code certainly didn't become any simpler.

slyall 1y ago
It's only bad if you need to get more than 2000 rps Which is only a small proportion of sites out there.
- kqr 1y ago
  I'd argue it's bad even if you get more than 1000 Bq of requests. You never want to approach 100 % utilisation, and I'd aim to stay clear of 50 %.
- Tractor8626 1y ago
  If there is no some other advantages - it is just bad.
  - kragen 1y ago
    It's boring technology that's supported everywhere, and starting the program from the beginning for every request eliminates a lot of the places where corrupted state can persist from one request to the next.
- gred 1y ago
  I'd rather not pay for 8 cores / 16 threads, though...
  - withinboredom 1y ago
    Depends on where you are shopping. I pay €211 every month for 96 threads and 384 gb of ram (clustered) -- disks are small (around 1tb each), but I'm still nowhere near 50% utilization there.
    - gred 1y ago
      Yeah, I pay $400/month to not be bothered with any installation or upgrade drama, ever. The problem is that I only get 16 threads.
      - johnisgood 1y ago
        I installed many Arch Linux for servers, they have been online for decades. There is no fuss. The only downtime was when I issued a reboot, but it was back in 5 seconds if not less. So you really do not have to be bothered by installation or anything of these lines. You install once and you are fine. You should check out the Wiki pages of Arch Linux, for example. It is pretty straightforward. As for upgrades, Arch Linux NEVER broke. Not on my servers, and not on my desktop. That said, to each their own.
        indigodaddy 1y ago
        Arch on servers is completely insane, unless you never update or are a maniac and update every few days
        oblio 1y ago
        Software is so advanced these days that tech SMBs can probably run Windows XP in production.
        johnisgood 1y ago
        Why would you think that it is insane? It works well, and had no issues for decades. Any personal experiences you have that suggest otherwise? I would love to hear. I will give you the benefit of the doubt that you are not regurgitating what other people have been saying (IMO wrongfully), which is: "Arch Linux for servers? Eww. Bleeding edge. Not suitable for servers.". All that said, please, do share. It will not negate those decades of no issues, however. As I said, I maintain quite a lot of Arch Linux servers with loads of services without any issues, for decades.
        1y ago
- masklinn 1y ago
  > It's only bad if you need to get more than 2000 rps Or if you don't want to pay for an 8/16 for the sort of throughput you can get on a VPS with half a core.
- YmiYugy 1y ago
  Yes, but it's running on pretty powerful hardware. Try this with 1 vCPU, 512MB RAM and a website, that makes a lot of requests for a single page visit. Until recently I used to maintain some legacy B2B software, where each customer got their own container with very strict resource limits. A single page visit could cause 20-50 requests. Removing CGI was a significant performance win, even with a single user loading just one page.
kqr 1y ago
It's not great, but it is enough for many use cases. Should even handle a HN hug of death.
- Tractor8626 1y ago
  But why? What advantages we getting?
  - kqr 1y ago
    Hypothetically, strong modularisation, ease of deployment and maintenance, testability, compatibility with virtually any programming language. In practise I'm not convinced -- but I would love to be. Reverse proxying a library-specific server or fiddling with FastCGI and alternatives always feels unnecessarily difficult to me.
- procaryote 1y ago
  The marging for error becomes tiny though... Performance regression making some requests slow? Suddenly you don't handle even those 2k requests. And a Denial of service attack doesn't even have to try hard.
  - kqr 1y ago
    I'm not convinced the run-time performance always comes from the same pool as start-up overhead. If the regression is waiting-based because resource contention or whatnot (very common) then that won't make the OS start up new processes more slowly, for example. Sure, there are regressions that will make start-up overhead worse, but I mean, there will be pathological regressions in any configuration.
    - procaryote 1y ago
      The problem is that 2400rps is such a tiny number. You can ddos yourself accidentally from a few browsers and a bug that makes it retry a request over and over; and the whole service will melt down in fun ways before you can isolate that. The thing limiting you to that number also isn't just the startup cost. If it was, you could just run more things in paralell. The startup cost kills your minimum latency, but the rps limit comes from some other resource running out; cpu, memory, context switching, waiting for other services that are in themselves limited, etc. If it's cpu, which is very likely for python, any little performance regression can melt down the service. Life is so much easier if you just get a somewhat performant base to build on. You can get away with being less clever, and you can see mistakes as a tolerable bump in resource usage or response times rather than a fail-whale

2400 rps on this hardware on hello world application - isn't it kinda bad? And we trading performance for what exactly? Code certainly didn't become any simpler.

slyall 1y ago

It's only bad if you need to get more than 2000 rps Which is only a small proportion of sites out there.

kqr 1y ago
I'd argue it's bad even if you get more than 1000 Bq of requests. You never want to approach 100 % utilisation, and I'd aim to stay clear of 50 %.
Tractor8626 1y ago
If there is no some other advantages - it is just bad.
- kragen 1y ago
  It's boring technology that's supported everywhere, and starting the program from the beginning for every request eliminates a lot of the places where corrupted state can persist from one request to the next.
gred 1y ago
I'd rather not pay for 8 cores / 16 threads, though...
- withinboredom 1y ago
  Depends on where you are shopping. I pay €211 every month for 96 threads and 384 gb of ram (clustered) -- disks are small (around 1tb each), but I'm still nowhere near 50% utilization there.
  - gred 1y ago
    Yeah, I pay $400/month to not be bothered with any installation or upgrade drama, ever. The problem is that I only get 16 threads.
    - johnisgood 1y ago
      I installed many Arch Linux for servers, they have been online for decades. There is no fuss. The only downtime was when I issued a reboot, but it was back in 5 seconds if not less. So you really do not have to be bothered by installation or anything of these lines. You install once and you are fine. You should check out the Wiki pages of Arch Linux, for example. It is pretty straightforward. As for upgrades, Arch Linux NEVER broke. Not on my servers, and not on my desktop. That said, to each their own.
      - indigodaddy 1y ago
        Arch on servers is completely insane, unless you never update or are a maniac and update every few days
        oblio 1y ago
        Software is so advanced these days that tech SMBs can probably run Windows XP in production.
        johnisgood 1y ago
        Why would you think that it is insane? It works well, and had no issues for decades. Any personal experiences you have that suggest otherwise? I would love to hear. I will give you the benefit of the doubt that you are not regurgitating what other people have been saying (IMO wrongfully), which is: "Arch Linux for servers? Eww. Bleeding edge. Not suitable for servers.". All that said, please, do share. It will not negate those decades of no issues, however. As I said, I maintain quite a lot of Arch Linux servers with loads of services without any issues, for decades.
        1y ago
masklinn 1y ago
> It's only bad if you need to get more than 2000 rps Or if you don't want to pay for an 8/16 for the sort of throughput you can get on a VPS with half a core.
YmiYugy 1y ago
Yes, but it's running on pretty powerful hardware. Try this with 1 vCPU, 512MB RAM and a website, that makes a lot of requests for a single page visit. Until recently I used to maintain some legacy B2B software, where each customer got their own container with very strict resource limits. A single page visit could cause 20-50 requests. Removing CGI was a significant performance win, even with a single user loading just one page.

kqr 1y ago

It's not great, but it is enough for many use cases. Should even handle a HN hug of death.

Tractor8626 1y ago
But why? What advantages we getting?
- kqr 1y ago
  Hypothetically, strong modularisation, ease of deployment and maintenance, testability, compatibility with virtually any programming language. In practise I'm not convinced -- but I would love to be. Reverse proxying a library-specific server or fiddling with FastCGI and alternatives always feels unnecessarily difficult to me.
procaryote 1y ago
The marging for error becomes tiny though... Performance regression making some requests slow? Suddenly you don't handle even those 2k requests. And a Denial of service attack doesn't even have to try hard.
- kqr 1y ago
  I'm not convinced the run-time performance always comes from the same pool as start-up overhead. If the regression is waiting-based because resource contention or whatnot (very common) then that won't make the OS start up new processes more slowly, for example. Sure, there are regressions that will make start-up overhead worse, but I mean, there will be pathological regressions in any configuration.
  - procaryote 1y ago
    The problem is that 2400rps is such a tiny number. You can ddos yourself accidentally from a few browsers and a bug that makes it retry a request over and over; and the whole service will melt down in fun ways before you can isolate that. The thing limiting you to that number also isn't just the startup cost. If it was, you could just run more things in paralell. The startup cost kills your minimum latency, but the rps limit comes from some other resource running out; cpu, memory, context switching, waiting for other services that are in themselves limited, etc. If it's cpu, which is very likely for python, any little performance regression can melt down the service. Life is so much easier if you just get a somewhat performant base to build on. You can get away with being less clever, and you can see mistakes as a tolerable bump in resource usage or response times rather than a fail-whale