Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Are Ruby on Rails site usually slower than java or .net sites?
(This is assuming developers are not abusing the technology.)
A lot of Ruby sites I have seen have performance issues.
Yes, Ruby on Rails sites do have performance issues, just like any other site. And just like any other site, those performance almost always are rooted in architectural decisions, not the language or the framework.
There was a nice presentation a couple of years back by Joyent (might have been RailsConf 2007?), which showed on one slide all the servers that are running on a single instance of their Rails platform. About 40 processes. Only one of those processes was the Ruby interpreter, everything else was stuff like the DNS resolver, web server, database server, MTA, memcached, message queue, reverse proxy, load balancer, etc. Every single one of those can screw up your performance. That's a 97.5% chance that your performance problems have nothing whatsoever to do with Rails or Ruby.
There's some really nice E-Mails on the JRuby mailinglists, and also some Tweets and blog posts by people who rewrote their Java web applications in Ruby and got a 10% performance improvement.
A really good example is Twitter. Twitter is one of the biggest Ruby on Rails sites in the world. It is also one with a very unusual usage pattern that will give any framework that is designed for "normal" web applications a tough nut to crack.
Now, you might think, why did I choose Twitter of all things as an example of performance and scalabilit, when clearly it is the exact opposite that they are known for? Well, that's exactly the point: they have had a ton of scaling, performance and reliability problems. And not a single one of those had anything to do with Rails or Ruby. In fact, Rails and Ruby were pretty much the only pieces in their stack that they did not have problems with.
They had problems with unexpected growth. It doesn't matter which language or framework you use: if users are signing on faster than you can buy new servers, there is nothing you can do.
They had problems with the performance and scalability of MySQL. Again, MySQL has nothig to do with Rails or Ruby. In fact, MySQL is written in C, so if you really absolutely must make any ridiculous conclusion about a programming language, based solely on a single incident, then it would be this: C is slow. If you want performance, stay away from C.
(In this particular case, in one interview, they actually did blame Rails: they said that because Rails only supported a single connection to a single database, their MySQL instance simply got overloaded. Within hours of that interview being posted, two Rails developers independently of one another both released Rails plugins to implement multiple connections. The lesson is: only the 80% solutions are in the core. Twitter clearly isn't in the 80%. The plugin API is there for a reason.)
They had problems with the performance and scalability of the overall system. It turned out that, in order to get the product out quickly, they implemented absolutely no caching whatsoever. Even the "static" Twitter homepage was completely dynamically generated for every single request. Again, this had nothing to do with Rails or Ruby. You can bring any site down by turning off their caches, I guarantee you that.
They hit some very bad scalability problems (and the MySQL problems mentioned above are related to that) which were simply caused by the fact that people used the site in a way not anticipated by the developers. Everybody knows that Twitter is a micro-messaging platform. Well, except for the Twitter founders. They had this brilliant idea for a micro content management system.
And so, they did build a micro-CMS. And of course, the central piece of a content management system, is a content repository, IOW a database. Users however used Twitter as a micro-messaging platform. And the central piece of a messaging platform is a message queue.
As a result, MySQL was being used as a message queue. No two things could be further apart than a database (especially a SQL database) and a message queue. The two have almost exactly opposite requirements and constraints.
And of course, the entire architecture was built around that content repository which was now being abused as a message queue.
In response to that, the Twitter developers wrote their own message queue in Ruby, which helped performance and scalability a lot. But not enough. So, they wrote another message queue, this time in Scala.
It is this single rewrite that is wholly responsible for, I would estimate, at leat 70% of all the Rails FUD out there. But, I don't know about you: when I write something that I have absolutely no idea how to write it, and then I write the exact same thing a second time, when I actually do know what the heck I'm doing … the second one is always better than the first. And I suspect that this is the case here, too.
In several interviews, the Twitter developers have pointed out that Ruby on Rails was not responsible for their scaling problems. On the contrary, only the maintainability of Ruby made it possible to do such large-scale architectural changes to fix their scaling problems.
To cut a long story short: today, Twitter is actually using Ruby on Rails for what it was intended to be used: for a web application. And they use a database for storing data and not as a message queue. And they use an actual proper message queue. The message queue and some other backend stuff is written in Scala. The frontend is written in Ruby on Rails. Some stuff is written in C.
And all is peachy.
The real moral of the story here is that you can substitute pretty much any large web app, any language, any framework into the above story and it would still be true. MySpace is one of the slowest, most unreliable websites I know, and that is a .NET site. GitHub is one of the fastest websites I know, while being the biggest hosting platform (it has over a million repositories after just over 2 years, that's more than SourceForge and Google Code combined) and it is written in Ruby on Rails for the frontend, Sinatra for the web service, Ruby for the Git interfacing and Git infrastructure, Erlang for the federation and cloud infrastructure and Node.JS for the download server.
Here's a start
Scaling ROR
Why Rails can run slowly
Framework Preformance Comparison
SO related question
Related interest article Twitter abandons ROR its old I know but I didnt actually know that lol
Short answer
Could potentially sure.
Might be more likely than some other languages.
Depends on the application, the programmer and the architecture.
As I see it - RoR is only a bit slower. At least slower than .Net, cause ruby is interpreted language.
But in general - it depends on quality of developers. RoR app that uses nice caching will work n times faster than .net/java app that loads half database into memory and sends plenty database requests cause of select n+1.
yes it is slower, but in production it will probably only hurt you once your load "exceeds a certain point" ("x requests/sec") and most sites never see more load than that.
Related
I have some (I think) really great ideas for an online strategy game similar to Travian. There's some content that I haven't yet figured out and some other challenges that I don't know of yet.
This is quite a big project and perhaps too heavy for one person that isn't a skilled web developer (yet). I'd still like to give it a shot, but I'm having trouble choosing a platform. The world "scales" has been thrown around a lot lately and I've seen Ruby on Rails being bashed because it doesn't scale well, so I've come here to get some answers.
I like Ruby on Rails, both Ruby and Rails. I'm certainly no expert at it but I love working with it. I have also worked with Python + Django before and also with PHP (which I am not fond of.)
Ideally the game would have, let's say, 7000 players per server, presumably a lot of data to be processed per second. Would RoR still be a viable platform?
I'm sorry if this question is vague, I guess I'm looking for a "RoR is fine, go at it!" kind of answer. Anything you might want to add is fine.
Thanks!
So if I were you, I would be looking into non-blocking servers like node.js, just because they are MUCH more suited to keeping many connections open for long periods of time, which is what games need to do, compared to traditional web servers.
That being said
There are 3 main things to worry about when you are scaling a web app; memory, execution speed, and io (hd and network) in that order.
For memory, things are much better then they used to be. Phusion Passenger uses copy on write to fork its workers, so the rails environment will get shared among all the workers on a given slice, which is pretty significant. There have also been huge improvements to the way ruby manages memory compared to "the dark times", if you are using 1.8.7 then you want to be using the patches that make up Ruby Enterprise Edition (the difference is like night and day). 1.9.x was pretty much a total rewrite of the runtime, so if you are using that the memory issues ruby had have already been addressed.
For execution speed, 1.8.7 is typically "fast enough" (at least after tuning garbage collection settings). 1.9.2 is actually around the same speed as python, which puts it on the faster side of interpreted languages. How important this point is completely depends on the nature of your application.
Last point is IO, which isn't really a concern of rails, but more your persistence strategy. Rubyists tend to love new things, so you will find first class support for things like redis and mongodb, with loads of people talking about using them and their wins/gotchas. I would look into mongo if I were you and see if the durability trade-offs are acceptable.
I was in java/.net before going to rails, and at the end of the day you are going to pay more for infrastructure, but the amount will be completely dwarfed by what you save in development time.
build it in Rails, host it on Heroku.com - job done. Almost infinite scaling that you don't have to worry about how it works (it just does) and it hosts a lot of highly trafficked Facebook apps so can more than handle it.
I think Ruby on Rails is a good choice for what you need. Actually, we recently created a platform for an online gaming tournament, where players and their gaming bots were playing a logic game.
We used Ruby on Rails and Sidekiq on the backend, ReactJS and WebSocket on the frontend. And it worked well for a quite massive number of players. Here is the tutorial based on what we learnt while building it: How to Write a Game Engine Using Ruby on Rails
As you said yourself, you already have the answer and you are only looking for encouraging words:). I am not RoR expert myself, but I don't think scalability is still such a great issue on this platform. I would advice you to do an architecture spike (XP terminology). Write a test with 7000 clients and method which would perform similar operations to what you intend to create. For example you might load files, render views or even just wait... The point is to test only the thing you are worried about. Good luck!
This is a bit of an impossible question to answer because in order to know whether rails is suitable for what you want to do we would need to a lot more about what you are trying to do. The best advice I can give in the absence of information is for you to check out the railslab scaling videos in order to work it out for yourself.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Hi I'm looking to write a multiplatorm tasks application for technical people. I want to handle as many platforms as I can (web, shell, desktop) and therefore I have decided to begin with a server/API.
I want to write it in Ruby, however i think that Rails is a bit too heavy for this, even though it would do the job. Sinatra also doesn't seem quite suited for the task.
All the server/API would do would be to translate simple requests to Database queries, and at a later stage some authentication and authorization.
So basically I want to know:
1) Should I use a REST api or a SOAP api?
2) Is there a framework for this? Or what is the closest framework avalable?
For the adventurous, there is also a less known project called grape. It is a rack based application, similar to Sinatra, but is only purposed to write API. I don't think it is mature enough to be used in serious projects yet, but it is still interesting to know.
1) REST, SOAP is a terrible system and its support in Ruby is quite lacking. REST, on the other hand, is basically the ruby default and takes very little effort to use, especially if you are using REST/JSON.
2) Sinatra and Rails are basically your options. It comes down to how complex this application will be. Sinatra can probably handle the task just fine, but Rails does much of the work for you at the expense of bloat. You will already be taking on some of the rails bloat if you use ActiveRecord for the database. When authentication and/or roles come into play, Rails has mature solutions for both. Without any additional information, I'd lean towards Rails as it does much of the work for you and, when written properly, can still be fairly fast.
Actually SOAP is very VERY easy to implement with AWS.
At the same time, REST API is also very easy to implement.
I have written a couple of different and parallel (JSON, XML and custom format) APIs with rails. Im sure the framework stack performance will not be your bottleneck, so don't bother with worrying about performance just yet. Your first bottleneck will anyhow be database and then perhaps requests per second.
All in all i would suggest going with Rails, it has a lot of work cut out for you.
Since this old thread still comes up high on related Google searches, I should chip in my highly biased (as co-author and user) recommendation for Hoodoo. Unlike other offerings, Hoodoo includes an API specification that says how API calls must be made and how they must respond; it enforces a consistency across your design that calling clients will appreciate. If you can call one API, you can call them all. Hoodoo implements a lot of the boilerplate so you can focus on meaningful service code.
We've been using Hoodoo services for over two years very successfully at Loyalty New Zealand, who run the country's largest loyalty programme. Our Hoodoo-based microservice platform handles 100% of our client transactions.
http://hoodoo.cloud/
https://github.com/LoyaltyNZ/hoodoo
https://github.com/LoyaltyNZ/hoodoo/tree/master/docs/api_specification
https://github.com/LoyaltyNZ/service_shell
Hoodoo has 100% non-trivial rspec test coverage and 100% rdoc documentation coverage. As you'll see from the above links, there's quite a lot there!
Hoodoo is a Rack application, so works with any Rack compatible web server. Our preferred deployment mechanism though is an indefinitely horizontally scalable arrangement based on an HTTP-over-AMQP bridge and an AMQP cluster of nodes each running the same collection of services, managed inside Docker containers and deployed with Fleet. The system self-load balances across the service nodes via the queue and the decoupling of front end HTTP->AMQP processor versus the AMQP->HTTP input into the Rack stack dramatically reduces the system's attack surface. We wrote the front-end component in Node and for more about this along with Node implementations of other parts of the framework concept, see the Alchemy Framework. Alchemy Node services and Hoodoo Ruby services can coexist on the same grid happily.
I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.
We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.
After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:
So I thought it would be about time to
set the record straight on a number of
unfounded fears, uncertainties, and
doubts. I'll be going through these
myths one at the time and showing you
exactly why they're just not true.
This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn't
founded in the many myths floating
around.
Let's Clarify!
Myth: "Ruby on Rails doesn't scale"
Bust: That is not a specific, answerable question. Please clarify.
Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:
"What precisely do you mean by 'scale'? and how do you measure it at the moment?"
It could mean:
Maximum user sessions
Average response time given load
Throughput of given concurrent scenarios per server in a fixed time.
... difficulties organising the project so a large team of developers could work on it.
There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.
There are loads of ruby-based solutions, including
caching fragments of HTML
sharding the application across multiple databases
pre-computing work that's shared between users
pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
using a front-end web server more efficiently
just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
doing less interactively and having more batch work
doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend
If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.
However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.
Make the argument from the only perspective the client understands, money!
Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.
In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:
1) Why Rails?
Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)
http://www.theserverside.com/news/thread.tss?thread_id=33120
2) Rails doesn't scale
http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html
3) Rails is just a CMS?
If they are building a CMS then recommend Drupal, not Rails
I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job
Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.
Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.
Myth: it is hard to hire a good Ruby on Rails programmer.
(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)
I'm a big fan of ruby on rails, and it seems to incorporate many of the 'greatest hits' of web application programming techniques. Convention over configuration in particular is a big win to my mind.
However I also have the feeling that some of the convenience I am getting is coming at the expense of technical debt that will need to be repaid down the road. It's not that I think ROR is quick and dirty, as I think it incorporates a lot of best practices and good default options in many cases. However, it seems to me that just doesn't cover some things yet (in particular there is little direct support for security in the framework, and plugins that I have seen are variable in quality).
I'm not looking for religious opinions or flamewars here, but I'd be interested to know the community's opinion on what areas Rails needs to improve on, and/or things that users of Rails need to watch out for on their own because the framework won't hold their hand and guide them to do the right thing.
Regardless of framework the programmer needs to know what she's doing. I'd say that it's much easier to build a secure web application using something as mature, well designed and widely adapted as Ruby on Rails than going without the framework support.
Take care with plugins and find out how they work (know what you do, again).
I love Rails too, but its important for us to understand the shortcomings of the framework that we use. Though it might be a broad topic addressing these issues wont hurt anyone.
Aside from security issues, one other big issue is DEPLOYMENT on Shared Hosts. PHP thrives in shared hosting environments but Rails is still lagging behind.
Of course most professional Rails developers know that their apps need fine-tuned servers for production and they will obviously deploy on Rails-Specific hosts.
In order for Rails to continue success the core team should address this issue, especially with Rails 3.0 (Merb +Rails) coming..
An example of this is simple: I have a bluehost account, and i noticed the Rails icon in my cpanel. I talked to the bluehost support and they said its more or less a dummy icon, and that it doesn't function properly.
Having said that any professional who wanted to deploy a Rails App would not use bluehost. , but it does hurt Rails, when hosts say that they support it and then users run into problems which their support know nothing about..
The article you refer to defines technical debt as
[the] eventual consequences of
slapdash software architecture and
hasty software development
With rails, any development that is not test driven incurs technical debt. But that is the case with any platform.
At an architectural level Rails provides some deployment challenges. A busy site must scale with lots of hardware or use intelligent caching strategies.
My advice to anyone adapting Rails would be to:
use TDD for all your development
verify the quality off any plugin
you use by reading its tests. If
they are not clear and complete,
avoid the plugin
read "Rails
Recipes" and "Advanced Rails
Recipes" (Advanced Rails Recipes has
a good recipe for adding
authentication in a RESTful way)
be prepared to pay for hardware to scale your site (hardware is cheaper than development time)
From my experience, by far the biggest tolls you end up paying with RoR are:
Pretty big default stack (not counting plugins you might be using)
Updating models tends to be a pain in the ass, at least in production servers.
Updating Rails or Ruby themselves is a bit more complicated than it should, but this differs depending on your server setup.
As ewalshe mentioned, deployment is sometimes a drag, and further down the road, should you require it, scaling gets a bit iffy, as it does with most development frameworks.
That being said, I'm an avid user of RoR for some projects, and with the actual state of hardware, even though you do end up paying some tech debt to using it, it's almost negligible. And one can hope these issues will be reviewed eventually and solved.
With any level of abstraction there is a bit of a toll you pay - genericized methods aren't quite as fast as those specific to something built just for your purpose. Fortunately though, it's all right there for you to change. Don't like the query plans that come out of the dynamic find methods? write your own, good to go.
Someone above put it well - hardware is cheaper than developers. I'd add "at a sufficiently low amount of hardware"
I'm reading Deploying Rails Applications and recommend it highly to answer your concerns.
The book is full of suggestions to make life easier, taking a deployment-aware approach to your Rails development from scratch, rather than leaving it to later.
I don't think the choice of RoR implies a technical debt but just reading the first few chapters alerted me to practices I should be following, particularly on shared hosts, such as freezing the core rails gems so you can't be disrupted by upgrades on the host.
The 30-page chapter on Shared Hosts includes memory quote tips such as using multiple accounts (if possible) with one Rails app per account. It also warns about popular libraries such as RMagick possibly pushing your memory size to the point where your processes are killed (such as a 100MB limit, which it suggests some hosts periodically apply).
I have a memory of talking to people who have got so far in using Ruby on Rails and then had to abandon it when they have hit limits, or found it was ultimately too rigid. I forget the details but it may have had to do with using more than one database.
So what I'd like is to know is what features/requirements fall outside of Ruby on Rails, or at least requires such contortions that it is better to use another more flexible framework, even though you may have to lose some elegance or write extra boilerplate code.
Rails (not ruby itself) is proud to be "Opinionated Software".
What this means in practice is that the authors of rails have a certain target audience in mind (themselves basically) and aim rails specifically at that. If X feature isn't needed for that target audience, it doesn't get added.
Off the top of my head, things that rails explicitly doesn't support that people may care about:
Foreign keys in databases
Connections to multiple DB's at once
SOAP web services (since rails 2.0)
Connections to multiple database servers at once
That said, it is very easy to extend rails with plugins, and there are plugins which add all of the above functionality to rails, and a lot more, so I wouldn't really count these as limits.
The only other caveat is that rails is built around the idea of creating CRUD web applications using MVC. If you're trying to do something which is NOT a CRUD web app (like twitter, which is actually a messaging system, or if you are insane and want to use a model like ASP.NET webforms) then you will also encounter problems. In this case you're better off not using rails, as you're essentially trying to build a boat out of bicycle parts.
In all likelihood, the problems you will run into that can't just be fixed with a quick plugin or a day or 2 of coding are all inherent problems with the underlying C Ruby runtime (memory leaks, green threads, crap performance, etc).
Ruby on Rails does not support two-phase commits out of the box, which maybe required if your database-backed application needs to guarantee immediate consistency AND you need to use two or more database schemas.
For many web applications, I would venture that this is not a common use-case. One can perfectly well support eventual consistency with two or more databases. Or one could support immediate consistency with one database schema. The former case is a great problem to have if your app has to support a mondo amount of transactions (note the technical term :). The latter case is more typical, and Rails does just fine.
Frankly, I wouldn't worry about limits to using Ruby on Rails (or any framework) until you hit real scalability problems. Build a killer app first, and then worry about scalability.
CLARIFICATION: I'm thinking of things that Rails would have a hard-time supporting because it might require a fundamental shift in its architecture. I'll be generous and include some things that are part of the gem/plugin ecosystem such as foreign key enforcement or SOAP services.
By two-phase commits, I mean attempting to make two commits to physically distinct servers within one transactional context.
Use case #1 for a two-phase commit: you've clustered your database, so that you have 2 or more database servers and your schema is spread across both servers. You may want to commit to both servers, because you want to allow ActiveRecord think do a "foreign key map" that traverses across the different servers.
Use case #2 for a two-phase commit: you're attempting to implement a messaging solution (sorry, I'm J2EE developer by day). The message producer commits to the messaging broker (one server) and to the database (a different server).
Also found some good discussion about the limits of ActiveRecord.
I think there is a greater “meta-question” here, that could be answered and that is “when is it OK to lean on external libraries to speed up development time?”
Third party libraries are often great and can drastically reduce development time, however there is a major problem, Joel Spolsky calls this “the law of leaky abstractions.” If you look that up on Google his post will come up first. Essentially this means that the trade off in development time means that you have no idea what is going on under the covers. So when something breaks you are completely stuck and have very limited methods of debugging. This also means that if you hit one of the features that are simply unsupported in RAILS, that you really need, you’ll have no next step except to write the feature yourself, if you’re lucky. Many libraries can make this difficult to do.
We’ve been burned badly in my dev shop by this issue. Our solutions worked fine under normal load, but we found that the third party subscription libraries that we were using simply could not stand up to the kind of load that we experienced once our site started to get a large number of concurrent users. This puts us in a very difficult place; essentially we have to rewrite the entire subscription service ourselves, with performance in mind. Doing this means that we’ve wasted all the time that we spent using the library.
Third party libraries can be great for small to medium sized applications; they can drastically reduce development time and hide complexities that aren’t necessary to deal with in the early stages of development. However eventually they will catch up with you and you’ll likely have to rewrite or re-engineer your solution to get past the “law of leaky absctractions”
Ruby don't have a functionality like IsPostBack in ASP.Net
Orion's answer is right on. There are few hard limits to AR/Rails: deploying to Windows, AR connectors that aren't frequently used, e.g. Firebird, ), but even the things he mentioned, multiple databases and DB servers, there are gems and plugins that address those for legacy, sharding, and other reasons.
The real limitation is how time-consuming it is to keep on top of all the things that rails devs are working on, and researching specific issues, given how many blogs, and how much mailing list volume there are.