First, I'm just starting to get past the Rails tutorials so I have NO (zero) knowledge of Rails at an Enterprise level. And I've had similar thoughts to Greg's that Rails was being pushed for the betterment of the speakers before.
So really I'm asking a question here... Are the points that Greg makes true?
Does Active Record really not have support for Prepared Statements?
We have two production applications running on Ruby. And how is it. Well, despite being perhaps no more than 5% of the functionality of our applications, Ruby on Rails is the number one consumer of Oracle CPU and logical gets. Why? Rails does not support prepared statements, so Oracle has to reparse every time.
He then goes on to say:
And ActiveRecord seems not to have learnt Hibernate's lession; that OR tools suck for performance and need caching tricks to make them work well.
Although maybe this is a result of Prepared Statements being absent?
Then, he has issues with Rails not running through a connection pool, because fastcgi is forking processes? Really? That sux:
Also, our Rails apps running in (now unmaintained) fast-cgi regularly go awry and fork more processes. Each one creates a new connection to Oracle. So, the opposite of connection pooling; connection denial of service.
Next:
And does Ruby support Unicode. Not really. And is Rails threadsafe? No.
Not threadsafe? Woah! Is this true?
So I'm really looking for answers now. Is everyone that is pushing Ruby on Rails really looking for more money, and not thinking about the enterprise readiness of the product? I know the 37signals success stories, and there are many more, but what of these questions that Greg raises?
6 comments:
Rails or not, if you aren't using bind variables / prepared statements with oracle in an enterprise app, be prepared to restart oracle often. You will eventually run out of shared memory. Guaranteed.
" Rails or not, if you aren't using bind variables / prepared statements with oracle in an enterprise app, be prepared to restart oracle often. You will eventually run out of shared memory. Guaranteed."
Guaranteed? Interesting. We have enterprise level apps with 10,000+ users that stay up for months. They don't use prepared statements.
We have deployed a few web applications in rails. I really enjoyed the development, but the kicker for us was maintenance. Rails does so much, so well, apart from when it comes to the crunch - maintaining your application.
Its integration with web servers is abismal (or was early this year). We have some horrible scripts sitting around that clean up rogue semaphores periodically.
Performance wise, these suck - even compared to php.
We have moved back to java and are now deploying new apps in GWT, because we can deploy in tomcat and forget about it.
Yes, it's time for Rails to move out of the "hype cycle" (apologies to Gartner). I rant against some outspoken Rails fanatics as well as provide a screenshot of a Rails stack trace here: Who are these mongrel ruby developers?
The optimization and scaling problems with Rails are the same problems you encounter with any large enterprise-y application. No, it doesn't include connection pooling or prepared statements.
You know what the core team would say? "PDI" (Please Do Investigate)
You need connection pooling or prepared statements? Write it yourself, or find someone who can. All of those enhancements to Java frameworks didn't come out of thin air.
The concern of the core team is not to be everything to everyone, but to keep Rails small, beautiful, and easy to develop with. The community is working on the deployment issues, many of which have been helped by Capistrano and Mongrel (yes I've read your article, Peter, don't flame).
As far as Oracle is concerned, I think it's a sign that you practically need a consultant to run the thing that it might not be best for Rails; Rails promotes an intimate relationship between the developer and the database. Furthermore, of all of the database connectors, I've heard the most problems with Rails coming from those who use Oracle or SQL Server. That doesn't mean they won't eventually work, just that it may be premature to use Oracle. Postgres offers a lot of the same features if you need a DB for Rails, and it's free!
I agree with seanicus. Rails doesn't have as much infrastructure or installed base as Java. As such, its not good for all situations, and perhaps not ready for prime time in some enterprise applications.
There are other reasons to crow about Rails however. A big part is Ruby itself. Ruby > Java in a big way (for certain applications).
Ruby/Rails has obstacles in a Fortune 500 enterprise environment, no doubt. But if you're starting from scratch in a startup, its the only way to go.
Post a Comment