Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Dislike EC2

openmymind.net

Post reply on HN
Print view View original

151–160 of 191 posts

Re: Why I Dislike EC2

#151

Post by bcoates »

CodeFoo wrote: post #141
jasonkester wrote: post #130

I sometimes feel like I'm the only one using EC2 as it was intended. S3stat's nightly job takes about 60 hours to run, and it needs to start and finish between 3am and 6am every morning. Amazon kindly keeps 20 machines ready to do that for me and only charges the time I'm actually using them. That's pretty amazing, and well worth the price in my mind. So yeah, if you need a box to run your webserver 24/7/365, you can…

> So yeah, if you need a box to run your webserver 24/7/365, you can find a better deal elsewhere. But that's really never been what EC2 is for. What Amazon offering is? This is AWS we're talking about. They have a service solution for nearly everything. You're saying in 2013 they still don't have a service for 24/7/365 website hosting?

Depends on what you mean by "hosting". If all you need to do is serve content, CloudFront+S3 will suffice.

Re: Why I Dislike EC2

#152

Post by vacri »

neya wrote: post #131
dangrossman wrote: post #4

On top of paying 8x what it cost before/after I moved from/back to Softlayer, AWS services just didn't work right. EBS failed often. RDS, which runs on top of EBS, would fail often too. When an entire AZ failed, despite paying double the hourly rate for "Multi-AZ" instances that were supposed to automatically fail over to another zone, nothing failed over, it just failed. If I need on-demand instances these days, I'l…

How does Rackspace work? Do they work just like Linode or are they an AWS competitor? I heard some good reviews about them, but not sure...Anyone here on Rackspace who could give us some pluses and minuses of the service?

We had a 2/3 ec2 1/3 rackspace split, and ended up moving largely off rackspace for operational reasons. I found the interface much more usable at AWS, whereas the one at Rackspace was a 'five clicks to do anything' webif, though apparently they've improved in recent months.

I'm not heavily experienced in cloud offerings, but it's far easier to manage the AWS stuff than the rackspace - the DNS management is quite flexible yet couldn't be simpler with AWS's 'Route 53', but with the part of Rackspace we were using it wasn't 'all in one place', which made it hard to peruse or alter.

I found support at both places to be upbeat and knowledgable, though I don't know about timeliness since I've only really lodged low-priority tickets. AWS does need more domain knowledge in order to understand its flexibility, and I've gotten a good workout from my $50/mo support add-on.

Re: Why I Dislike EC2

#153

Post by JoeAltmaier »

Our interactive server-based app (TeamSpace) absolutely cannot run in AWS/EC2. The latency is the killer. Even when throughput is high, latency per message can be 100s of milliseconds in/out of a datacenter, which is on top of our app latency and our client latency, leading to a miserable experience.

Re: Why I Dislike EC2

#154

Post by vacri »

Goladus wrote: post #80
forrestthewoods wrote: post #16

The first letter in EC2 stands for elastic. If you aren't using EC2 for it's elasticity then you're probably doing it wrong. Kind of a no-brainer.

Agreed. And of course, the second letter stands for compute . If you find yourself using words like traffic instead of computation and discussing the finer points of the per-hour billing feature instead of how many CPU-hours of jobs are enqueued, you should definitely consider that you're trying to use a tool that wasn't designed with your needs in mind. That said, AWS in general has a lot of useful tools for web dev…

I'm interested to hear the next shoehorned criticism based on the third word, 'cloud'.

Re: Why I Dislike EC2

#156

Post by bad_user »

nirvdrum wrote: post #90
threeseed wrote: post #78

Earlier quoted context omitted.

Not necessarily. AWS has a far superior network to almost anything else out there. Machine performance is not the only important part.

Sure, but the whole thing is predicated on the 20ms slowdown coming from a slow machine, not network latency. And that's a pretty good assumption. Due to RAM limitations and abysmal performance, I could maybe push 15 concurrent requests on a c1.medium running a Rails app in Passenger with a non-CoW Ruby. Forking is terribly slow on EC2. An m1.small was out of the question.

I'm working on a web service (build on top of Scala and the JVM) that's handling between 1500 and 3000 reqs per second per c1.medium instance, with an average time per request of under 15ms. This is real traffic, with the web service receiving between 16,000 and 30,000 total requests per second during the day. A c1.xlarge can do 7000 reqs per second or even more, but for the moment I felt like the difference in pricing is too big and it's cheaper and safer just starting more c1.medium instances (with auto-scaling based on latency), but in case we'll need more RAM, then we'll probably switch to c1.xlarge.

If scalability matters, you should have picked a better platform. Ruby/Rails/Passenger is a terrible platform for scalability / performance. And even if AWS is slower than other solutions, the first problem you have is your own heavy-weight app and the platform you've chosen. 15 concurrent requests per second makes me chuckle.

Re: Why I Dislike EC2

#157

Post by Goladus »

nirvdrum wrote: post #149
CodeFoo wrote: post #141

Earlier quoted context omitted.

> So yeah, if you need a box to run your webserver 24/7/365, you can find a better deal elsewhere. But that's really never been what EC2 is for. What Amazon offering is? This is AWS we're talking about. They have a service solution for nearly everything. You're saying in 2013 they still don't have a service for 24/7/365 website hosting?

I know you were asking for effect, but of course they do and it's EC2. That's why they have a heavy reservation pricing tier, which only makes sense for 24/7/365 (you pay for hours even if you don't use them). But, it's fun to point at "elastic" and tell people they're "doing it wrong" because they don't take a name chosen 7 years ago literally. As if somehow the service (called EC2 virtually everywhere -- not Elasti…

In other words they took a system targeted especially at people who needed on-demand computing and as it got popular, adapted it to the needs of the 24/7/365 web-hosting by offering an alternate pricing model, point-and-click user interfaces and additional features and services like EBS and CloudWatch.

The point is absolutely not that EC2 never evolved beyond its initial use case and isn't good at other things.

The point is that while they have 24/7/365 hosting services, there's never been any reason to expect that they would be better at it than anyone else. So why do we continue to see blog posts about not liking EC2 with vague complaints about the horrible price-to-performance ratio getting lots of upvotes?

Re: Why I Dislike EC2

#158

Post by nirvdrum »

bad_user wrote: post #156
nirvdrum wrote: post #90

Earlier quoted context omitted.

Sure, but the whole thing is predicated on the 20ms slowdown coming from a slow machine, not network latency. And that's a pretty good assumption. Due to RAM limitations and abysmal performance, I could maybe push 15 concurrent requests on a c1.medium running a Rails app in Passenger with a non-CoW Ruby. Forking is terribly slow on EC2. An m1.small was out of the question.

I'm working on a web service (build on top of Scala and the JVM) that's handling between 1500 and 3000 reqs per second per c1.medium instance, with an average time per request of under 15ms. This is real traffic, with the web service receiving between 16,000 and 30,000 total requests per second during the day. A c1.xlarge can do 7000 reqs per second or even more, but for the moment I felt like the difference in prici…

I don't entirely disagree. All I can say is REE and Rails 2.3 were far lighter weight and faster than Ruby 1.9 and Rails 3.2. Given it's a 3.5 year old app, the landscape was pretty different back then. I looked at Lift and didn't like it. Django was still in a weird place. And ultimately Rails looked like the best option for a variety of reasons.

Things evolve and whole hog rewrites are difficult. Nowadays we run in JRuby and things are quite a bit better. But we can't run on anything smaller than an m1.large. The low I/O and meager RAM in a c1.medium preclude its use. (BTW, that's where a lot of the original 15 came from -- with a process using 100 MB RAM and only 1.7 GB available, it's hard to squeeze much more out of that).

But the larger point is with virtually any other provider you can pick a configuration that matches the needs of your app (rather than the other way around), don't have to fight with CPU steal, don't have to fight with over-subscribed hardware, and don't have to deal with machine configurations from 2006. Yeah, Rails is never going to outperform your Scala web service. But if the app would run just fine on the other N - 1 providers, then it's disingenuous to gloss over the execution environment as well.

Re: Why I Dislike EC2

#159

Post by nirvdrum »

bad_user wrote: post #156
nirvdrum wrote: post #90

Earlier quoted context omitted.

Sure, but the whole thing is predicated on the 20ms slowdown coming from a slow machine, not network latency. And that's a pretty good assumption. Due to RAM limitations and abysmal performance, I could maybe push 15 concurrent requests on a c1.medium running a Rails app in Passenger with a non-CoW Ruby. Forking is terribly slow on EC2. An m1.small was out of the question.

I'm working on a web service (build on top of Scala and the JVM) that's handling between 1500 and 3000 reqs per second per c1.medium instance, with an average time per request of under 15ms. This is real traffic, with the web service receiving between 16,000 and 30,000 total requests per second during the day. A c1.xlarge can do 7000 reqs per second or even more, but for the moment I felt like the difference in prici…

I just wanted to add -- since you're not the first to point out the Rails part -- that I've also run a 42 node Cassandra cluster on a m1.xlarges and did a fair bit of CPU-bound operations (encryption and compression) on hundreds of TB of data on cc2.8xlarge. I just used the Rails one as an example.

In the case of Cassandra, disk I/O was a constant issue. So, we grew the cluster much larger than would be necessary on another provider. We also lost instances pretty regularly. If we were lucky, Amazon would notify us about degraded hardware, but usually the instance would stay up but do things like drop 20% of its packets. Replacing a node in Cassandra is easy enough, but you quickly learn how much their I/O levels impact network performance as well. Nowadays Cassandra has the ability to compress data to reduce network load, but you then run into EC2's fairly low CPU performance.

The CPU-bound application I mentioned wasn't so bad, but we paid heftily for that ($2.40 / hour - some volume discount). At the high end the hardware tends not to be over-subscribed.

Performance, price, and reliability were all issues in all cases. Those are not EC2's strong suits and haven't been for a while.

Re: Why I Dislike EC2

#160

Post by bad_user »

nirvdrum wrote: post #158
bad_user wrote: post #156

Earlier quoted context omitted.

I'm working on a web service (build on top of Scala and the JVM) that's handling between 1500 and 3000 reqs per second per c1.medium instance, with an average time per request of under 15ms. This is real traffic, with the web service receiving between 16,000 and 30,000 total requests per second during the day. A c1.xlarge can do 7000 reqs per second or even more, but for the moment I felt like the difference in prici…

I don't entirely disagree. All I can say is REE and Rails 2.3 were far lighter weight and faster than Ruby 1.9 and Rails 3.2. Given it's a 3.5 year old app, the landscape was pretty different back then. I looked at Lift and didn't like it. Django was still in a weird place. And ultimately Rails looked like the best option for a variety of reasons. Things evolve and whole hog rewrites are difficult. Nowadays we run in…

Yes, JRuby should be much better.

Run it on top of JDK 7 and use the CMS garbage collector, as JRuby (and Scala) tend to generate a lot of short-term garbage and experiment with the new generation proportion (something like -XX:+UseConcMarkSweepGC -XX:NewRatio=1 -XX:MaxGCPauseMillis=850). You can also profile memory usage (make sure you're not stressing the GC, as that can steal away CPU resources) and for that I believe you can use Java profilers (like YourKit which is pretty good).

Also, try to do more stuff async, like in another thread, process or server. Use caching where it's easy, but don't over do it, as dealing with complex cache invalidation policies is a PITA.

Post reply on HN