Forum: Ruby on Rails Unacceptibly slow.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3df897745c664e3add6f047daa5835d1?d=identicon&s=25 DDudde (Guest)
on 2006-03-04 04:09
I currently have a fairly simple Rails application running on FreeBSD
under Apache 1.3 and normal CGI, and the performance I'm getting is
alarmingly poor. I realize CGI or WebBrick are quite a bit slower than
FastCGI, and I'll probably use one of those instead when I have the
time. However, I'm just curious if CGI is really supposed to be that
slow, or if there's something wrong with my configuration.

At present any request to the server (i.e. page refresh) takes 2 or 3
seconds. Again, I'm talking about a decent server on a Gigabit local
area network. Also the PHP web sites I run on this very same server are
instantaneous, so the server couldn't be the problem. But anything I've
tried with Rails is incredibly slow.

Does that sound right to everyone? Is normal CGI usually so unacceptably
slow?
821395fe70906c8290df7f18ac4ac6cf?d=identicon&s=25 Rick Olson (Guest)
on 2006-03-04 04:27
(Received via mailing list)
> Does that sound right to everyone? Is normal CGI usually so unacceptably
> slow?

Yup.  Each request invokes a whole new ruby process, reloads the whole
framework from scratch, and manages to take care of your request.
Don't use CGI.

--
Rick Olson
http://techno-weenie.net
3ccecc71b9fb0a3d7f00a0bef6f0a63a?d=identicon&s=25 Kent Sibilev (Guest)
on 2006-03-04 04:33
(Received via mailing list)
On 3/3/06, DDudde <mendake_ddude@yahoo.com> wrote:
>
> Does that sound right to everyone? Is normal CGI usually so unacceptably
> slow?
>

Yes, they are. Note that with every request you create a new process
which has to load  Rails framework plus most of the standard library
and your own classes. Also note that the current Ruby interpreter
doesn't use bytecode compilation and has to interpret every line.

--
Kent
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-03-04 04:33
(Received via mailing list)
On 3/3/06 10:09 PM, "DDudde" <mendake_ddude@yahoo.com> wrote:

> I currently have a fairly simple Rails application running on FreeBSD
> under Apache 1.3 and normal CGI, and the performance I'm getting is
> alarmingly poor. I realize CGI or WebBrick are quite a bit slower than
> FastCGI, and I'll probably use one of those instead when I have the
> time. However, I'm just curious if CGI is really supposed to be that
> slow, or if there's something wrong with my configuration.
>

I'm actually seeing similar performance issues on FreeBSD 6.0 with the
latest Ruby 1.8.4 and Rails.  I find that Mongrel screams on Linux,
Windows,
and NetBSD, but on FreeBSD or OSX it *crawls*.  It's still faster than
WEBrick, but not nearly as fast as it should be.  It's actually so bad
that
I installed FreeBSD on my laptop just so I could debug the problem once
and
for all.

As a comparison, I have 1/16th VPS donated to me by the railsmachine.net
people, which runs Linux.  My tests on this VPS show Mongrel doing a
basic
"test" controller at around 120 req/sec (70 low end).  Over on my
FreeBSD
laptop--which is a full computer with a 1.6ghz processor--the exact same
code gets a pathetic 20 req/sec.  WEBrick gets 8 req/sec.

There's just no way that FreeBSD--one of the fastest server OS out
there--is
really getting 1/6th the performance of a literal slice of a Linux
system.
OSX also has similar crap performance for some odd reason.

My current theory--after not much review--is that OSX and FreeBSD set
their
default select fd limit to 256 so Ruby isn't able to keep up with a
serious
load.  But I've got no evidence to back this up.

> At present any request to the server (i.e. page refresh) takes 2 or 3
> seconds. Again, I'm talking about a decent server on a Gigabit local
> area network. Also the PHP web sites I run on this very same server are
> instantaneous, so the server couldn't be the problem. But anything I've
> tried with Rails is incredibly slow.
>

CGI is going to be insanely and horribly slow.  The only people who use
CGI
are the desperate ones.  Give Mongrel a try (pimptastic plug from me) or
take the time to setup lighttpd and fastcgi.

http://mongrel.rubyforge.org/

But yeah, I'm seeing the same kind of slow performance from Rails
applications on FreeBSD.

Zed A. Shaw
http://www.zedshaw.com/
Cf7e5e4b5ca573eec214191fac420a2f?d=identicon&s=25 Dave Silvester (Guest)
on 2006-03-04 04:42
(Received via mailing list)
On Saturday 04 Mar 2006 03:09, DDudde wrote:
> At present any request to the server (i.e. page refresh) takes 2 or 3
> seconds. Again, I'm talking about a decent server on a Gigabit local
> area network. Also the PHP web sites I run on this very same server are
> instantaneous, so the server couldn't be the problem. But anything I've
> tried with Rails is incredibly slow.
>
> Does that sound right to everyone? Is normal CGI usually so unacceptably
> slow?

You don't mention what Rails environment you're running in, so I'm
assuming
you're quite likely running in the Development environment, where Rails
reloads a lot more stuff each time.

Apache + regular CGI + Development environment = SLOOOOW.

You might find that if you switch to the Production environment things
will
speed up a tiny bit, but I'd still say don't use regular CGI as it's
waaaay
slower than FCGI.  Info about Environments is here:

http://wiki.rubyonrails.org/rails/pages/Environments/

I certainly wouldn't try to develop using Apache and regular CGI - much
too
slow!  I'd use Lighttpd or WEBrick for development, then Apache + FCGI
for
production (assuming that Lighttpd + FCGI isn't an option).

Cheers,

~Dave

--

Dave Silvester
Rent-A-Monkey Website Development
http://www.rentamonkey.com/

PGP Key: http://www.rentamonkey.com/pgpkey.asc
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-04 07:16
(Received via mailing list)
On Mar 3, 2006, at 7:09 PM, DDudde wrote:

> At present any request to the server (i.e. page refresh) takes 2 or 3
> seconds. Again, I'm talking about a decent server on a Gigabit local
> area network. Also the PHP web sites I run on this very same server
> are
> instantaneous, so the server couldn't be the problem. But anything
> I've
> tried with Rails is incredibly slow.

On Mar 3, 2006, at 7:26 PM, Rick Olson wrote:

>> Does that sound right to everyone? Is normal CGI usually so
>> unacceptably
>> slow?
>
> Yup.  Each request invokes a whole new ruby process, reloads the whole
> framework from scratch, and manages to take care of your request.
> Don't use CGI.

I'm not disagreeing with Rick, but using WEBrick on my laptop (G4 1.25)
isn't as slow as DDudde is seeing...

--
-- Tom Mornini
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-04 07:19
(Received via mailing list)
On Mar 3, 2006, at 7:30 PM, Zed Shaw wrote:

> I'm actually seeing similar performance issues on FreeBSD 6.0 with the
> latest Ruby 1.8.4 and Rails.  I find that Mongrel screams on Linux,
> Windows,
> and NetBSD, but on FreeBSD or OSX it *crawls*.  It's still faster than
> WEBrick, but not nearly as fast as it should be.  It's actually so
> bad that
> I installed FreeBSD on my laptop just so I could debug the problem
> once and
> for all.

Interesting to note. I'd been considering FreeBSD 6 recently as someone
mentioned that had a fantasticly simple Rails port, but I'll wait.

That said, as repeated from my last response on this thread, the slow
you're talking about and slow this person is seeing are two different
slows. :-)

He's talking about 1/2 req/second, you're talking about 8 req/second,
so he's seeing 1/16 the performance that you consider crawling!

There's GOT to be something else wrong with his setup.

--
-- Tom Mornini
3df897745c664e3add6f047daa5835d1?d=identicon&s=25 DDudde (Guest)
on 2006-03-04 16:13
DDudde wrote:
> I currently have a fairly simple Rails application running on FreeBSD
> under Apache 1.3 and normal CGI, and the performance I'm getting is
> alarmingly poor. I realize CGI or WebBrick are quite a bit slower than
> FastCGI, and I'll probably use one of those instead when I have the
> time. However, I'm just curious if CGI is really supposed to be that
> slow, or if there's something wrong with my configuration.
>
> At present any request to the server (i.e. page refresh) takes 2 or 3
> seconds. Again, I'm talking about a decent server on a Gigabit local
> area network. Also the PHP web sites I run on this very same server are
> instantaneous, so the server couldn't be the problem. But anything I've
> tried with Rails is incredibly slow.
>
> Does that sound right to everyone? Is normal CGI usually so unacceptably
> slow?

Thank you all for the very helpful information. Looks like I should
definitely scrap CGI for fast CGI. I'll work on that today.

You know, I just realized I somehow worded my post wrong. I said "I
realize CGI or WebBrick are quite a bit slower than FastCGI", when I
meant to say I realize CGI is quite a bit slower than WebBrick or
FastCGI". Sorry for the confusion, but your comments were definitely
helpful. I guess I should avoid making posts late at night after a few
glasses of rum. :-)
8e44c65ac5b896da534ef2440121c953?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-03-04 18:27
(Received via mailing list)
On Mar 3, 2006, at 7:30 PM, Zed Shaw wrote:

>> time. However, I'm just curious if CGI is really supposed to be that
> once and
> code gets a pathetic 20 req/sec.  WEBrick gets 8 req/sec.
> serious
> load.  But I've got no evidence to back this up.
>

Zed-

	I have been using mongrel on my new intel iMac and it is much faster
then webrick on these new machines.

-Ezra
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-03-04 18:54
(Received via mailing list)
> I'm actually seeing similar performance issues on FreeBSD 6.0 with the
> latest Ruby 1.8.4 and Rails.  I find that Mongrel screams on Linux, Windows,
> and NetBSD, but on FreeBSD or OSX it *crawls*.  It's still faster than
> WEBrick, but not nearly as fast as it should be.  It's actually so bad that
> I installed FreeBSD on my laptop just so I could debug the problem once and
> for all.

fwiw I have lighttpd running on FBSD 6.0 and it screams
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-03-04 19:03
(Received via mailing list)
On 3/4/06 12:51 PM, "Pat Maddox" <pergesu@gmail.com> wrote:

>> I'm actually seeing similar performance issues on FreeBSD 6.0 with the
>> latest Ruby 1.8.4 and Rails.  I find that Mongrel screams on Linux, Windows,
>> and NetBSD, but on FreeBSD or OSX it *crawls*.  It's still faster than
>> WEBrick, but not nearly as fast as it should be.  It's actually so bad that
>> I installed FreeBSD on my laptop just so I could debug the problem once and
>> for all.
>
> fwiw I have lighttpd running on FBSD 6.0 and it screams

I was actually talking about Mongrel not lighttpd. Not sure where you
got
that comparison, but yeah a compiled server like lighttpd is using
kqueue so
it's gonna be faster than Mongrel doing Ruby threads.

Zed A. Shaw
http://www.zedshaw.com/
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-03-04 19:12
(Received via mailing list)
On 3/4/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
> >> for all.
> >
> > fwiw I have lighttpd running on FBSD 6.0 and it screams
>
> I was actually talking about Mongrel not lighttpd. Not sure where you got
> that comparison, but yeah a compiled server like lighttpd is using kqueue so
> it's gonna be faster than Mongrel doing Ruby threads.
>
> Zed A. Shaw
> http://www.zedshaw.com/

OP was talking about Apache on FreeBSD, and then you said

"I'm actually seeing similar performance issues on FreeBSD 6.0 with
the latest Ruby 1.8.4 and Rails.  I find that Mongrel screams on
Linux, Windows, and NetBSD, but on FreeBSD or OSX it *crawls*. "

So it seemed to me like you were addressing a possible performance
issue with Ruby on FBSD 6.0.  I was just pointing out that I run Rails
on a couple FreeBSD servers with no problems, that's all.

Pat
Eea7ad39737b0dbf3de38874e0a6c7d8?d=identicon&s=25 Justin Forder (Guest)
on 2006-03-04 22:32
(Received via mailing list)
Tom Mornini wrote:
>>> Does that sound right to everyone? Is normal CGI usually so unacceptably
>>> slow?
>>
>> Yup.  Each request invokes a whole new ruby process, reloads the whole
>> framework from scratch, and manages to take care of your request.
>> Don't use CGI.
>
> I'm not disagreeing with Rick, but using WEBrick on my laptop (G4 1.25)
> isn't as slow as DDudde is seeing...

WEBrick is fine (apart from being single-threaded for Rails). It is
keeping all of Ruby and Rails in memory, whereas CGI is loading it on
every request.

   Justin
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-05 01:16
(Received via mailing list)
On Mar 4, 2006, at 1:31 PM, Justin Forder wrote:

> Tom Mornini wrote:
>> On Mar 3, 2006, at 7:09 PM, DDudde wrote:
>> I'm not disagreeing with Rick, but using WEBrick on my laptop (G4
>> 1.25)
>> isn't as slow as DDudde is seeing...
>
> WEBrick is fine (apart from being single-threaded for Rails). It is
> keeping all of Ruby and Rails in memory, whereas CGI is loading it
> on every request.

I understand the difference, Justin, and as I said I wasn't disagreeing.

My point was that the behavior the OP(DDudde) was seeing was much worse
than one would expect even from WEBrick.

--
-- Tom Mornini
Eea7ad39737b0dbf3de38874e0a6c7d8?d=identicon&s=25 Justin Forder (Guest)
on 2006-03-05 15:53
(Received via mailing list)
Tom Mornini wrote:
>
> I understand the difference, Justin, and as I said I wasn't disagreeing.
>
> My point was that the behavior the OP(DDudde) was seeing was much worse
> than one would expect even from WEBrick.

OK. On this laptop, I can run a simple application at tens of
requests/second (as reported in the development log). Firing up
script/console takes four seconds (as measured by hand stopwatch) to the
time the prompt appears. The latter is more relevant to CGI performance
than the former.

   Justin
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-05 19:17
(Received via mailing list)
On Mar 5, 2006, at 6:50 AM, Justin Forder wrote:

>>> loading it on every request.
> performance than the former.
Oh, I think I understand the misunderstanding...

Are you saying WEBrick mode is *not* CGI?

If so, I've been misunderstanding this thread the whole time.

Since WEBrick in development reloads everything every time,
I always thought it *was* using CGI...

--
-- Tom Mornini
Eea7ad39737b0dbf3de38874e0a6c7d8?d=identicon&s=25 Justin Forder (Guest)
on 2006-03-05 21:13
(Received via mailing list)
Tom Mornini wrote:
> Are you saying WEBrick mode is *not* CGI?
>
> If so, I've been misunderstanding this thread the whole time.
>
> Since WEBrick in development reloads everything every time,
> I always thought it *was* using CGI...

WEBrick is like a Ruby servlet container. It is not CGI, and it doesn't
reload everything every time.

The script/server script runs your application, on Rails, on WEBrick,
and it is Rails, rather than WEBrick, that understands the different
modes (development vs. production).

In development mode, Rails reloads your application code when it has
changed. Ruby, Rails, other gems and the contents of the lib directory
stay loaded. This is true regardless of whether you are running on
WEBrick, FCGI, or SCGI. (For FCGI and SCGI each Rails process has a
startup cost, but should then stay alive to handle many requests.)

CGI creates a new process per request, so it has to load *everything*
from scratch. In my previous post I compared this with starting up
script/console - perhaps a better comparison would be with the time it
takes to run a single functional test from the command line.
(Script/console only lets you work with your models and ActiveRecord,
whereas a functional test uses the whole of your app on the whole Rails
framework.)

By the way, it's worth trying running your WEBrick app in production
mode (script/server -e production) just to see what difference it makes
to performance. When I did this I was hoping to see a big speedup - but
I didn't. I haven't got on to using caching yet - I'm sure that would be
a different story.

regards

   Justin
This topic is locked and can not be replied to.