I’ve seen a lot of issue regarding the stability of Rails apps. I’m
charged with investigation of Rails for my company and I’ve looked at
numerous fourms, groups, etc. (Textdrive, here, etc.) and it seems
like there is a stability problem with Rails (ie: crashes, etc.) Is
this as common as it looks, or is this tied to things like Lighttpd (web
server) or Typo (Rails app) quirks?
I’ve run PHP apps that have never crashed as far as I know and haven’t
needed to restart Apache on those boxes.
Can anyone verify if a Rails app is capable of staying up longer than a
couple weeks before memory leaks (see the Ruby forum for recent memory
leak issue), or some other issue hauls it down?
I can’t say I’ve experienced many stability issues. I’ve never had
memory
leaks for instance. The apps that I’ve deployed have thus far been very
stable. The only time I’ve experienced problems was when we went from
lighttpd to mongrel. We experienced a week of crashes that were
rectified by
going back to lighttpd. I don’t see Rails as having stability issues and
as
a former sys admin I understand where you are comming from. When rails
initially came out I opted not to deploy it simply because I didn’t
think
there was a solid server stack supporting it. Now there are a variety of
software stacks to run Rails off. I do feel that there needs to be work
still to creating more of a standard in regards to rails server
platforms.
-m
I’ve worked with PHP for 6 years before migrating to Rails.
I would absolutely not agree that PHP is in any way more stable than
Rails.
I set up my first heavy duty Rails application with the best practices
detailed in “The Perfect Rails Stack”[1]. I did not experience any
stability issues with that first application. It was at least as stable
as any PHP application I’ve ever worked with, including those deployed
and administered by sysadmins far more specialised and knowledgable
than me.
And yes, that first application and several others following it ran for
weeks at a time, with zero adminning, zero restarts, and zero stability
issues. It is still running today.
There are several heavy-duty Rails applications[2], serving millions of
requests a day[3]. Not sure where you got that information about
supposedly rampant stabity concerns, but it runs contrary to my
personal experience and to common knowledge of many others as well.
–
[1] Ruby on Rails Blog / What is Ruby on Rails for?
[2] http://rubyonrails.com/applications
[3]
0歳の日帰り旅行はいつから大丈夫？持ち物や注意点も知ろう！
I can see how you’d get that impression from the messages posted to
the list, but my experience is that after you get through the
inevitable “teething problems” of setting up a prod server running
software you haven’t used before, Rails is very robust.
I suspect most of the issues you’re reading about are from people
still going through the learning curve; people who’ve got things set
up and running smoothly typically don’t post that often about it…
Regards
Dave M.
David M. wrote:
I can see how you’d get that impression from the messages posted to
the list, but my experience is that after you get through the
inevitable “teething problems” of setting up a prod server running
software you haven’t used before, Rails is very robust.
I suspect most of the issues you’re reading about are from people
still going through the learning curve; people who’ve got things set
up and running smoothly typically don’t post that often about it…
Regards
Dave M.
Perhaps we should encourage people to chime in with good news. I can
see it now…
“OMG, my rails app is getting about ten thousands hits per hour and it
hasn’t crashed yet; what should I do???”
jp
On Aug 29, 2006, at 2:51 PM, Leo S. wrote:
needed to restart Apache on those boxes.
Can anyone verify if a Rails app is capable of staying up longer
than a
couple weeks before memory leaks (see the Ruby forum for recent memory
leak issue), or some other issue hauls it down?
–
Posted via http://www.ruby-forum.com/.
The http://yakimaherald.com/ website has been running since July
2005 on rails first on lighttpd/fcgi and now on apache2.2/
mod_proxy_balancer/mongrel_cluster and it runs for months at a time
without restarts.
Cheers-
-Ezra
No stability problems for me…
Mongrel
Lighttpd
PostgreSQL
Rails
Fedora Core 4
Keeps going and going, weeks and weeks, months and months…
Joe
Charlie H. wrote:
While my new box has helped getting rid of the crashes when I run rails.
The debugger is a different story. The debugger on windows won’t even
work. It crashes in just a few seconds of coming up. It’s almost
enough to make me quit using Rails altogether. Having a proper debugger
is essential for productivity. I find it terribly ironic that a
framework that predicates itself on productivity doesn’t have a working
debugger. While you can go without a debugger it’s just faster to have
one at your side when you need it.
OMG!!! I’ve never had any problems with the debugger on my windows box
since I started using Rails!!! What should I do!!!
Windows debugger – isn’t that an oxymoron?
Joe
mark wrote:
OMG!!! I’ve never had any problems with the debugger on my windows box
since I started using Rails!!! What should I do!!!
Yeah, it generally worked for me too. That said, everything works
much better and more predictable on Linux (preferably Debian).
Developing on a good Linux box, you basically don’t experience any
random crashes and the like. It’s about as good as it gets, stability
wise. Maybe a modern Mac is about is good. Windows definitely isn’t
(no, not even a properly set-up XP).
On Tue, 2006-08-29 at 18:22 -0700, Ezra Z. wrote:
server) or Typo (Rails app) quirks?
There actually are three remaining stability bugs in Mongrel that hit
some folks:
-
LEAK: A slow memory leak when the site is hit with enough requests to
trigger a leak that shows up in Ruby thread locking. This bug is fixed
in the latest pre-release for POSIX systems, but not win32.
-
CLOSE_WAIT: Excessive numbers of sockets in CLOSE_WAIT state that
cause a Mongrel process to stop answering requests. This appears to hit
people who are behind Apache most, and especially those who are having
Mongrel serve files. It also seems to be rare, but you can test it by
running: lsof -i -P | grep CLOSE_WAIT and looking to see if they never
go down.
-
99% CPU: After running for a while, a Mongrel process will just eat
CPU like crazy. This so far is rare and I can’t replicate this so I’m
looking for people who have this happen and can let me onto their
computer to look at the process when it happens.
I’m currently working with people who have these problems, and hopefully
will have it solved soon. If you are seeing these issues then please
contact me so I can give you special builds of Mongrel and have you run
a debugging process for me.
Otherwise, very few people have reported these problems and the majority
of them are doing strange things like accessing legacy databases.
–
Zed A. Shaw
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 – Come get help.
I have had serious problems with stability on Windows, but I have not
had any trouble with Ruby on Linux. I have upgraded to a box with more
memory and faster CPU which has really helped the problems. When I saw
crashing I was using windows box with low memory. That caused
operations to take longer to run, and I think I was hitting a race
condition in the MySQL driver. Now that I’ve got a faster box with more
memory I haven’t had any crashes when I run rails. However, the same
situation could arise from a server under heavy load and that race
condition could come back. I wouldn’t be surprised if that is the same
problem other people are seeing.
While my new box has helped getting rid of the crashes when I run rails.
The debugger is a different story. The debugger on windows won’t even
work. It crashes in just a few seconds of coming up. It’s almost
enough to make me quit using Rails altogether. Having a proper debugger
is essential for productivity. I find it terribly ironic that a
framework that predicates itself on productivity doesn’t have a working
debugger. While you can go without a debugger it’s just faster to have
one at your side when you need it.
Yo EZ,
Have a good tutorial on getting mongrel/apache running on a Debian
server?
On 8/29/06, Ezra Z. [email protected] wrote:
this as common as it looks, or is this tied to things like Lighttpd
Cheers-
-Ezra
–
seth at subimage interactive
http://www.subimage.com/sublog/
On Aug 31, 2006, at 10:16 AM, subimage interactive wrote:
Yo EZ,
Have a good tutorial on getting mongrel/apache running on a Debian
server?
Well you will ant to compile apache2.2.3 yourself. If you are anal
about debian packaging then use chkinstall to do it so it will be
packaged into a .deb as well. But here are the good config flags for
a nice slim apache2.2.3/mod_proxy_balancer setup. the mongrel cluster
part is easy once you get apache compiled and a good vhost set up.
Here’s a good vhost:
http://brainspl.at/articles/2006/06/12/apache2-2-vhost-template-for-
mongrel-clusters
configure flags for compiling a skinny apache:
./configure
–with-mpm=worker
–with-ssl
–enable-alias
–enable-cache
–enable-auth-basic
–enable-auth-digest
–enable-authn-anon
–enable-authn-default
–enable-authn-file
–enable-authz-default
–enable-authz-host
–enable-authz-user
–enable-dir
–enable-disk-cache
–enable-expires
–enable-mime
–enable-mem-cache
–enable-negotiation
–enable-deflate
–enable-http
–enable-headers
–enable-include
–enable-log-config
–enable-proxy
–enable-proxy-balancer
–enable-proxy-http
–enable-rewrite
–enable-setenvif
–enable-so
–enable-ssl
–enable-threads
–disable-actions
–disable-asis
–disable-authn-alias
–disable-authn-dbd
–disable-authn-dbm
–disable-authz-dbm
–disable-authz-groupfile
–disable-authz-ldap
–disable-authz-owner
–disable-autoindex
–disable-bucketeer
–disable-case-filter
–disable-case-filter-in
–disable-cern-meta
–disable-cgi
–disable-cgid
–disable-charset-lite
–disable-dav
–disable-dav-ds
–disable-dav-lock
–disable-distcache
–disable-dbd
–disable-dumpio
–disable-echo
–disable-env
–disable-example
–disable-ext-filter
–disable-file-cache
–disable-filter
–disable-index
–disable-indent
–disable-imagemap
–disable-imap
–disable-info
–disable-isapi
–disable-ldap
–disable-log-forensic
–disable-logio
–disable-mime-magic
–disable-nw-ssl
–disable-optional-fn-export
–disable-optional-fn-import
–disable-optional-hook-export
–disable-optional-hook-import
–disable-proxy-ajp
–disable-proxy-connect
–disable-proxy-ftp
–disable-speling
–disable-status
–disable-suexec
–disable-unique-id
–disable-userdir
–disable-usertrack
–disable-version
–disable-vhost-alias
Cheers-
-Ezra
On 8/29/06, Jeff P. [email protected] wrote:
Perhaps we should encourage people to chime in with good news. I can
see it now…
“OMG, my rails app is getting about ten thousands hits per hour and it
hasn’t crashed yet; what should I do???”
Heh. One of my admin users sent me a note this morning complaining
that the site was way too fast.
Damn that pound + mongrel combo!
The main problem I ran into with Debian is that ruby 1.8.2 is the
standard.
I’m guessing I’d have to recompile 1.8.4, then ImageMagick, and
everything
else (along with Apache) right?
On 8/31/06, Ezra Z. [email protected] wrote:
--enable-authn-default \
--enable-deflate \
--enable-ssl \
--disable-autoindex \
--disable-distcache \
--disable-imagemap \
--disable-optional-hook-export \
--disable-version \
--disable-vhost-alias
Cheers-
-Ezra
–
seth at subimage interactive
http://www.subimage.com/sublog/
I’m having memory issues with rails at the moment, but I can’t say yet
if it’s our fault or the fault of rails, lighty, fcgi, etc.
Our site is very dynmic and is getting between 30k -40k hits per day
and the memory uses of our fcgi processes grows very fast and we have
to restart it once a day. Unfortunately, we haven’t been able to
duplicate this problem off of the live server so we’re having a hard
time tracking it down.
Yes. Or upgrade to testing instead of sarge and you can get
ruby1.8.4 and imagemagick and all that stuff thru apt. Or if you have
to stay on sarge you can use apt-pinning to pin ruby1.8.4 from
testing back into sarge. Or there is always backports too.
I am still debating how I am going to reccomend installing ruby on
the debian server I walk you thru installing in my book. I might just
have people install ruby and friends from source and use chkinstall
to install them as .deb’s.
-Ezra