[j-kidd]

> The persistence scaling story for Heroku seems pretty questionable to me.

Agree. Those people who tell horror stories about Heroku/EC2, usually give solid numbers, i.e. this was how much I spent, this is how much I save by moving away, and our response time is now X% faster.

On the other hand, we have article like this that shows pretty graph for a web app serving 16.2 requests per minute, and make bold claims that everything will scale.

[benologist]

Here's my pretty graph for serving ~500,000 requests per minute on Heroku:

https://api.playtomic.com/load.html

Savings aren't exclusively because of Heroku, I also switched the underlying architecture during that migration from C# / ASP.NET to NodeJS which is exceptionally well suited to what I'm doing there.

Previously: Dedicated servers, ~$1600 a month

8x dedicated servers at ~$200 each, each running 3 to 5 instances of the API depending on how many IP addresses they were provisioned with. Uploading was done via a simple hand-rolled script that'd just FTP everything to each server.

Now: Heroku, current usage $400 - $500 a month

With Heroku I don't have to worry about concurrent connections (typically 200 - 400 thousand people at once), I don't have to maintain all those servers and I don't have to fuck around with all the stupid things that can go wrong when you're operating at scale.

It was a lot of work to get to this point and I made a lot of mistakes like having a heavy redis pub/sub outside of the EC2 network that cost me $350 in excess bandwidth providing inter-dyno communication, and I saturated database connections lots of times because in the old days those dedicated servers each had a local mongodb which could keep up with ordinary connection pooling, but it was totally worth it.

[zeeg]

So let's assume thats $500 in dynos, that's approximately 14 dynos. You have 30k concurrent users per dyno using Node.JS?

It's not that I don't believe you, I just think you don't understand what you're saying.

(Actually, it is that I don't believe you)

That said, if this is if you're doing 500 requests/sec (that's very different than 500 concurrent users) per dyno, good for you. My main bottleneck was not so much CPU on the web machines (I hit memory limitations), but the database layer.

[benologist]

Just over 20,000,000 people hit my API yesterday 700,749,252 times, playing the ~8,000 games my analytics platform is integrated in for a bit under 600 years in total play time. That's just yesterday.

There are lots of different bottlenecks waiting for people operating at scale. Heroku and NodeJS, for my use case, eventually alleviated a whole bunch of them very cheaply.

[zeeg]

>>> 20000000/24/60/60.0 ~231.46666666666667 requests a second?

[benologist]

That's people, not requests. :)

[zeeg]

Is your graph showing concurrent (as in active connection) users?

[benologist]

The graph shows http requests, each individual person sends 'event.general...' requests approximately 2x per minute.

In the last minute ~460,000 of those requests were made which means somewhere around 230,000 people sent data although there's room for that to be higher or lower depending on sessions starting, sessions ending, and just what period of time you want 'concurrent' to live within.

[j-kidd]

So, another pretty graph for Heroku, yet no comparison to alternatives due to the total architecture change. The numbers are useless for comparison purpose.

[heretohelp]

Your app isn't "serving" anything up, it's an event API. 100% different use-case than what I was talking about.

[batista]

You keep using that word "serving". I don't think it means what you thing it means. Parent is spot on.

[heretohelp]

>The persistence scaling story for Heroku seems pretty questionable to me.

I said this and was talking exclusively about this. Read my original comment.

[heretohelp]

>16.2 requests per minute

Was it written in TCL? ;)