How's Science-inc working out for you?
That's a whole other conversation ;)
Hopefully good, lol. I've been watching them recently and thinking about reaching out with a couple prototypes.
I left Heroku for OpsWorks and shaved 40% off response times
21–30 of 53 posts
Re: I left Heroku for OpsWorks and shaved 40% off response times
#22While I can understand the advantages the author of the article mentions, I must say that one should think about making the move to OpsWorks, because you can't compare their prices without considering other costs / tradeoffs. A friend of mine and I have been working on a startup for the last 8 months. It has been tough as we have been working full time for a company and hacking like crazy once we got home, or on week…
I'd be really interested to know more about how the switch shaved 40% off of the response times. What was the major bottleneck? RAM? CPU? Network IO to PostgreSQL? Network IO to memcache? Heroku is offering 2X and soon, 4X dynos; did he experiment with these? The author also sounds rather excited about nginx serving static assets. The Rack::Cache problem on Heroku is easily solved with a CDN layer (and Heroku even re…
I agree with the CDN comment. Please use a CDN to serve your assets no mater what you host on. It's so easy, and the performance gains to the end user are good, it should be an obvious choice.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#23Earlier quoted context omitted.
I'd be really interested to know more about how the switch shaved 40% off of the response times. What was the major bottleneck? RAM? CPU? Network IO to PostgreSQL? Network IO to memcache? Heroku is offering 2X and soon, 4X dynos; did he experiment with these? The author also sounds rather excited about nginx serving static assets. The Rack::Cache problem on Heroku is easily solved with a CDN layer (and Heroku even re…
I agree with the CDN comment. Please use a CDN to serve your assets no mater what you host on. It's so easy, and the performance gains to the end user are good, it should be an obvious choice.
Agree with both of you 100%, but the fact that Heroku forces this choice is a frustrating one nonetheless.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#24At WeHostels we moved from Heroku to Rackspace last year and we shaved ~30% off response times.
Curious from a user experience perspective would you consider going back to try out the PX dyno service? Do you use chef or puppet or any other software to manage your Rackspace instances?
Re: I left Heroku for OpsWorks and shaved 40% off response times
#25While I can understand the advantages the author of the article mentions, I must say that one should think about making the move to OpsWorks, because you can't compare their prices without considering other costs / tradeoffs. A friend of mine and I have been working on a startup for the last 8 months. It has been tough as we have been working full time for a company and hacking like crazy once we got home, or on week…
Agree with most of what you say, but adding dynos increases concurrency but doesn't do anything to reduce response times. Sometimes you just need a faster box.
Or a bigger (more RAM) box, I posted this to the Ruby Rouges mailing list on tail latencies: https://gist.github.com/schneems/8849116
Concurrency is only half the battle with tail latencies. Of course dedicated CPU helps as well :)
Re: I left Heroku for OpsWorks and shaved 40% off response times
#26Earlier quoted context omitted.
Agree with most of what you say, but adding dynos increases concurrency but doesn't do anything to reduce response times. Sometimes you just need a faster box.
Or a bigger (more RAM) box, I posted this to the Ruby Rouges mailing list on tail latencies: https://gist.github.com/schneems/8849116 Concurrency is only half the battle with tail latencies. Of course dedicated CPU helps as well :)
Good stuff schneems, in my case, too little, too late.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#27Nice writeup. I recently switched from Nodejitsu over to Heroku for my open source project gitignore.io and I noticed there was a slight slowdown in response time. The app score index in New Relic went from around 92 to 100 though so I guess Heroku's servers on AWS were a bit more reliable. I also added in a CDN to increase the speed of serving the static assets.
All in all, I can say that I'm happy with the transition, but I'm also running one Dyno which I'm far from maxing out. I feel like for a larger product, Heroku would be more problems down the line than it's worth.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#28Nice writeup. I recently switched from Nodejitsu over to Heroku for my open source project gitignore.io and I noticed there was a slight slowdown in response time. The app score index in New Relic went from around 92 to 100 though so I guess Heroku's servers on AWS were a bit more reliable. I also added in a CDN to increase the speed of serving the static assets. All in all, I can say that I'm happy with the transiti…
Exactly how I felt, great at small scale, but increasingly painful to use as you reach scale.
By the way, great tool, thanks for building it!
Re: I left Heroku for OpsWorks and shaved 40% off response times
#29Earlier quoted context omitted.
Or a bigger (more RAM) box, I posted this to the Ruby Rouges mailing list on tail latencies: https://gist.github.com/schneems/8849116 Concurrency is only half the battle with tail latencies. Of course dedicated CPU helps as well :)
Good stuff schneems, in my case, too little, too late.
Understood, can't be everything to every one. BTW thanks for sticking around and answering questions/engaging :)
Re: I left Heroku for OpsWorks and shaved 40% off response times
#30Earlier quoted context omitted.
I'd be really interested to know more about how the switch shaved 40% off of the response times. What was the major bottleneck? RAM? CPU? Network IO to PostgreSQL? Network IO to memcache? Heroku is offering 2X and soon, 4X dynos; did he experiment with these? The author also sounds rather excited about nginx serving static assets. The Rack::Cache problem on Heroku is easily solved with a CDN layer (and Heroku even re…
I was using 2X dynos on Heroku. I did have memory issues and had to continually reduce the number of unicorns that I was running. I think CPU and disk were the major bottlenecks, but again, Heroku makes it hard to track down exactly what the cause is. Also, we're an ecommerce site so we rely on a lot of external services (specifically for payments) where we have to run the call in the web process ... hence the issue…
> we have to run the call in the web process
I know you probably have good reason for this, but this smells like an architecture problem. Whenever you are talking to an external service it is a good idea to have your code laid out such that you can do that in the background. I understand that if you didn't plan enough architecture and maybe even product design to make that feasible from the get-go it is an expensive thing to build, but regardless of who is your hosting provider sooner or later you'll likely need to do it.
One thing I've always liked about heroku, at least in concept, is that it forces you to have good architecture. Some times it is a bit of a pain, but I think this pays off quicker than you seem to realize.