What are the cons of using rails?

Rails
41

On Thu, 2006-08-17 at 18:41 -0400, heri rakotomalala wrote:

or 43things and they reckon it could be faster. they don’t know about
database or RAM problems or processing power. and you agree with me
that users have the ultimate word.

i just know that rails talks a lot. for example, it needs at least a
‘show fields’ commands for each request. sessions slows the website
down unless you have memcache, which needs lots of RAM, so people
cannot use sessions for personal websites. i don’t know also where the
speed is lost, maybe in routes.rb, in dispatch …i don’t know.

There’s this concept I have called “tuning density”. It’s basically the
point at which changing the implementation of the design doesn’t buy you
any more performance, and the only thing left is to redesign. Even this
hits a certain tuning density when no design makes the application
faster, and the only thing left is to change to a faster platform. This
continues until you just cannot make it faster without a change in how
the universe works.

You can usually spot when you’re at the tuning density of a system when
the effort to increase it’s speed is greater than the performance gain
you get. At this point you have to look for alternative ways to make
the system faster or get deeper in the rabbit hole and do a complete
redesign.

I also say that tuning density is different from a bottleneck as it’s
not a single identifiable performance killer, but just a factor of how
the system is implemented. Changing it involves a complete rethinking
of the application so you’re stuck finding an alternative solution if
you can’t make the change.

My opinion is that Rails is at it’s tuning density. Folks like Stefan
Kaes and myself (indirectly) have been pounding on it in an attempt to
make it faster, but the effort just doesn’t match the gains. I think
this is a combination of two factors:

  1. Biggest limiting factor is that Rails isn’t thread safe, so it has
    to be locked. Changing this though would involve a major redesign
    (thus, it’s the current tuning density cause I think).
  2. Ruby itself has such poor IO facilities and other processing limits
    that only a magical complete rewrite or getting rails to run on
    something else will improve things. I know most people yell and scream
    that I’m an idiot when I point out the emperor has no clothes, but
    remember I’m writing a web server AND client. The people yelling aren’t
    even nearly as close to this as I am.

My suggestion right now is that you can’t do anything about the above
two short of getting in there and fixing the problem yourself or trying
your app on something like jruby or the latest ruby 1.9 vm.

What you must focus on–especially if your performance problem is
based on user perception–is how to make your application seem faster
to the users. This involves less mucking with code and more observation
and measurement of what users think. People are visually pretty dumb,
so you’d be amazed at what little stupid tricks you can do to simply
make them believe your stuff is quick.

Just remember, humans don’t have a stop watch embedded in the side of
their skull with nanosecond accuracy. For them, it’s how they think
about their experience that makes the difference.

Finally, I’d say that the most annoying thing I get from rails coders is
“potpourri turd syndrome” when it comes to performance. This is where
they assume whatever crap they slapped into their actions is golden and
smells like flowers, and therefore it must be [mongrel, ruby, rails,
etc.]. Before you go screaming at the performance of rails, do what I
did and quadruple check that it’s not your code messing things up or
running slow.

You wouldn’t believe how many times I’ve talked to someone with a
problem, and then upon looking at their code find out that they’re doing
something stupid. Not to mention, how many times I’ve had the same
person argue with me that their code is fine before finally having to
admit it’s crap.

Anyway, hope that gives some food for thought.

–
Zed A. Shaw

http://mongrel.rubyforge.org/
http://www.railsmachine.com/ – Need Mongrel support?

42

Andreas S. wrote:

Joe R. wrote:

Eleo wrote:

Aren’t there like a bazillion benchmarks showing that Ruby is one of the
slowest, if not THE slowest language out there? And if Ruby is slow,
isn’t it fairly logical to assume Rails is just as slow if not slower?
Obviously Rails could out-perform PHP if the PHP code were crap, but I
think it’s safe to assume the most generally a Rails app is slower than
a PHP app doing the same thing.

Tests I’ve seen show about a 3-5% performance penalty. But then Ruby
does better on memory. At any rate – BIG DEAL (except for trolls).

Ruby might do better on memory than PHP, but Ruby on Rails definitely
doesn’t. My FastCGI PHP processes each use about 5-6 MB RAM (+10 MB
shared), with eAccelerator and big applications like Mediawiki. My Rails
LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40
(almost no shared memory used). And don’t forget that you need multiple
processes for each Rails appication, whereas you can host any number of
applications with just one set of PHP processes.

Shrug. Memory’s cheap. And it probably equals out with Apache being a
big memory hog compared to Lighty and Mongrel.

Joe

43

Joe R. wrote:

Eleo wrote:

Aren’t there like a bazillion benchmarks showing that Ruby is one of the
slowest, if not THE slowest language out there? And if Ruby is slow,
isn’t it fairly logical to assume Rails is just as slow if not slower?
Obviously Rails could out-perform PHP if the PHP code were crap, but I
think it’s safe to assume the most generally a Rails app is slower than
a PHP app doing the same thing.

Tests I’ve seen show about a 3-5% performance penalty. But then Ruby
does better on memory. At any rate – BIG DEAL (except for trolls).

Ruby might do better on memory than PHP, but Ruby on Rails definitely
doesn’t. My FastCGI PHP processes each use about 5-6 MB RAM (+10 MB
shared), with eAccelerator and big applications like Mediawiki. My Rails
LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40
(almost no shared memory used). And don’t forget that you need multiple
processes for each Rails appication, whereas you can host any number of
applications with just one set of PHP processes.

44

Using more or less memory isn’t a good measure. PHP shares memory across
many sessions, since Ruby doesn’t. PHP also has a lot of things Ruby
doesn’t
have itself… (also not a good measure: lots of things that the 3% of
the
developers use but still in our memory)

Don’t test Ruby with PHP on CentOS, Fedora or another ones. The more
modules
has PHP, more memory uses. I compiled it just with PostgreSQL extension
(leaving XML and a lot of stuff I won’t use), and it is very fast.

About Rails, yeah, but… how much work does it take to have a website
with
the same interactivity as a Rails generated one? Rails runs on top of
Ruby,
but there are another frameworks written in PHP which run on top of
their
functions that are finally the functions that run on top of PHP. The
more
layers you add (supposing that those don’t discriminate between
model-view-controller like Rails do) the more complex is to debug the
entire
Rails site. Let’s take any CMS. The bug appears one day and a week after
it
has been patched and no one noticed it. Let’s take Rails 1.1.4, how much
time did it take to be patched?

I am not in conditions to run a fine-tuned Rails site, because I know I
still have very much to learn about it. But if someone wants to do it, I
offer my time and knowledge about PHP to fine-tune an application on top
of
it and lets see which one is better, measuring:

1.- usability
2.- accesibility
3.- resources utilized

any other items?

Right now I am building an Intranet with it, while the clients platform
is
in PHP and the documentation interface is in .NET… Nothing hard, but
Rails
give me the enough time to implement more and more things.

BTW, nice ideas.

45

Andreas S. wrote:

Joe R. wrote:

Andreas S. wrote:

Joe R. wrote:

Eleo wrote:

Aren’t there like a bazillion benchmarks showing that Ruby is one of the
slowest, if not THE slowest language out there? And if Ruby is slow,
isn’t it fairly logical to assume Rails is just as slow if not slower?
Obviously Rails could out-perform PHP if the PHP code were crap, but I
think it’s safe to assume the most generally a Rails app is slower than
a PHP app doing the same thing.

Tests I’ve seen show about a 3-5% performance penalty. But then Ruby
does better on memory. At any rate – BIG DEAL (except for trolls).

Ruby might do better on memory than PHP, but Ruby on Rails definitely
doesn’t. My FastCGI PHP processes each use about 5-6 MB RAM (+10 MB
shared), with eAccelerator and big applications like Mediawiki. My Rails
LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40
(almost no shared memory used). And don’t forget that you need multiple
processes for each Rails appication, whereas you can host any number of
applications with just one set of PHP processes.

Shrug. Memory’s cheap.

Think of shared hosting. With PHP you can put any number of websites on
one server, the only thing that matters is the total number of hits the
sites get. With Rails you need at least one process per site constantly
running, or the startup time will make the response unacceptably slow.

Well, yeah, processes are segmented according to site (which is probably
a good thing), but still with Apache and PHP, each connection needs an
Apache process, which has a PostgreSQL/MySQL connection.

Joe

46

Joe R. wrote:

Andreas S. wrote:

Joe R. wrote:

Eleo wrote:

Aren’t there like a bazillion benchmarks showing that Ruby is one of the
slowest, if not THE slowest language out there? And if Ruby is slow,
isn’t it fairly logical to assume Rails is just as slow if not slower?
Obviously Rails could out-perform PHP if the PHP code were crap, but I
think it’s safe to assume the most generally a Rails app is slower than
a PHP app doing the same thing.

Tests I’ve seen show about a 3-5% performance penalty. But then Ruby
does better on memory. At any rate – BIG DEAL (except for trolls).

Ruby might do better on memory than PHP, but Ruby on Rails definitely
doesn’t. My FastCGI PHP processes each use about 5-6 MB RAM (+10 MB
shared), with eAccelerator and big applications like Mediawiki. My Rails
LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40
(almost no shared memory used). And don’t forget that you need multiple
processes for each Rails appication, whereas you can host any number of
applications with just one set of PHP processes.

Shrug. Memory’s cheap.

Think of shared hosting. With PHP you can put any number of websites on
one server, the only thing that matters is the total number of hits the
sites get. With Rails you need at least one process per site constantly
running, or the startup time will make the response unacceptably slow.

And it probably equals out with Apache being a
big memory hog compared to Lighty and Mongrel.

Apache a memory hog compared to Mongrel? Absolutely not. Anyway, nobody
forces you to use PHP with Apache, it works just as well with Lighttpd,
Litespeed etc.

47

Think of shared hosting. With PHP you can put any number of websites on
one server, the only thing that matters is the total number of hits the
sites get. With Rails you need at least one process per site constantly
running, or the startup time will make the response unacceptably slow.

Php is a particular case. Compare rails to other frameworks written
in interpreted/byte compiled languages and it compares about the same.
rails/mod perl/mod python/jboss are all frameworks built on top of a
general purpose programming language. Most of the functionality of
the frameworks use modules/libraries that are coded in the language
the framework is built on , plus the memory footprint of the language
itself, whatever that is. Comparing php to these other frameworks
isn’t really fair. The similarities are only skin deep.

48

snacktime wrote:

Think of shared hosting. With PHP you can put any number of websites on
one server, the only thing that matters is the total number of hits the
sites get. With Rails you need at least one process per site constantly
running, or the startup time will make the response unacceptably slow.

Php is a particular case.

Yes, but it can be compared.

Compare rails to other frameworks written
in interpreted/byte compiled languages and it compares about the same.

The only other thing I’ve got here to compare with is tracd, it uses
9MB.

I’m often wondering: what is all this RAM actually used for, e.g. the
30-40 MB of Mongrel+Rails? Is it object data, is it code, …? Can
anyone of the Ruby experts (Zed?) give me some insight?

49

Joe R. wrote:

Andreas S. wrote:

Think of shared hosting. With PHP you can put any number of websites on
one server, the only thing that matters is the total number of hits the
sites get. With Rails you need at least one process per site constantly
running, or the startup time will make the response unacceptably slow.

Well, yeah, processes are segmented according to site (which is probably
a good thing), but still with Apache and PHP, each connection needs an
Apache process, which has a PostgreSQL/MySQL connection.

That’s the worst case setup. But it’s not really that expensive to fork
a new Apache/mod_php process. After the fork most of the memory is
shared, and a lot of it stays shared for the lifetime of the process. An
interesting effect with Rails is that after a fork (LSAPI uses fork to
create Rails listeners) the shared memory drops to almost zero after a
few requests are handled.

50

On Fri, 2006-08-18 at 01:49 +0200, Andreas S. wrote:

does better on memory. At any rate – BIG DEAL (except for trolls).

Ruby might do better on memory than PHP, but Ruby on Rails definitely
doesn’t. My FastCGI PHP processes each use about 5-6 MB RAM (+10 MB
shared), with eAccelerator and big applications like Mediawiki. My Rails
LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40
(almost no shared memory used). And don’t forget that you need multiple
processes for each Rails appication, whereas you can host any number of
applications with just one set of PHP processes.

Wow, is that all? Try Java sometime. I’ve got a very simple little app
running on Tomcat and IBM JDK that’s just translating SOAP calls to XML.
The thing uses about 306m virt, 71m res, 2304 shr memory, and it can
spike to 150m res before I have to kill it. Worst part is all this
thing does is run 10 jsps. And this was after trying the Sun JDK which
is much worse. It was so bad I couldn’t run the app on our VPS.

When it comes to RAM usage Java is king of all destruction.

–
Zed A. Shaw

http://mongrel.rubyforge.org/
http://www.railsmachine.com/ – Need Mongrel support?

51

On Fri, 2006-08-18 at 03:20 +0200, Andreas S. wrote:

snacktime wrote:
I’m often wondering: what is all this RAM actually used for, e.g. the
30-40 MB of Mongrel+Rails? Is it object data, is it code, …? Can
anyone of the Ruby experts (Zed?) give me some insight?

Not sure at all as I haven’t looked into it. For me 40M is a dream
compared to the monstrosity systems Java inspires.

–
Zed A. Shaw

http://mongrel.rubyforge.org/
http://www.railsmachine.com/ – Need Mongrel support?

52

Zed S. wrote:

  1. Ruby itself has such poor IO facilities and other processing limits

Can you elaborate on these limits? I’m not at all familiar with them.

Thanks,
Joe

53

On Thu Aug 17, 2006 at 11:04:39PM -0700, snacktime wrote:

  1. Biggest limiting factor is that Rails isn’t thread safe, so it has
    to be locked. Changing this though would involve a major redesign
    (thus, it’s the current tuning density cause I think).

Is it unsafe all over or just in particular parts like AR?

http://permalink.gmane.org/gmane.comp.lang.ruby.mongrel.general/245

54

http://permalink.gmane.org/gmane.comp.lang.ruby.mongrel.general/245

That’s scary.

55

Other problems ruby/rails has, and the reasons I honestly cannot
recommend rails to be used for anything but personal projects.

a) The rails code-base is not stable. Version 1.2 might very well break
existing applications and require a newer version of ruby. Of course the
solution would be to stick with the original version of rails… However
this is not always practical.

b) In connection with a), I cannot even remotely guess where rails will
be in a year from now. For example there has been talk of removing the
webservices api from the rails codebase. (Yes it is then said to be
further developed as a plugin, but for how long? There are already great
rails 1.0 plugins which ceased to be compatible with 1.1)

c) Not enough ruby-programmers. It is simply too risky for a company to
depend on one or two experienced ruby/rails programmer to take care of
their website, which most often is there primary source of income. What
if their web guru ceased to exist for some reason? A new php/java/.net
and even python developer is easier to find than one experienced with
ruby/rails.

d) Ruby. Not so much because its notorious slowness but because its
lack of more advanced libraries or c-bindings. However this seems to be
slowly improving, yet most ruby libraries have the tendency not to be
maintained once its author is satisfied. This, again, does not bode well
for future use. (For example an opensrs library, lucene API (but
admittedly, ruby now has ferret) and ta-lib api would be welcome).
However ruby is rather easy to extend. But having to code these
library-bindings myself kind of mitigates rails largest advantage, fast
to develop with. (Itâ??s still fast, but you need to develop more)

a) and b) are imho the more serious issues. I imagine it is the result
of this so called â??opinionated softwareâ?, but a lead developer that
tells its softwareâ??s users that have certain, legitimate, issues to
â??shove itâ?… Well… imho it doesnâ??t bode well for â??stableâ? future
versions of that software. (stable as in (backwards) compatible,
smoothing issues users have)

56
  1. Biggest limiting factor is that Rails isn’t thread safe, so it has
    to be locked. Changing this though would involve a major redesign
    (thus, it’s the current tuning density cause I think).

Is it unsafe all over or just in particular parts like AR?

Chris

57

Rodrigo F. wrote:

read changelogs of PHP, Python, Perl and TODO’s. The only entirely
stable
language is Java, which sucks a lot in particular environments, apart of
being very hard to write something in there.

b) In connection with a), I cannot even remotely guess where rails
will

be in a year from now. For example there has been talk of removing the
webservices api from the rails codebase. (Yes it is then said to be further
developed as a plugin, but for how long? There are already great rails 1.0plugins which ceased to be compatible with
1.1)

All good points Rodrigo, but I think that Java is far from stable.

Each of the last three clients I worked at were migrating from 1.2x to
1.4x, even though 1.5 has been out for more than a year.

The large banks and insurance companies I contract at do this to ensure
stability. They won’t support multiple versions, so they stay way behind
the curve on their upgrade path. They won’t even start completely new
projects with 1.5, until they start their migration to 1.5.

So it seems that businesses interested in stability of language treat
Java the same way they would treat Ruby. We’ll upgrade when we are
convinced none of our systems will break. That goes for Java, Ruby, or
even COBOL. (yes they treated the upgrade from IBM COBOL II to IBM COBOL
390 on the mainframe just like they treat upgrading Java).

So it seems the original poster’s complaints come down to “Ruby on Rails
has the same exact problems as every other language and framwork have.”

Thanks Rodrigo

58

2006/8/18, Colin Cc [email protected]:

Other problems ruby/rails has, and the reasons I honestly cannot
recommend rails to be used for anything but personal projects.

a) The rails code-base is not stable. Version 1.2 might very well
break existing applications and require a newer version of ruby. Of course
the solution would be to stick with the original version of rails… However
this is not always practical.

read changelogs of PHP, Python, Perl and TODO’s. The only entirely
stable
language is Java, which sucks a lot in particular environments, apart of
being very hard to write something in there.

b) In connection with a), I cannot even remotely guess where rails
will

be in a year from now. For example there has been talk of removing the
webservices api from the rails codebase. (Yes it is then said to be further
developed as a plugin, but for how long? There are already great rails 1.0plugins which ceased to be compatible with
1.1)

having a small core is not a bad idea. faster, loads modules in
execution
time instead of loading in startup like PHP does. But, as I say, read
changelogs.

c) Not enough ruby-programmers. It is simply too risky for a
company

to depend on one or two experienced ruby/rails programmer to take care of
their website, which most often is there primary source of income. What if
their web guru ceased to exist for some reason? A new php/java/.net and even
python developer is easier to find than one experienced with ruby/rails.

here in my country, .NET and Java are very popular… but PHP gurus…
and
Python gurus… and Rails!!!

d) Ruby. Not so much because its notorious slowness but because
its

lack of more advanced libraries or c-bindings. However this seems to be
slowly improving, yet most ruby libraries have the tendency not to be
maintained once its author is satisfied. This, again, does not bode well for
future use. (For example an opensrs library, lucene API (but admittedly,
ruby now has ferret) and ta-lib api would be welcome). However ruby is
rather easy to extend. But having to code these library-bindings myself kind
of mitigates rails largest advantage, fast to develop with. (It’s still
fast, but you need to develop more)

can’t say anything about Ruby.

a) and b) are imho the more serious issues. I imagine it is the result

of this so called “opinionated software”, but a lead developer that
tells its software’s users that have certain, legitimate, issues to
“shove it”… Well… imho it doesn’t bode well for “stable” future
versions of that software. (stable as in (backwards) compatible,
smoothing issues users have)

the most serious you have aren’t particular from Ruby, even .NET has
those
things.

Nice catch, try again.

59

sean lynch wrote:

developed as a plugin, but for how long? There are already great rails 1.0plugins which ceased to be compatible with
projects with 1.5, until they start their migration to 1.5.
The large banks and insurance companies I work for use WebSphere, and
until version 6.1 and its associated toolset arrives and they fully
understand the implications of moving to it, they can’t start moving
to Java 1.5. (WebSphere 6.1 is out, but the corresponding version of the
Rational Application Developer toolset is not out yet.)

So it seems that businesses interested in stability of language treat
Java the same way they would treat Ruby. We’ll upgrade when we are
convinced none of our systems will break. That goes for Java, Ruby, or
even COBOL. (yes they treated the upgrade from IBM COBOL II to IBM COBOL
390 on the mainframe just like they treat upgrading Java).

And so Sun, IBM, and BEA support multiple versions of their application
servers, JVMs, Java class libraries and tools concurrently. If a fix is
needed, it will be made available for all affected versions that are
still under support. The same is true for DBMSs, whether commercial or
open-source.

So it seems the original poster’s complaints come down to “Ruby on Rails
has the same exact problems as every other language and framwork have.”

No, in that fixes (with the possible exception of source patches) are
only being provided for the latest version of Rails.

I just took a look to check on the PHP situation, and found:

“[17-Aug-2006] The PHP development team would like to announce the
immediate availability of PHP 5.1.5 and 4.4.4. These two releases
address a series of security problems that were discovered since the
release of PHP 5.1.4 and 4.4.3.”

Given that AWDR version 1 is still selling, and must be approaching the
50,000 copy mark, it would have been great if a version of Rails existed
that was fully in line with the book and was actively being supported
with bug fixes. (Of course, since Rails is open source, anybody who
cares enough could do this, but installing the “book version” would
require information on where to get it that is currently not in the
book.)

So far as Ruby is concerned, is anyone else bothered that Ruby is
written in pre-ANSI (K&R) C?

I think that Ruby and Rails are truly great, but there are always things
that could be improved.

regards

Justin

60

It’s all OK with everything we said here, different points of view and
everything.

About performance stuff, there’s nothing to do with it.
(Mis)configurations
have a special role here, security and webserver configuration also have
important roles. Code being managed or unmanaged have important roles
such
when it’s about multiplatform. .NET is managed and Ruby too, but .NET is
platform-specific so it has many tweaks to work as expected. .NET hasn’t
many changes in their frameworks and difficultly something breaks
between
Visual Basic 2003 and 2005 / ASP.NET 1.1 and 2.0.

After that, there’s one thing calling my attention:

I work in many languages, as you could notice in my responses to the
list,
and none of these have good backwards compatibility. I programmed a
framework in PHP months ago (for the enterprise I am developing) and i
found
out that there aren’t very much difficulties in maintaining a framework
and
stuff like a language should be also easy to make planning on syntax and
function reference, object-orientation and so on.

Why, then, people breaks backwards compatibility? Is it a way to keep
computer developers in the way of new migrations? Or it’s simply because
making stuff compatible is bothering->boring? Or it’s bad planification
for
a language?

I go for bad planifications. I don’t know very much computer developers
who
can do good plannings on paper before programming… and the ones who
did
planning (standard and personally applied diagrams), had more control
over
their source codes. But, I would love to hear some other responses.