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?
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.
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.
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:
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).
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.
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.
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 O. 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…
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
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.
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
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.
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.
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.
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.
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
