Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: could an EC2 microinstance handle being on TechCrunch or front page HN?
14 points by hoodoof on June 18, 2013 | hide | past | favorite | 28 comments
Say you managed to get TechCrunch to cover your site, or if your site got to the front page of HN, and you had a static HTML page as your index.html with all the images coming from a CDN, would an EC2 micro instance running Nginx be able to handle the load?


I'm going to go against the grain and say yes [1].

Static HTML hosted by nginx? How many hits do you honestly think being on TechCrunch would get you? 100,000? 200,000? 500,000? And over how much time? 500,000 requests in total over the course of a day?

nginx or any high-performance platform is designed to deliver hundreds of thousands of static responses in a second on high-performance hardware. Even a micro instance, for all its infinitesimally tiny CPU power, can deliver a small fraction of that. Let's say for the sake of argument a micro instance provides 0.5% the performance of an i7 2600K.

Knowing that an i7 2600K can easily saturate a gigabit Ethernet connection with over 200,000 small responses per second [2], and knowing that it's even easier to do so with large responses, we just have to be comfortable that our micro instance can handle your 500,000 requests per day. 0.5% of 200,000 rps is 1,000 rps. With 1,000 rps, we could fulfill our entire day's worth of 500,000 requests in 500 seconds.

Being #1 on the HN home page will yield sustained traffic in the realm of 10 to 30 requests per second. I think there's a lot of confusion about the load generated by being on the HN home page because we all have seen sites taken off-line by upvotes. That is more of an indication of architectural failures in web applications than a failure of the hardware.

[1] An important caveat being I understand that Amazon throttles active micro instances using some arcane algorithm that I've never actually taken the time to understand. It is certainly possible that they would throttle its performance so much that you could not handle a few dozen requests per second. But that too seems implausible to me.

[2] http://www.techempower.com/benchmarks/

Additional caveat: you need to not make silly mistakes in your nginx configuration.


I tend to agree with you (not on the basis of facts, but on hunch).

One thing about your calculations I would challenge is that 500,000 requests per day is 1,000 rps. If a site gets 500,000 requests because it was on TechCrunch for example, then the traffic flow is likely to be lumpy rather than smooth, with an initial very high peak requests per second declining over time.

The point being that you can't plan for traffic by dividing requests per day into requests per second. You need to plan for peak requests in any given second in that day, which is some number up to the total, hard to work out what.


Yes, real-world traffic will definitely vary over time.

1,000 rps is significantly beyond the average rps needed for 500,000 requests per day (which works out to an average/sustained ~6 rps). I consider the capacity to handle 1,000 rps well beyond the realm of handling the unpredictable burstiness of a 6 rps sustained load.

But just to contribute some anecdotal evidence: I've never observed greater than ~50 rps from the HN #1 position. Real world traffic is not smooth, but it's also not bursty to quite the degree that would be necessary to cause the server to wince.

All of this remains predicated on Amazon not throttling the CPU capacity to true zero or something approximating true zero.


You're vastly over-estimating the amount of traffic that being on the front page of TC brings you, generally we're talking about <10k direct visitors over a few hours.

(although if other outlets pick it up as a result of TC coverage that can obviously balloon)

Being on the front page of HN can get you in the low-to-mid tens of thousands of visitors, reddit the high tens of thousands.


I think you're making the same point I was when I asked the OP how much traffic she/he actually thinks will originate from being featured on one of these sites.

You'd be lucky to get 100,000 requests. Still, assuming there would be disagreement about that, I wanted to be generous with the number to show that even if we're extremely liberal with total daily traffic, we still are dealing with extremely small sustained load per second and small burst traffic.

As I said earlier, because we've all seen sites knocked offline by this kind of media attention, there is a widespread belief that the traffic in question is huge. It is not. Rather, the traffic some sites see as a result of being featured in this way is simply the first time they've been tested with any sort of concurrent usage. If during its development, the application was only ever been tested by a few users, it might not have been designed or deployed all that well.


You are right about nginx and it's performance. The only problem is that micro instances don't only have low cpu power. But also only a cpu boost. If it's get hit with multiple request after each other, the cpu boost is exhausted and the requests will pile up.

For a static page, S3 hosting of the html file is way more efficient.


I don't disagree that S3 is superior for hosting static content; I'm just concerned with the question of micro instances' capacity.

To continue that particular line of thinking... For the "CPU boost" point you bring up, do you understand the throttling as literally reducing the CPU capacity to zero when the boost is "exhausted"? Or simply dramatically reduced?

For the sake of argument again, let's say the Micro instance that is not being throttled by the Amazon hypervisor can handle 0.5% the sustained load of a i7 2600K. That is, 1,000 static requests per second from nginx.

Then, just by conjecture, let's say the throttling algorithm smashes the CPU allocation to 10% of its nominal maximum, thereby reducing our throttled micro instance's capacity to 0.05% that of an i7 2600K. We can still process 100 static requests per second from nginx. That is still more than enough to handle the few dozen requests per second that come in at #1 on the HN home page.

Like I said, it's theoretically possible that they throttle the CPU to literally zero but that seems extraordinarily punitive.


I agree with this on a general level, but I wonder if bandwidth at some level becomes an issue. If you have a page that weighs in at 1MB - not unlikely - and you are averaging, let's say, three dozen visitors per second for at least a little while, you are talking 288Mbps of traffic.

Would amazon allow that throughput, for a micro instance, at least briefly? Maybe, but I'd just be speculating. This I would guess is a more likely issue than CPU usage.


Edit: Never mind the above. By the time I got around to that first reply, I had forgotten the rather important fact that the assets were coming from a cdn.


And that is indeed the case. You only get a limited time of CPU, after that it's powers goes to somewhat like zero.


Not worth the risk. While the micro instances can handle the load and have good burst performance, they aren't good if the load is sustained. So if you get a sudden burst, and load average jumps, expect EC2 to penalize you.

See steal time and stolen CPU - http://www.newvem.com/whats-cpu-steal-time.

I have seen a micro instance become unaccessible to even ssh after a prolonged activity.


I had a front page item about a year ago. The article ended up getting like 300 points so it was on the front page for around 12 hours. All the content was served by nginx on a micro EC2 instance, nothing was even put on a CDN. But still, it worked flawlessly.


Interesting. How do you know it worked flawlessly?


How many hits did you get?


No, it would not handle the load. But you can use your AWS S3 bucket as a host for your index.html file. In route 53 you can easily point the index of the domain to your S3 bucket. This way you have a huge load capacity for the lowest prices.


If you host from S3 does that mean that we cannot have things like forms for example - because all requests to the domain are going to S3?


You can have forms, but they need to be jquery submission from the S3 static HTML to an external mongo sitting separately on your EC2 micro in the domain (or by IP address). Since you would receive few submissions likely - it would be fine I would think.


No. Many sites paying for hosting serving static pages go down by being on the front of HN so I doubt a free ec2 instance could out preform a paid one.

It's like asking if a gameboy can play battlefield 3.


Micro instances aren't free. Unless you are on the AWS free tier. But of themselves, they are not free.


As Wouter33 mentioned, put the HTML, CSS, and images in S3 (or CloudFront). I did this for a Top 3 U.S. music superstar client when they launched new stuff, and it held up fine.


Do you mean a micro instance held up fine?


I got 40k unique visits hours 1-2, and 200k unique visitors total over the course of a week (this traffic is probably much higher than a TCrunch article would be). Only static html, no servers at all - everything held together very well (i was monitoring twitter in case...bc if it went wrong it would be not good for me).


Hello czbond. Did you get onto the front page of HN? What was the post that got you there?


No - it was an singer who ran Billboard magazine ads, released a song, and was on the U.S. Grammys all in the same week.


If you have a static html page, do a silent redirect to the CDN which will also host the html page apart from the resources. That will work nicely.


No. The EC2 micro instances are not stable or reliable. I had to move to a small instance just because the micro instances kept going offline.


I've used micro instances extensively for a long time in locations all around the world and never had one go offline.


Hoodoof, I agree with you, they're very stable. The cpu and network traffic can hiccup occasionally - and the cpu throttles higher than a small instance.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: