Open source Scaling Ruby on Rails vs PHP
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
There has been a lot of talk in the blogsphere about scaling. Most of this have been caused by an interview with Alex Payne where he discusses the problems they have had with scaling up twitter. After reading it you really get the sense that Rails does not currently have any hard/fast answers to the scaling problem. One key element he mentions (and I am no ruby expert!) is that Rails does not allow you access to more than one database at a time. This is only a problem if your database server is the bottleneck but there are certainly enough instances where you need to split your requests between two database servers to make it a priority to get it fixed.
The second and most serious problem is really about high level frameworks. It is an obvious trade off that high level languages give you faster development but slower execution and less flexability to control bottlenecks. Alex stated that the only way currently to increase performance was to throw more hardware at it, and there is only so much hardware throwing you can do before other harder to fix bottlenecks start happening.
Compared to the current problems Rails is facing PHP is proving itself within a very wide range of sectors including the commercial sector. And although PHP in its raw state is slower to develop for and more prone to having BAD code written for it. The guys at Zend (and the open source community) are doing a great job at building a framework that is making developed quicker and enforces better code practices.
The advantage of using a framework within PHP is that you still have the option to tweak at a lower level when you find a bottleneck. The Zend Framework gives you Zend_Cache which allows you to cache chunks of data or sections of output both which can be generated within a hierarchy of cached content. On top of this if you are a commercial company you can switch the cache mechanism from its built in modules (file, database, etc..) to cache within their own Zend Platform for enterprise level stability and performance.
There are a lot of other PHP Frameworks out there CakePHP, Prado, Symphony to name but a few. And although I think its healthy that everyone wants to work on improving PHP by writing different frameworks I hope that we end up with one standard bearer framework with which we can associated with PHP.
One other quick note to say I was very interested to see that Zend have also been getting in bed with BEA.
5 Questions with Alex Payne on Radical Behavior blog
Another article and a reply in the comments from Alex
List of PHP Accelerators
Others Talking about Twitter/Scaling/Rails
tzda uclkfa zyarugi 
meiru mp3 hentai meiru engineering hentai 
wow !!
its very point of view.
Good post.
realy good post
thx :-) 
Examples are easy to follow for my students 
Good day!, 
Hi!, 
Oops - Missing a final parenthesis. Looks like I failed the pseudo code programming test. ;-)
FINAL SCORE = PERCENTAGE CORRECT ...
I am the best coder alive. I code the human DNA and the entire universe. Period. I am the best ...
Good article, largely true (and made me smile) although I have now got 2 agencies who on the whole don't ...
Trackback by PHPDeveloper.org on 19 April 2007:
Nick Halstead’s Blog: Open source Scaling Ruby on Rails vs PHP…
…
Comment by topfunky on 19 April 2007:
I think these problems are no different from what PHP was experiencing in the mid-to-late 90’s when PHP stood for Personal Home Page. People didn’t take it seriously. People said that it was not enterprise ready.
Fast forward a few years and the parser was rewritten, commercial support became available, and PHP can be seen in use at IBM, Yahoo, and other large companies. People use PHP as a standard of scalability instead of needing to defend it.
Rails is in the middle of that same conversion right now. New interpreters are being written that will make it much faster. Commercial vendors such as Sun and Microsoft are coming on board. Sites with heavy traffic like the Penny Arcade and A List Apart are using Rails and helping to make it better.
Comment by TJ on 20 April 2007:
Rails allows connections to multiple databases. It’s not a recent feature.
Many Rails apps use memcache or other caching techniques. These are well-known in the Rails developer community.
The advantage of using a framework within Ruby is that you still have the option to tweak at a lower level when you find a bottleneck. Including dropping to C with no trouble.
I think these problems are no different from what PHP is experiencing right now when people try to build applications that require operations and behavior outside the realm of more traditional Web apps. Which is why people use J2EE as the standard of scalability.
Seriously, Twitter would have been no better off having been written in PHP. They should have done better database profiling, but didn’t. Sucks to be the most popular site on the ‘Net. Now that they’ve released early and gotten the gold, they need to dig in and customize the hell out of the their DB layer.
Rails gave them the win because it fit their development tastes and helped them get a product up and running fast. Ruby is a clean, fluid language, so tweaking and hacking to optimize for known concerns is straightforward. Twitter has problems, but they’re the problems people should want to have.
Comment by Mark Murphy on 20 April 2007:
That’s called “scaling”. It’s what’s supposed to happen. You eliminate some bottlenecks, alter performance (hopefully improved by a smidge or a lot), and then move on to other bottlenecks.
Why do you feel this is a feature of PHP, considering you can do that with nearly every Web framework I’ve tried, both Rails and various Java MVC stacks? Admittedly, my focus is on open source frameworks, and I can see where closed-source ones might make getting to lower levels more difficult.
Pingback by developercast.com » Nick Halstead’s Blog: Open source Scaling Ruby on Rails vs PHP on 21 April 2007:
[...] his “What I accidently learnt about programming” blog today, Nick Halstead shares some of his thoughts on Open Source scaling functionality in languages, specifically comparing Ruby and PHP. Compared [...]
Comment by melkahdor on 25 April 2007:
what’s nice with phpis there is many ways to do one thing.
heritage from perl I suppose.
there are to many web apps, developpers using php and it should be very difficult to convert a lot of them to use one framework.
all developper should try to make it own framework , if it is posssible. It’s a very exciting experience. I find it better than use an “anonymous” tool, made by other. And coding with an home made tool seem to be a faster and easyer way to.
Comment by sp on 3 May 2007:
Problem with PHP is it’s Perl legacy as well. Writing sloppy PHP code (even with the better frameworks in PHP) is MUCH easier than writing sloppy Rails code. The PHP developers I have worked with that love PHP also have the wrong mindset about development. They are much more focused on hacking than delivering production ready well tested/speced code. The PHP mentality (this is not saying ALL PHP coders are hackers, but the majority) and PHP’s Perl legacy of enabling sloppy code much more than other languages are the biggest PHP bottlenecks.
Comment by sp on 3 May 2007:
On the topic of Rails issues. I have three points to make:
* Our Rails application reads and writes to 6 different databases. Currently 4 of those databases are on the same server and 2 on another server. But 6 logically different databases that could be located on 6 different servers if need be when the time comes for scaling up to that level. Writing to multiple databases in PHP is about the same effort as it took to implement in Rails, except in Rails the solution feels (to the developers) much cleaner and more maintainable going forward. BTW the number of lines of code needed to support multiple databases for our AR models was between 30-40 and this was a generic enough solution such that adding AR models for a 7th database would require an additional 3 lines of code maximum.
* Performance: Rails does need some tweaking. Perhaps more so than PHP. However, it is completely doable and it doesn’t take anywhere near as much time as some people suspect it would. The biggest increase in performance we have found was from using memcached for sessions. This was a huge win. Another huge win was separating static asset content out of the Rails application (done by adding just one line of configuration code to environment.rb by the way). So you would have lighttpd or httpd serving up static content on optimized configurations and significantly improving total page load times and enhancing the user experience. Not to mention reducing unnecessary load to the Rails mongrel instances (we use mongrel).
* Scaling the scale solution: scaling with mongrel is a no-brainer in my view. Not to mention the superior deployment tools and predefined tasks in Capistrano and the Mongrel Capistrano extensions. Without a doubt much easier to deploy Rails applications seamlessly across many more boxes than effort to write custom scripts to automate the process for PHP applications.
The latter point is an often overlooked point, not to mention very important point to make for agile projects.
The problem with Twitter seems to be have been twofold:
* The developers seems very PHP biased and their way of thinking (mindset) is obviously not in tune with the Rails philosophy. This will always be a problem, but it is not a problem with Rails. The developers should have chosen PHP because they still think that way and seem unwilling to change quickly enough.
* The service had a huge surge in hits very quickly. They didn’t think about scaling soon enough and as a consequence they paid for it big time. This would have happened even if they wrote the entire thing in PHP. The only difference would have been that the developers had more experience in PHP and may have solved the problems quicker. But it is worth noting that the problems would have still existed nonetheless. No framework or language combination is ever going to overcome developer oversight or stupidity.
Comment by Nick on 3 May 2007:
Thank you for such a comprehensive comment sp. I think I will have to re-post it on the blog attributing it to you.
Pingback by The Soapbox » Ruby-on-Rails (Ror) vs PHP on 14 May 2007:
[...] folks at Twitter recently expressed their difficulties in scaling with RoR - check this and this. They faced moderate backlash from the RoR development community and I consider that to be [...]
Comment by christof on 5 September 2007:
I really think people should stop these post about php vs rails - its not the same thing , one is a language and the other a framework, rather compare the php zend framework with rails ror - I have been developing in all different flavours of php and frameworks for the past 7 years - I ‘ll put it straight, if you want an enterprise level framework, if you want to be taken seriously as a php developer then you’ll get into zend framework. It has a bit of a steap learning curve, but its 100% worth while at the end. Plus its got the zend company behind it, so you can be sure of quality, testing and regular upgrades. zend framework has got me all excited again - it just blows me away, how easy it is to accomplish tasks that normally took hours, zend framework rocks - I need to thank Zend for eventually reallizing that we (php community) needs an industry standard framework, and they have really gone all the way - I personally think rails ror has nothing on the zend framework, well ruby itself has so many cons it deserves a post of its own, one obvious one that I ‘ll mention here is the language syntax - it like nothing you’ve ever seen before, most novice coders with c, c++, java, javascript etc experience will not even attempt to learn it. Try zend framework, it really is the only php framework to consider.
Comment by Just me on 11 April 2008:
It sounds fantastic. The question is - this post is absolutely new and original, isn
Comment by DC on 22 May 2008:
This is a very helpful blog. Like Christof I have many years of experience with PHP and was considering Rails and learning Ruby, but the one thing we needed is some sort of encoder like the Zend or ionCube encoders and there isn’t anything for Ruby that will do that, so we went with PHP and the Zend Framework makes sense for me simply because if anybody in the PHP world is enterprise minded, Zend surely comes to mind. Shucks, I was looking forward to getting paid to learn Ruby though hahaha ;o)
Comment by mormon on 11 August 2008:
I agree with this article. Rails is slow and expensive to scale, however with the addition of mod_rails now and the fact that most sites don’t even have to come CLOSE to scaling…it’s a viable solution. Albeit one slightly on the fringe when it comes to the enterprise. Just my $0.02.