6 ms·

A typical PHP application that does a bit of database updating per request, gets some new data from the DB and templates it should handle 20 requests per second

A typical PHP application that does a bit of database updating per request, gets some new data from the DB and templates it should handle 20 requests per second on a single $20/month VM. And in my experience from the last years, VMs have uptime >99.99% these days. What made you settle on a multi-machine setup instead? Was it to reach higher uptime or were you processing very heavy computations per request?

atonse 7y ago
Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year. There was little to no room for error. I once introduced a bug in a commit that, in less than an hour, cost us $40,000. So it wasn't about performance. Also this was 9 years ago. So adjust for performance characteristics from back then.
- dwild 7y ago
  100 000 000$ a year with only 20 requests a second? That's some crazy revenue per request, 100 000 000 / (365 * 24 * 60 * 60) = 3.17$ per request! What were you selling?
  - atonse 7y ago
    Insurance policies :) Good point, actually the 100MM may have included brick and mortar.
  - mytherin 7y ago
    Forgot to multiply by 20, it's actually around $0.15 per request. Still high but certainly not as crazy.
  - aaron_m04 7y ago
    It should be (365 * 24 * 60 * 60 * 20) which brings it to $0.15/req if I did my mental math right. Still a high amount of course.
    - dwild 7y ago
      Oh thanks, I actually did the math right the first time, kept only the result and then when I was about to hit send I thought it was too good to be true, thus I did it again and got 3.15$, which was even crazier, but couldn't find why my math was wrong.
  - btilly 7y ago
    I worked on a site 20 years ago that got even better revenue per request (though with fewer requests). It did analytics on bond deals. Cost $1k/month for an account. Minimum 3 accounts. Median logins, ~1/month/account. On the other hand people would login because they were about to trade $10-100 million of bonds. So knowing what the price should be really, really mattered. Wall St can be a funny place.
    - dwild 7y ago
      That's quite interesting! That's why I asked, I wasn't exactly doubting the figure, just curious about the market that allowed that kind of customer targeting.
gravitas 7y ago
(outside of GP's reply) Generically, life is messy and unpredictable, never put all your eggs in one basket. Your cloud server is sitting on a physical hyp which will need maintenance or go down, or even something in your VM goes wrong or needs maintenance. Using a basic N+1 architecture allows for A to go down and B to keep running while you work on A - whether that's DNS, HTTP or SQL etc.
- FreeHugs 7y ago
  If your physical hyp dies, how do you redirect your traffic to a different one?
  - vajrabum 7y ago
    Load balancing--and yes that can become a source of failure too.
  - CameronNemo 7y ago
    Two load balancers using either keepalived or bgp anycast.
  - gravitas 7y ago
    Replace "your" with "the" - the hyp can be run by your provider (Linode, DO, Vulture, AWS, GKE, whoever). Most cloud providers have virtual/shared/managed load balancers to rent time on as well, such that you don't have to maintain N+1 of those (let them do it). You could even use basic round-robin DNS, it's a possible choice just not generally suggested.
    - FreeHugs 7y ago
      For the load balancer solution, a lot more is needed then to just rent a load balancer. Example: What do you expect to happen when the server with your DB goes down? Just send the next UPDATE/INSERT/DELETE to DBserver2? Which is replicated from the DBserver1? When DBserver1 comes back, how does it know that it now is outdated and has to sync from DBserver2? How does the load balancer know if DBserver1 is synced again and ready to take requests? Even if you set up all moving parts of your system in a way that handles random machine outtages: Now the load balancer is your single point of failure. What do you do if it goes down?
Damogran6 7y ago
A single server isn't redundant. 3 behind a load balancer, where each is sized to handle 50% of the volume lets you take systems offline for maintenance without incurring downtime. Heck, Raspberry Pis have more horsepower than the webservers in the cluster I ran around Y2k.
Vesuvium 7y ago
For performance context: nginx on a $5 DO droplet does 600 requests per second on static file. Serving static files with Elixir/Phoenix has a performance of 300 requests per second. Python+gunicorn serves about 100 requests per second of JSON from postgres data.

atonse 7y ago

Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year. There was little to no room for error. I once introduced a bug in a commit that, in less than an hour, cost us $40,000. So it wasn't about performance. Also this was 9 years ago. So adjust for performance characteristics from back then.

dwild 7y ago
100 000 000$ a year with only 20 requests a second? That's some crazy revenue per request, 100 000 000 / (365 * 24 * 60 * 60) = 3.17$ per request! What were you selling?
- atonse 7y ago
  Insurance policies :) Good point, actually the 100MM may have included brick and mortar.
- mytherin 7y ago
  Forgot to multiply by 20, it's actually around $0.15 per request. Still high but certainly not as crazy.
- aaron_m04 7y ago
  It should be (365 * 24 * 60 * 60 * 20) which brings it to $0.15/req if I did my mental math right. Still a high amount of course.
  - dwild 7y ago
    Oh thanks, I actually did the math right the first time, kept only the result and then when I was about to hit send I thought it was too good to be true, thus I did it again and got 3.15$, which was even crazier, but couldn't find why my math was wrong.
- btilly 7y ago
  I worked on a site 20 years ago that got even better revenue per request (though with fewer requests). It did analytics on bond deals. Cost $1k/month for an account. Minimum 3 accounts. Median logins, ~1/month/account. On the other hand people would login because they were about to trade $10-100 million of bonds. So knowing what the price should be really, really mattered. Wall St can be a funny place.
  - dwild 7y ago
    That's quite interesting! That's why I asked, I wasn't exactly doubting the figure, just curious about the market that allowed that kind of customer targeting.

gravitas 7y ago

(outside of GP's reply) Generically, life is messy and unpredictable, never put all your eggs in one basket. Your cloud server is sitting on a physical hyp which will need maintenance or go down, or even something in your VM goes wrong or needs maintenance. Using a basic N+1 architecture allows for A to go down and B to keep running while you work on A - whether that's DNS, HTTP or SQL etc.

FreeHugs 7y ago
If your physical hyp dies, how do you redirect your traffic to a different one?
- vajrabum 7y ago
  Load balancing--and yes that can become a source of failure too.
- CameronNemo 7y ago
  Two load balancers using either keepalived or bgp anycast.
- gravitas 7y ago
  Replace "your" with "the" - the hyp can be run by your provider (Linode, DO, Vulture, AWS, GKE, whoever). Most cloud providers have virtual/shared/managed load balancers to rent time on as well, such that you don't have to maintain N+1 of those (let them do it). You could even use basic round-robin DNS, it's a possible choice just not generally suggested.
  - FreeHugs 7y ago
    For the load balancer solution, a lot more is needed then to just rent a load balancer. Example: What do you expect to happen when the server with your DB goes down? Just send the next UPDATE/INSERT/DELETE to DBserver2? Which is replicated from the DBserver1? When DBserver1 comes back, how does it know that it now is outdated and has to sync from DBserver2? How does the load balancer know if DBserver1 is synced again and ready to take requests? Even if you set up all moving parts of your system in a way that handles random machine outtages: Now the load balancer is your single point of failure. What do you do if it goes down?

Damogran6 7y ago

A single server isn't redundant. 3 behind a load balancer, where each is sized to handle 50% of the volume lets you take systems offline for maintenance without incurring downtime. Heck, Raspberry Pis have more horsepower than the webservers in the cluster I ran around Y2k.

Vesuvium 7y ago

For performance context: nginx on a $5 DO droplet does 600 requests per second on static file. Serving static files with Elixir/Phoenix has a performance of 300 requests per second. Python+gunicorn serves about 100 requests per second of JSON from postgres data.