[RAILS] way too slow...

[David Morton]

I'm having a heck of a time justifying ruby/rails dues to speed issues.

I just downloaded rails 0.6, unpacked, changed #! lines to point to my
path, and then:

#-------------------------------------------------------------------
/script/new_controller test index
/usr/sbin/ab2 -n 1000 -c 10 http://rails/fcgi/test/index
...
Requests per second: 19.17 [#/sec] (mean)
Time per request: 521.568 [ms] (mean)
#--------------------------------------------------------------------

Out of the box, it can't even handle 2 requests per second. (divide by
10 fcgi processes running)

My server is old, but not that old: 1Ghz athlon with 768M RAM

Serving static requests, I get:

#---------------------------------------------------------------------
/usr/sbin/ab2 -n 1000 -c 10 http://www.dgrmm.net/

Requests per second: 189.65 [#/sec] (mean)
Time per request: 52.728 [ms] (mean)
#---------------------------------------------------------------------

That makes it 10 times slower than static. Obviously, it will be
slower, but is this reasonable? Any ideas on how to make this better?

I'm running on a mostly pristine Suse 9.1.

 

[Carl Youngblood]

In today's world, boxes are cheap. Development time is what costs
money. Rails saves money where it matters most. If your site is
bogged down, just add a few servers to your load-balanced pool.

 

[Edgardo Hames]

In today's world, boxes are cheap. Development time is what costs
money. Rails saves money where it matters most. If your site is
bogged down, just add a few servers to your load-balanced pool.

That sounds fine to me, but is it really _that_ slow?

Regards,
Ed

I'm having a heck of a time justifying ruby/rails dues to speed issues.

I just downloaded rails 0.6, unpacked, changed #! lines to point to my
path, and then:

#-------------------------------------------------------------------
../script/new_controller test index
/usr/sbin/ab2 -n 1000 -c 10 http://rails/fcgi/test/index
....
Requests per second: 19.17 [#/sec] (mean)
Time per request: 521.568 [ms] (mean)
#--------------------------------------------------------------------

Out of the box, it can't even handle 2 requests per second. (divide by
10 fcgi processes running)

My server is old, but not that old: 1Ghz athlon with 768M RAM

Serving static requests, I get:

#---------------------------------------------------------------------
/usr/sbin/ab2 -n 1000 -c 10 http://www.dgrmm.net/

Requests per second: 189.65 [#/sec] (mean)
Time per request: 52.728 [ms] (mean)
#---------------------------------------------------------------------

That makes it 10 times slower than static. Obviously, it will be
slower, but is this reasonable? Any ideas on how to make this better?

I'm running on a mostly pristine Suse 9.1.

 

[David Heinemeier Hansson]

That makes it 10 times slower than static. Obviously, it will be

slower, but is this reasonable? Any ideas on how to make this better?

What are you doing on your test page? If I don't need to have sessions
and just say "hello world" in an action, I'm able to get 150 req/sec on
FCGI on my lowly Powerbook (4200 rpm drive).
--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

 

[Carl Youngblood]

I haven't tried it with fcgi yet, so I can't tell you. Sorry.

In today's world, boxes are cheap. Development time is what costs
money. Rails saves money where it matters most. If your site is
bogged down, just add a few servers to your load-balanced pool.

That sounds fine to me, but is it really _that_ slow?

Regards,
Ed

I'm having a heck of a time justifying ruby/rails dues to speed issues.

I just downloaded rails 0.6, unpacked, changed #! lines to point to my
path, and then:

#-------------------------------------------------------------------
../script/new_controller test index
/usr/sbin/ab2 -n 1000 -c 10 http://rails/fcgi/test/index
....
Requests per second: 19.17 [#/sec] (mean)
Time per request: 521.568 [ms] (mean)
#--------------------------------------------------------------------

Out of the box, it can't even handle 2 requests per second. (divide by
10 fcgi processes running)

My server is old, but not that old: 1Ghz athlon with 768M RAM

Serving static requests, I get:

#---------------------------------------------------------------------
/usr/sbin/ab2 -n 1000 -c 10 http://www.dgrmm.net/

Requests per second: 189.65 [#/sec] (mean)
Time per request: 52.728 [ms] (mean)
#---------------------------------------------------------------------

That makes it 10 times slower than static. Obviously, it will be
slower, but is this reasonable? Any ideas on how to make this better?

I'm running on a mostly pristine Suse 9.1.

 

[David Heinemeier Hansson]

That makes it 10 times slower than static. Obviously, it will be

What are you doing on your test page? If I don't need to have sessions
and just say "hello world" in an action, I'm able to get 150 req/sec
on FCGI on my lowly Powerbook (4200 rpm drive).

I might have been overstating myself there. I just ran a few quick
tests and got something like this on a simple "hello world" through
render_text:

No logging, no sessions 98.51
Logging, no sessions 80.11
Logging, pstore/sessions 50.64

Anyway. Florian Weber is working on a benchmark suite for Rails now
that will include a bunch of common use cases and measure them at
different steps in the application. That'll give us a much easier tool
for comparison and tweaking.

Also, I've done pretty much zero performance tuning on the Action Pack.
I'm *positive* that I'm doing a bunch of unnecessary and expensive
calls that can be heavily tuned.

When I spent some time tuning Active Record, the use cases I was
working with improved by 400%.

So basically: Chill. Rails will only get faster
--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

 

[Florian Weber]

In today's world, boxes are cheap. Development time is what costs
money. Rails saves money where it matters most. If your site is
bogged down, just add a few servers to your load-balanced pool.

plus caching can be applied in soo many situations. arg! that reminds
me that i still have to still finish up that caching filter i started
to work on =)

 

[David Morton]

In today's world, boxes are cheap. Development time is what costs
money. Rails saves money where it matters most. If your site is
bogged down, just add a few servers to your load-balanced pool.

What kind of answer is that? You can't possibly justify one server per
connection?!?!?!?!?

It won't save that kind of money. If boxes are really that cheap, would
you mind giving me one? No?

 

[David Morton]

What are you doing on your test page? If I don't need to have sessions
and just say "hello world" in an action, I'm able to get 150 req/sec on
FCGI on my lowly Powerbook (4200 rpm drive).

Exactly what I said. It is the default page put there by the
new_controller script. Nothing more.

 

[David Morton]

So basically: Chill. Rails will only get faster

Sigh. Well, let me know when it does, because for now, it's completely
unusable fo me.

 

[Wes Moxam]

Sigh. Well, let me know when it does, because for now, it's completely
unusable fo me.

David, how complex is your site going to be and how much traffic do
you plan on getting? Unless you're planning to compete with ebay in
the next couple of months, Rails is likely fast enough for you. Signup
for a free account at http://www.basecamphq.com/ to try out a
production rails application.

 

[David Morton]

David, how complex is your site going to be and how much traffic do
you plan on getting? Unless you're planning to compete with ebay in
the next couple of months, Rails is likely fast enough for you. Signup
for a free account at http://www.basecamphq.com/ to try out a
production rails application.

I don't have an application for it right now, but I'm arguing the
principle of the thing. I think a web server needs to be able to handle
more than 1 request per second.

 

[Jamis Buck]

I don't have an application for it right now, but I'm arguing the
principle of the thing. I think a web server needs to be able to handle
more than 1 request per second.

Welll... I know you're being facetious, but rails does handle a LOT more
than 1 request per second. In fact, as Wes said, it is probably
sufficient for most things you need to do with it, especially since you
are only arguing "the principle of the thing."

I definately don't want to be misunderstood here. I'm not trying to
flame, and I don't want to come off as insulting. I just want to say: be
careful when "arguing the principle of [a] thing." If you don't know
what you want to use a tool for, it makes no sense to argue that the
tool is insufficient. However, once you sit down and try to use that
tool for something, and then discover that it is insufficient, that is
the point at which you can begin to offer constructive criticism,
because that is when you begin to understand *what* aspects of that tool
could be improved.

DHH is *very* responsive to constructive criticism. He has a fast
turnaround on bug fixes, and is very willing to work with his users.
However, a general "it's not fast enough" is hard to fix, especially
when there is nothing to compare it with. Not fast enough for what?

I honestly hope these comments aren't misunderstood. I don't mean to be
patronizing or insulting; I just want to make it clear that when
criticizing software, the principle of the thing is not enough of an
argument, generally.

- Jamis

--
Jamis Buck
(e-mail address removed)
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

 

[Wes Moxam]

I don't have an application for it right now, but I'm arguing the
principle of the thing. I think a web server needs to be able to handle
more than 1 request per second.

It sounds like you would rather use something that has impressive
looking benchmark numbers than something that will reduce your
develpment time. I would suggest php (www.php.net). There are plenty
of PHP frameworks available, although none will be as fun to use as
rails.

-- Wes

 

[David Heinemeier Hansson]

I don't have an application for it right now, but I'm arguing the

principle of the thing. I think a web server needs to be able to
handle
more than 1 request per second.

First of all, I don't know where the 1 request per second thing came
from. Is that a parody of the 20 you were getting?

Secondly, and let me make this clear, Rails *does* care about
performance. It's just that I'd rather spend my time getting it right
before making it fast. And Rails is already fast enough to power
Basecamp on a single machine, but of course it can go faster. And it
will.

I expect to include the new benchmark suite in the next release of
Rails. That'll give us some comparable numbers to have a meaningful
discussion about.

Anyway, thanks for your concern. I'm glad to hear that Rails is worth
freaking out over when the first set of numbers doesn't sing to your
expectations. It's good to have high expectations. I'll do my earnest
to live up to them.
--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

 

[David Morton]

It sounds like you would rather use something that has impressive
looking benchmark numbers than something that will reduce your
develpment time. I would suggest php (www.php.net). There are plenty
of PHP frameworks available, although none will be as fun to use as
rails.

Yes, I realize what you are saying, and rails devel *is* fun. Except
for the agonizing long time it takes for a page to reload to show me
what I've changed. That seems to mitigate against the supposed increase
in devel time. It's actually taking me longer to devel in rails right
now. (I'm still learning ruby, too)

I'm not necessarily looking for the best benchmarks, but I would expect
better than 1 req/sec.

What I was really asking was if anyone had any idea *WHY* it was running
so slowly.

 

[David Heinemeier Hansson]

I'm not necessarily looking for the best benchmarks, but I would

expect better than 1 req/sec.

Are you running in CGI mode? If so, 1 req/sec is similar to what I'm
getting. Rails does a ton of fancy, smancy stuff at startup to get all
the magic poofing.

In a production environment, though, this initialization cost is never
seen by the users as it only happens once when a new Apache or FCGI
process starts up.

So I wouldn't get my hopes up for that to improve. I find 1 req/sec
perfectly acceptable for developing on my Powerbook offline. I
developed the new release of Basecamp like that.

But even if it is a problem for you, it's pretty easy to switch between
FCGI and CGI. So just use CGI when you're changing stuff all the time
(like working on a single page), then use FCGI (or mod_ruby) when you
need to test a bunch of pages.

Also, compare this to any compiled language. Do you still think 1
second to compile all of Rails and your entire application is a raw
deal? I think it's pretty darn well amazing.

There's no build script to wait for. There's no file-based code
generation.

I find Rails development to be extremely fast compared to most other
environments. I guess it's about expectations. If you're comparing to
changing a line in a static HTML file and reloading, then yes, Rails is
dog slow. If you're comparing to other web-application frameworks,
Rails is a bonefied sprinter.

What I was really asking was if anyone had any idea *WHY* it was
running so slowly.

I hope I've been able to explain that here. If not, please don't
refrain from phrasing another question.
--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

 

[Thomas Fini Hansen]

Are you running in CGI mode? If so, 1 req/sec is similar to what I'm
getting. Rails does a ton of fancy, smancy stuff at startup to get all
the magic poofing.

In a production environment, though, this initialization cost is never
seen by the users as it only happens once when a new Apache or FCGI
process starts up.

So I wouldn't get my hopes up for that to improve. I find 1 req/sec
perfectly acceptable for developing on my Powerbook offline. I
developed the new release of Basecamp like that.

But even if it is a problem for you, it's pretty easy to switch between
FCGI and CGI. So just use CGI when you're changing stuff all the time
(like working on a single page), then use FCGI (or mod_ruby) when you
need to test a bunch of pages.

Random thought: auto-reload.rb from the mod_ruby distribution. Does
that work with Rails, or does the two not like each other?

I should get some Rails up and running soon..

 

[Wes Moxam]

Yes, I realize what you are saying, and rails devel *is* fun. Except
for the agonizing long time it takes for a page to reload to show me
what I've changed. That seems to mitigate against the supposed increase
in devel time. It's actually taking me longer to devel in rails right
now. (I'm still learning ruby, too)

That's strange that page reloads are slow to the point that it's
slowing you down... I'm using Webrick and the response time is fairly
quick. What type of hw/sf platform are you using?

If you want to experiance some *real* pain try installing BEA Weblogic
8.0 on your system. It takes almost 5 minutes to start the workshop
app on my home system (1.2 GHz) ....

 

[David Heinemeier Hansson]

Random thought: auto-reload.rb from the mod_ruby distribution. Does

that work with Rails, or does the two not like each other?

They're not too fond of each other. It won't reload the requires of
your requires, so it basically doesn't work for changing the model.
You'll have to restart Apache when doing that.
--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services