3 ms·
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
by swrobel 13y ago
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 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.