Hacker News new | ask | show | jobs
by robben1234 1106 days ago
Serving a social network is not the case where you'd want just one server. Mainly due to reliability concerns, spikes in traffic and different patterns at different times.

But if you like the idea of ignoring best practices, there are EC2 instances with 192 vCPUs that go for several thousands an hour. And taking as example Golang benchmarks https://github.com/smallnest/go-web-framework-benchmark where it's not uncommon to be able to serve 6 digits of 30ms requests per second with just 4 cores. Then the conclusion is, the limit is the sky, if you are stubborn enough.
3 comments
ihattendorf 1104 days ago
Several thousands an hour is a bit of a stretch, maybe you meant monthly? but your point still stands.

For those interested: right now the largest instance I see is a u-12tb1.112xlarge (448 vCPUs, 12 TB RAM, 100 gb networking) which is ~$109/hr on demand or $40-80/hr with a 1-3 year commitment. This works out to ~$29k, ~$58k, or ~$79k per month.

If you don't need 12 TB of memory, there's a 6 TB instance for roughly half the cost.

link
robben1234 1092 days ago
Whoops. Mixed up pricing. 192 vCPUs instances on-demand depending on the type indeed fluctuate around $10/hr, leading to several thousands a month.

Not to forget the data transfer costs though https://aws.amazon.com/ec2/pricing/on-demand/ And also the potential minefield of API GW and NAT costs.

link
fho 1104 days ago
Honestly, I am completely clueless, but what would a beefy server with 240 physical cores cost? (8 CPUs with 30 cores each)

edit: physical server that is

link
fho 1105 days ago
Another dumb question ... for "several thousand an hour" I could buy a pretty decent server myself ... last time I checked (on https://yourdatafitsinram.net/) the largest physical server there was like 10 grand.

Combine that with the ability to actually throttle a physical server (ie you only pay what you actually use, not per hour) ... I guess I would propose the following scaling strategy:

1. get cheap physical server 2. get your software up and running 3. get a second physical server that is roughly twice as capable 4. use that second server as a "beta" and development server ... do a lot of profiling there 5. once your real world usage spike on the first server routinely reach 80-90%, switch production over to the bigger server 6. get a new development server that is twice as beefy as the former development server

link
robben1234 1092 days ago
I mixed up pricing. Several thousands a month. But if you could buy a 192 CPUs server for just 10 grand, seems like not a bad deal. Especially if this hypothetical project is able to attract the load we are discussing for longer than a few weeks.
link
fho 1105 days ago
> But if you like the idea of ignoring best practice

... do you know me? ;-)

link