Rails - Aug 2006 - Do i need multiple mongrel instances for good performance?

I have developed a rails application for my company.

It will be used by upto 3o people at a time.  I have just read that 
Mongrel will only process 1 request at a time (rails is only in 1 
controller at a time).  Does this mean that to get good performance i 
need to run mongrel many times on different ports?

How many different instances of mongrel is recommended?

If this is true then it wouldn''t you agree it makes running mongrel a 
lot less simple than  "mongrel_rails start -pXXX"?

Also what is the simplest software to use that would allow me to run 
multiple instances all accessible from the same URL?  How does it work? 
Do you assign 1 main port that all the other instances will be 
accessible from?

I am looking for the simplest solution.

Thanks
Chris

-- 
Posted via http://www.ruby-forum.com/.

if you only have 3 people accessing the application, i probably
wouldn''t worry unless you have a controller that takes a very long
time to process.  most requests are handled within milliseconds, so
it''s really a non-issue.

if you do find yourself needing something more robust, take a look at
mongrel_cluster.

Chris

On 8/9/06, Chris <cadams1342@hotmail.com> wrote:
> I have developed a rails application for my company.
>
> It will be used by upto 3o people at a time.  I have just read that
> Mongrel will only process 1 request at a time (rails is only in 1
> controller at a time).  Does this mean that to get good performance i
> need to run mongrel many times on different ports?
>
> How many different instances of mongrel is recommended?
>
> If this is true then it wouldn''t you agree it makes running
mongrel a
> lot less simple than  "mongrel_rails start -pXXX"?
>
> Also what is the simplest software to use that would allow me to run
> multiple instances all accessible from the same URL?  How does it work?
> Do you assign 1 main port that all the other instances will be
> accessible from?
>
> I am looking for the simplest solution.
>
> Thanks
> Chris
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

This is a common question.

You''re correct: Rails can only handle one request at a time.  HOWEVER,
you
have to know how long the reqest is. 30 people will most likey NOT be using
the application at the SAME TIME because web apps connect you and then
disconnect you.  In the unlikely event that requests overlap, the users will
just wait in line until the server can get to them.

You should run performance tests and determine your site''s capabilities
in
terms of ''requests per second''

Your deployment platform makes a huge difference. One instance of Mongrel
running on Linux can often be as performant as three instances of Mongrel on
Windows.


Use httperf on Linux to test your URLs to see how many requests per second
you can handle with your current server.

As for simplicity:

Mongrel_cluster is a plugin that will let you set up multiple instances of
Mongrel, each on its own port. You have to use Linux for this.

Pen is a simple load balancer that can link them together.

Say I have two instances of Mongrel running, one on port 4001 and one on
port 4002;

To start listening on port 4000 with Pen, I just do

   pen -r 4000 localhost:4001 localhost:4002

General rules apply here too... you need to optimize your application. Use
page caching whenever possible (like pages which don''t need
authentication)
and use action or fragment caching whenever you can to reduce the request
time.  Ensure you''re eager loading data when appropriate to avoid
unnecessary database access.  Make sure you''re running in production
mode so
things run faster :)

And consult the community. We''ll help you out where we can.

Good luck to you!





On 8/9/06, Chris <cadams1342@hotmail.com> wrote:
>
> I have developed a rails application for my company.
>
> It will be used by upto 3o people at a time.  I have just read that
> Mongrel will only process 1 request at a time (rails is only in 1
> controller at a time).  Does this mean that to get good performance i
> need to run mongrel many times on different ports?
>
> How many different instances of mongrel is recommended?
>
> If this is true then it wouldn''t you agree it makes running
mongrel a
> lot less simple than  "mongrel_rails start -pXXX"?
>
> Also what is the simplest software to use that would allow me to run
> multiple instances all accessible from the same URL?  How does it work?
> Do you assign 1 main port that all the other instances will be
> accessible from?
>
> I am looking for the simplest solution.
>
> Thanks
> Chris
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060809/bc7b7f20/attachment.html

On 8/9/06, Chris <cadams1342@hotmail.com> wrote:
> I have developed a rails application for my company.
>
> It will be used by upto 3o people at a time.  I have just read that
> Mongrel will only process 1 request at a time (rails is only in 1
> controller at a time).  Does this mean that to get good performance i
> need to run mongrel many times on different ports?
>
> How many different instances of mongrel is recommended?
>
> If this is true then it wouldn''t you agree it makes running
mongrel a
> lot less simple than  "mongrel_rails start -pXXX"?
>
> Also what is the simplest software to use that would allow me to run
> multiple instances all accessible from the same URL?  How does it work?
> Do you assign 1 main port that all the other instances will be
> accessible from?
>
> I am looking for the simplest solution.
>
> Thanks
> Chris
>
http://mongrel.rubyforge.org/index.html


Isak

On Aug 9, 2006, at 5:30 AM, Brian Hogan wrote:
> General rules apply here too... you need to optimize your  
> application. Use page caching whenever possible (like pages which  
> don''t need authentication) and use action or fragment caching  
> whenever you can to reduce the request time.  Ensure you''re eager
> loading data when appropriate to avoid unnecessary database access.
With 30 users using it at once, even these steps are pre- 
optimizations. :-)

-- 
-- Tom Mornini