[RAILS] way too slow

ruby-talk
1

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.

2

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.

···

On Thu, 19 Aug 2004 04:11:27 +0900, David Morton <mortonda@dgrmm.net> wrote:

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.

3

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

4

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

···

On Thu, 19 Aug 2004 04:28:49 +0900, Carl Youngblood <carl.youngblood@gmail.com> wrote:

On Thu, 19 Aug 2004 04:11:27 +0900, David Morton <mortonda@dgrmm.net> wrote:
> 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.
>
>

5

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).

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 :wink:

···

--
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

6

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 =)

···

On Aug 18, 2004, at 21:28 Uhr, Carl Youngblood wrote:

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.

7

Carl Youngblood wrote:

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?

8

David Heinemeier Hansson wrote:

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).

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

9

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

···

On Thu, 19 Aug 2004 04:48:44 +0900, Edgardo Hames <ehames@gmail.com> wrote:

On Thu, 19 Aug 2004 04:28:49 +0900, Carl Youngblood > <carl.youngblood@gmail.com> wrote:
> 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

> On Thu, 19 Aug 2004 04:11:27 +0900, David Morton <mortonda@dgrmm.net> wrote:
> > 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.
> >
> >
>
>

10

David Heinemeier Hansson wrote:

So basically: Chill. Rails will only get faster :wink:

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

11

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.

···

On Thu, 19 Aug 2004 06:24:55 +0900, David Morton <mortonda@dgrmm.net> wrote:

David Heinemeier Hansson wrote:
> So basically: Chill. Rails will only get faster :wink:

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

12

Wes Moxam wrote:

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. :stuck_out_tongue:

13

David Morton wrote:

Wes Moxam wrote:

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. :stuck_out_tongue:

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. :frowning:

- Jamis

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

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

14

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

···

On Thu, 19 Aug 2004 06:55:43 +0900, David Morton <mortonda@dgrmm.net> wrote:

Wes Moxam wrote:

> 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. :stuck_out_tongue:

15

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. :stuck_out_tongue:

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

16

Wes Moxam wrote:

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.

17

Hello Wes,

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.

Sorry but this is not a good suggestion.

I think we must compare our ruby solutions with existing web frameworks in
perl or python. And they have some really good solutions like Mason or
Webware out there. And i really doubt that you can get a real
development speed advantage with RAILS.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

18

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

19

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) ....

···

On Fri, 20 Aug 2004 02:04:48 +0900, David Morton <mortonda@dgrmm.net> wrote:

Wes Moxam wrote:
>
> 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)

20

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)

like david already said, that requests can take up to one second using
cgi is totally normal. ruby has to parse tons of classes for every execution
with that. i have to admit that i was also surprised by that at first. especially
when you compare it to php. but then again most of the php libs are c..

anyways. i really never even thought that rails is slowing me down in
my development. i mean, i use unit tests for most of the stuff and just
every now and then i have to test the ui and controller via http requests.
works great!