3 ms·

But he only did the rewrite after the first version proved there was a demand for the product. Sounds better than spending a few weeks (he did 20h!) on V1, onl

by PanMan 13y ago

But he only did the rewrite after the first version proved there was a demand for the product. Sounds better than spending a few weeks (he did 20h!) on V1, only to find out there is no demand for it.

mkingston 13y ago
I agree: there's no indication they had any problems serving their customers at any point, nor that they got crushed by hosting costs. I'd contend the "optimisation balance" was just about perfect.
- voidlogic 13y ago
  >>there's no indication they had any problems serving their customers at any point "we started having issues keeping up with customer demand" "To keep things running smoothly, I scaled up our Heroku Dynos, but quickly realized that things needed to be rewritten as soon as possible to avoid major problems." What you are saying is possible, by the article suggests they either did have problems serving customers or there was major risk of that happening...
  - rdegges 13y ago
    Author here: we never had any customer-facing issues, but (and a big shout out to New Relic), NewRelic helped us identify that we were dangerously close to a catastrophe if we kept growth steady. We did the rewrite to avoid problems, and by the time we relaunched our new Flask backend we were struggling to support customer demand. All in all, NewRelic really helped save us here ^^
    - rbsn 13y ago
      Could your performance problems be closer related to http://news.rapgenius.com/James-somers-herokus-ugly-secret-annotated http://news.rapgenius.com/James-somers-herokus-ugly-secret-a... than the performance of Django or your code?
      - rdegges 13y ago
        Nah, I've actually written quite a bit about Heroku (I authored a book on it). The issue was us having complex problems with Django and our supporting libraries: we needed to have database connection pooling, we had to rip out the tastypie REST framework due to complications with scaling the user model, and a bunch of other stuff. Heroku has always been great for us! I'm always a bit surprised about the RapGenius stuff because their problem is not really a Heroku specific issue, IMO. If you're running code on Heroku (which uses random load balancing), you need to have a proper multi-threaded web server to serve requests concurrently. In our situation, we were able to service many concurrent requests per dyno, and maintained very low response times (10ms or less), in most cases.

by PanMan 13y ago

But he only did the rewrite after the first version proved there was a demand for the product. Sounds better than spending a few weeks (he did 20h!) on V1, only to find out there is no demand for it.

mkingston 13y ago

I agree: there's no indication they had any problems serving their customers at any point, nor that they got crushed by hosting costs. I'd contend the "optimisation balance" was just about perfect.

voidlogic 13y ago
>>there's no indication they had any problems serving their customers at any point "we started having issues keeping up with customer demand" "To keep things running smoothly, I scaled up our Heroku Dynos, but quickly realized that things needed to be rewritten as soon as possible to avoid major problems." What you are saying is possible, by the article suggests they either did have problems serving customers or there was major risk of that happening...
- rdegges 13y ago
  Author here: we never had any customer-facing issues, but (and a big shout out to New Relic), NewRelic helped us identify that we were dangerously close to a catastrophe if we kept growth steady. We did the rewrite to avoid problems, and by the time we relaunched our new Flask backend we were struggling to support customer demand. All in all, NewRelic really helped save us here ^^
  - rbsn 13y ago
    Could your performance problems be closer related to http://news.rapgenius.com/James-somers-herokus-ugly-secret-annotated http://news.rapgenius.com/James-somers-herokus-ugly-secret-a... than the performance of Django or your code?
    - rdegges 13y ago
      Nah, I've actually written quite a bit about Heroku (I authored a book on it). The issue was us having complex problems with Django and our supporting libraries: we needed to have database connection pooling, we had to rip out the tastypie REST framework due to complications with scaling the user model, and a bunch of other stuff. Heroku has always been great for us! I'm always a bit surprised about the RapGenius stuff because their problem is not really a Heroku specific issue, IMO. If you're running code on Heroku (which uses random load balancing), you need to have a proper multi-threaded web server to serve requests concurrently. In our situation, we were able to service many concurrent requests per dyno, and maintained very low response times (10ms or less), in most cases.