3 ms·
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 PostgreS
by nthj 13y ago
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 recommends you do so.) (Cult Cosmetics /is/ set up with CloudFront, so the author obviously knows this.)
There are a lot of Rails architecture smells in this article, such as worrying about the 60-second boot timeout and the 30-second request timeout. [1] I have to wonder if the time invested in learning Chef and managing the architecture may have been spent making the app more performant.
Developer time is really, really expensive. Not only can you bill $100-$150 hour instead of learning how to use Chef, you could be shipping features for your own products, which can bring you passive income forever. A lot of companies are successfully running on Heroku, and it seems strange to throw everything out for the explained reasons.
[1] Specifically, adding 'require: false' to your Gemfile and only loading heavy libraries when you need them greatly helps with boot time. Ideally, you won't run any image processing libraries (like RMagick) except in background jobs, and your main app should not even need these libraries available. Same goes for PDF generation, scraping technology, or any other heavy processing.
The 30-second timeouts either need to be handled via background jobs (the author mentioned they use sidekiq) or uploading directly to S3, side-stepping the web process entirely.
- swrobel 13y agoI 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 with 30s timeouts.
- rguzman 13y ago> 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.
- swrobel 13y agovalid point.
- joevandyk 13y agoHow would you do payment processing in the background without temporarily storing the payment details?
- steveklabnik 13y agoI work for a payments company. Generally, you use JavaScript to actually tokenize the card. You then save that token in your actual application, and then use it to actually charge against. This model works just fine with background jobs.
- thinkbohemian 13y agoI 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.
- swrobel 13y agoAgree with both of you 100%, but the fact that Heroku forces this choice is a frustrating one nonetheless.