6 ms·

However with Ruby 1.9 - 2.0 (2.1 will support generational gc, finally) the performance of Ruby (with ORM and non-c frameworks, like phalcon and Yaf) is drawing

by trebor 13y ago

However with Ruby 1.9 - 2.0 (2.1 will support generational gc, finally) the performance of Ruby (with ORM and non-c frameworks, like phalcon and Yaf) is drawing close to parity with PHP.[1] I think that what drove diaspora's failure is the lack of people who truly care to run their own nodes. There's a pretty steep "cost of acquisition" to get a single diaspora user. [1]: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db&l=3y8&f=zik0zj-zi8sfz-34v http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

pearjuice 13y ago
Wait, Ruby is actually slower than PHP? So whenever some webdev laughs at me for using PHP and points me to that "A fractal of bad design" article, I can just laugh back and say "Well, at least my language is faster!"? Amazing.
- reeses 13y ago
  Ruby, as generally served with Rails, has historically been much slower than SQL-in-the-page PHP with APC/etc. One example[1], from 37 Signals back in 2009, showed a 320ms response time (gack!) with 9,000 requests per minute on 10 4vcpu/4gb VMs in a private cluster. Assuming they had a reasonably tuned storage subsystem, this is pretty terrible performance. That's about 150 requests per second for 10 VMs with 40 vcpus and 40gb RAM. However, that doesn't quite match up with the 320ms claim, which would have them pushing a little lower. I'll assume a rounding error. Things have gotten better in many cases, but hardware and scaling up and out is still the best way to improve rails performance. [1] https://37signals.com/svn/posts/1819-basecamp-now-with-more-vroom https://37signals.com/svn/posts/1819-basecamp-now-with-more-...
  - benatkin 13y ago
    I don't think I could find a better summary for why rails was bad for a CMS than that post. You could do much better with ruby but until some more killer non-rails ruby web apps are written, ruby's reputation will be inseparable from that of rails.
- mcovey 13y ago
  One of the last complaints anyone has had about PHP is that it's slow. PHP's main competitors have only recently begun to catch up in terms of speed, and the future of PHP is looking like it's going to remain competitive and near/in the lead.

by trebor 13y ago

pearjuice 13y ago

Wait, Ruby is actually slower than PHP? So whenever some webdev laughs at me for using PHP and points me to that "A fractal of bad design" article, I can just laugh back and say "Well, at least my language is faster!"? Amazing.

reeses 13y ago
Ruby, as generally served with Rails, has historically been much slower than SQL-in-the-page PHP with APC/etc. One example[1], from 37 Signals back in 2009, showed a 320ms response time (gack!) with 9,000 requests per minute on 10 4vcpu/4gb VMs in a private cluster. Assuming they had a reasonably tuned storage subsystem, this is pretty terrible performance. That's about 150 requests per second for 10 VMs with 40 vcpus and 40gb RAM. However, that doesn't quite match up with the 320ms claim, which would have them pushing a little lower. I'll assume a rounding error. Things have gotten better in many cases, but hardware and scaling up and out is still the best way to improve rails performance. [1] https://37signals.com/svn/posts/1819-basecamp-now-with-more-vroom https://37signals.com/svn/posts/1819-basecamp-now-with-more-...
- benatkin 13y ago
  I don't think I could find a better summary for why rails was bad for a CMS than that post. You could do much better with ruby but until some more killer non-rails ruby web apps are written, ruby's reputation will be inseparable from that of rails.
mcovey 13y ago
One of the last complaints anyone has had about PHP is that it's slow. PHP's main competitors have only recently begun to catch up in terms of speed, and the future of PHP is looking like it's going to remain competitive and near/in the lead.