Hacker News Reader

Comment by fweespeech | Hacker News Reader

> That works out at 2.95 years of computation for $370.

It is 2.95 years of computation on less than 1 CPU core.

http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduct...

> AWS Lambda allocates CPU power proportional to the memory by using the same ratio as a general purpose Amazon EC2 instance type, such as an M3 type. For example, if you allocate 256 MB memory, your Lambda function will receive twice the CPU share than if you allocated only 128 MB.

https://aws.amazon.com/ec2/instance-types/

> m3.large 2 7.5 1 x 32

> Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.

1 Core per 7.5GB RAM. Or ~1/28th of 1 core.

(2.95*365.25)/28 = ~39 Core Days.

That is really only impressive when you are comparing AWS prices to AWS prices which is a trap people seem to frequently fall into imo.

View on HN

The computation costs for Lambda were $174, not the full $370.

Using AWS Lambada created that cost structure. Using an alternative to AWS would not.

$150 (at most) dedicated server for instance.

We're all assuming content comes in constantly, but that's not the case. I imagine they spike heavily at peak times, perhaps 5-6 fold (judging by my own site statistics). Serverless might be good for them because they can handle small loads with small costs and large loads with no effort.

> We're all assuming content comes in constantly, but that's not the case. I imagine they spike heavily at peak times, perhaps 5-6 fold (judging by my own site statistics). Serverless might be good for them because they can handle small loads with small costs and large loads with no effort.

No. I've pushed 1000 r/s (approx) on a price tracking tool at work for keeping track of competitors on one of those boxes. Their largest spike (even if you assume its 10x their average) would be at most 15% of that.

Wow, I wonder if it's location based. Mine was heavily situated in one location, whereas yours was perhaps global? So it was always prime time for someone? Here is a graph of my usage for the past week (note lows of 30-40 and highs of 650 odd):

https://puu.sh/wrAn1/5816d3f7d7.png

> Wow, I wonder if it's location based. Mine was heavily situated in one location, whereas yours was perhaps global? So it was always prime time for someone? Here is a graph of my usage for the past week (note lows of 30-40 and highs of 650 odd):

A) I'm not sure "one location" is a city, country, or province.

B) Yes, it was global as we had offices from China to the EU.

C) Given the OP is handling 15 r/s, 150 r/s is not going to be pushing 500 mbps unless something is very poorly designed.

D) Even at spikes of 40x, it would still only be 600 r/s which is still quite doable with a commodity server.

The only serious difference is it was very large batches of requests (20 * SKUs) so people were fine with waiting a few minutes.

As an aside (and a noob question), how many requests can a single server handle? I know frameworks such as Node can do handle many more connections when compared to something like Django but what would be a reasonable ballpark?

As a concrete example, say you have an ecommerce app. Read requests take 80ms while write takes 200ms. Any good article/book I can read to get more insight regarding this?

I've personally handled hundreds of requests per second using Django behind Nginx on a m3.medium EC2 instance. The trick to scaling like this is to take full advantage of caching, and the cores available to you. With Django (and Node), this means spinning up multiple instances on a single server (one per available core).

With even moderate caching (say, 1m), you can saturate your VM's bandwidth before running out of CPU or memory.

Ultimately, you will always have a bottleneck. All you can do is identify the bottleneck (via load testing) and address it. If it's network (and you're in Amazon), you have to scale vertically until they remove that limit, or horizontally if you're already on unrestricted instances. If it's the CPU, you'll need to be more aggressive at caching completed computations, or work in a language with less overhead. If it's memory, start evaluating the tradeoffs between CPU and memory. If it's your DB, start investigating why it's slow (it's probably a poor index or configuration; DBs on decent hardware can handle millions of requests per second before degrading).

I don't have any book recommendations; I just recommend creating something and find its limits with a simple load test tool. Then figure out your bottleneck and fix that. Rinse and repeat, and learn.

Its too application centric to be honest to give good generics unless you've built something similar before.

> As a concrete example, say you have an ecommerce app. Read requests take 80ms while write takes 200ms.

An ecommerce site can be nearly 100% cached except for cart/session/search data. This gives it a massive advantage over everything else (since you can load the non-cached data via js and its relatively tiny).

I think the last time I benchmarked one of our front end servers it was ~500 r/s on 2 cores for our search page.

You really aren't going to know until you try it and benchmark it yourself tho.

Reply on news.ycombinator.com