JRuby on Rails - Deployment Options

[Matthew Winter]

Hi,

I was wondering if anyone has done some tests with regards to different deployment options for JRuby on Rails.

Ideally open source deployment options. So far I have come up with the following, different combinations:

• Jetty
• Glassfish
• JBoss
• Apache + Tomcat
• Apache + Jetty
• Nginx + Tomcat
• Nginx + Jetty

I am sure there are a lot more options available.

What do people currently have running in production and how have you found the deployment option with regards to performance and memory utilisation.

I have read various blog posts on the subject, but most seem to concentrate on how easy the deployment option is rather than how effective a solution it is.

For example, would it still be beneficial to place a HTTP server such as Apache, Nginx, etc in front of the Java servlet container, much like a standard RoR deployment option. Reading the Jetty, Glassfish and JBoss sites seem to suggest that you do not have to do this, and you will still be able to achieve the same or at least similar levels of performance, but I would have thought that it would still have been beneficial to place static objects behind a HTTP server, and then share the JRoR load across multiple Java servlet containers, so handling concurrency more effectively.

Any help, information on this would be most appreciated.

Regards

Matthew Winter

[JannaB]

Some parts of this message have been removed. Learn more about Nabble's security policy.

apache (1.3.x, really!) virtualhosted to glassfish gem. BLAZING! No warring-up of the file, simple to set up, solid as can be. -Janna

---

From: wintermi@...
To: user@...
Date: Sun, 21 Jun 2009 22:12:46 +1000
Subject: [jruby-user] JRuby on Rails - Deployment Options

Hi,

I was wondering if anyone has done some tests with regards to different deployment options for JRuby on Rails.

Ideally open source deployment options. So far I have come up with the following, different combinations:

• Jetty
• Glassfish
• JBoss
• Apache + Tomcat
• Apache + Jetty
• Nginx + Tomcat
• Nginx + Jetty

I am sure there are a lot more options available.

What do people currently have running in production and how have you found the deployment option with regards to performance and memory utilisation.

I have read various blog posts on the subject, but most seem to concentrate on how easy the deployment option is rather than how effective a solution it is.

For example, would it still be beneficial to place a HTTP server such as Apache, Nginx, etc in front of the Java servlet container, much like a standard RoR deployment option. Reading the Jetty, Glassfish and JBoss sites seem to suggest that you do not have to do this, and you will still be able to achieve the same or at least similar levels of performance, but I would have thought that it would still have been beneficial to place static objects behind a HTTP server, and then share the JRoR load across multiple Java servlet containers, so handling concurrency more effectively.

Any help, information on this would be most appreciated.

Regards

Matthew Winter

---

Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it out.

[Bob McWhirter-2]

Ideally open source deployment options. So far I have come up with the following, different combinations:

• JBoss

Not sure if you're aware, but in addition to just warbling on JBoss, we (JBoss) also have TorqueBox, a more "natural" way to do rails.

It supports capistrano-based deployments, also with some included cap recipes to manage your server.

http://torquebox.org/

-Bob

[Frederic Jean-3]

Matthew Winter wrote:

Hi,

I was wondering if anyone has done some tests with regards to different deployment options for JRuby on Rails.

Ideally open source deployment options. So far I have come up with the following, different combinations:

• Jetty
• Glassfish
• JBoss
• Apache + Tomcat
• Apache + Jetty
• Nginx + Tomcat
• Nginx + Jetty

I am sure there are a lot more options available.

What do people currently have running in production and how have you found the deployment option with regards to performance and memory utilisation.

I have read various blog posts on the subject, but most seem to concentrate on how easy the deployment option is rather than how effective a solution it is.

For example, would it still be beneficial to place a HTTP server such as Apache, Nginx, etc in front of the Java servlet container, much like a standard RoR deployment option. Reading the Jetty, Glassfish and JBoss sites seem to suggest that you do not have to do this, and you will still be able to achieve the same or at least similar levels of performance, but I would have thought that it would still have been beneficial to place static objects behind a HTTP server, and then share the JRoR load across multiple Java servlet containers, so handling concurrency more effectively.

Hi Matthew,

I think that you are on the right path with having a static HTTP server fronting your application servers. Both Apache and nginx will do a great job of serving the static content and load balancing between the servlet container running your applications. The servlet containers can certainly serve static content, but they are not as effecient as Apache or nginx at doing so. My preference is to reserve application severs (whether servlet containers, Mongrels or FastCGI processes) to generate dynamic content.

We currently use Apache HTTPD to front our application servers on Project Kenai. We are still using Glassfish V2 to run our web application (a JRuby on Rails app). It works well enough for us.

I have used nginx to front another Rails application. I prefer the nginx configuration file syntax to the Apache HTTPD one.

I hope that this helps.

Fred

Any help, information on this would be most appreciated.

Regards

Matthew Winter

[Joseph Athman]

I think you should try to go with the most simple solution you can that will handle the load your site has.  There's no sense in making a load balanced clustered server environment with Apache/Nginx and app servers if you have 10 users.  All it does is add complication without any perceivable benefit.  We have been using the glassfish gem and it works great.  Dead simple and handles a nice load as well.  If you are using a new version of Rails and can turn on multithreaded mode you will get some nice throughput without as big of a memory footprint.

Joe

On Sun, Jun 21, 2009 at 10:36 AM, Frederic Jean <fred@...> wrote:

Matthew Winter wrote:

Hi,

I was wondering if anyone has done some tests with regards to different deployment options for JRuby on Rails.

Ideally open source deployment options. So far I have come up with the following, different combinations:

• Jetty
• Glassfish
• JBoss
• Apache + Tomcat
• Apache + Jetty
• Nginx + Tomcat
• Nginx + Jetty

I am sure there are a lot more options available.

What do people currently have running in production and how have you found the deployment option with regards to performance and memory utilisation.

I have read various blog posts on the subject, but most seem to concentrate on how easy the deployment option is rather than how effective a solution it is.

For example, would it still be beneficial to place a HTTP server such as Apache, Nginx, etc in front of the Java servlet container, much like a standard RoR deployment option. Reading the Jetty, Glassfish and JBoss sites seem to suggest that you do not have to do this, and you will still be able to achieve the same or at least similar levels of performance, but I would have thought that it would still have been beneficial to place static objects behind a HTTP server, and then share the JRoR load across multiple Java servlet containers, so handling concurrency more effectively.

Hi Matthew,

I think that you are on the right path with having a static HTTP server fronting your application servers. Both Apache and nginx will do a great job of serving the static content and load balancing between the servlet container running your applications. The servlet containers can certainly serve static content, but they are not as effecient as Apache or nginx at doing so. My preference is to reserve application severs (whether servlet containers, Mongrels or FastCGI processes) to generate dynamic content.

We currently use Apache HTTPD to front our application servers on Project Kenai. We are still using Glassfish V2 to run our web application (a JRuby on Rails app). It works well enough for us.

I have used nginx to front another Rails application. I prefer the nginx configuration file syntax to the Apache HTTPD one.

I hope that this helps.

Fred

Any help, information on this would be most appreciated.

Regards

Matthew Winter

[Matthew Winter]

Hi,

I will take a look thanks.

Regards

Matthew Winter

On 22/06/2009, at 12:52 AM, Bob McWhirter wrote:

Ideally open source deployment options. So far I have come up with the following, different combinations:

• JBoss

Not sure if you're aware, but in addition to just warbling on JBoss, we (JBoss) also have TorqueBox, a more "natural" way to do rails.

It supports capistrano-based deployments, also with some included cap recipes to manage your server.

http://torquebox.org/

-Bob

[Matthew Winter]

Hi,

Thanks for the information.

I have done some testing with Glassfish and found it to be super  
simple. My only concern was the memory footprint, which I guess is a  
trade off with being feature rich. I have not tried V3 yet, do you  
know if this version has a lower memory footprint?

Regards
Matthew Winter


On 22/06/2009, at 1:36 AM, Frederic Jean wrote:

> Hi Matthew,
>
> I think that you are on the right path with having a static HTTP  
> server fronting your application servers. Both Apache and nginx will  
> do a great job of serving the static content and load balancing  
> between the servlet container running your applications. The servlet  
> containers can certainly serve static content, but they are not as  
> effecient as Apache or nginx at doing so. My preference is to  
> reserve application severs (whether servlet containers, Mongrels or  
> FastCGI processes) to generate dynamic content.
>
> We currently use Apache HTTPD to front our application servers on  
> Project Kenai. We are still using Glassfish V2 to run our web  
> application (a JRuby on Rails app). It works well enough for us.
>
> I have used nginx to front another Rails application. I prefer the  
> nginx configuration file syntax to the Apache HTTPD one.
>
> I hope that this helps.
>
> Fred
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Matthew Winter]

Hi,

Agreed, but I would prefer to deploy with an option that could scale  
if and when the user numbers require it.

I am using Rails 2.3.2 so threading is an option. Do you know if  
anyone has published any figures comparing threaded and non-threaded  
on a JRuby implementation?

Thanks.

Regards
Matthew Winter


On 22/06/2009, at 6:27 AM, Joseph Athman wrote:

> I think you should try to go with the most simple solution you can  
> that will handle the load your site has.  There's no sense in making  
> a load balanced clustered server environment with Apache/Nginx and  
> app servers if you have 10 users.  All it does is add complication  
> without any perceivable benefit.  We have been using the glassfish  
> gem and it works great.  Dead simple and handles a nice load as  
> well.  If you are using a new version of Rails and can turn on  
> multithreaded mode you will get some nice throughput without as big  
> of a memory footprint.
>
> Joe

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Joseph Athman]

I'm not really sure on specific numbers but I think the biggest advantage will be with memory usage.  If you do not go with the threaded mode then you will either need to have multiple servers and/or multiple rails instances per server.  If I were you I would try out the glassfish gem and turn on the threaded mode in rails and see what kind of performance and memory footprint you have.  I'm pretty sure the GF gem will configure itself to only use one Rails instance if it detects multi-threaded mode has been enabled.

If you go with any of the app server only options to start you can always configure apache to front them later if the need arises.  Unless you know apache well and setting that part up is trivial.  Being a Java person my whole life I wasn't really comfortable dealing with Apache right from the start.  Good luck.

Joe

On Sun, Jun 21, 2009 at 4:52 PM, Matthew Winter <wintermi@...> wrote:

Hi,

Agreed, but I would prefer to deploy with an option that could scale if and when the user numbers require it.

I am using Rails 2.3.2 so threading is an option. Do you know if anyone has published any figures comparing threaded and non-threaded on a JRuby implementation?

Thanks.

Regards
Matthew Winter

On 22/06/2009, at 6:27 AM, Joseph Athman wrote:

I think you should try to go with the most simple solution you can that will handle the load your site has.  There's no sense in making a load balanced clustered server environment with Apache/Nginx and app servers if you have 10 users.  All it does is add complication without any perceivable benefit.  We have been using the glassfish gem and it works great.  Dead simple and handles a nice load as well.  If you are using a new version of Rails and can turn on multithreaded mode you will get some nice throughput without as big of a memory footprint.

Joe

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[Jacob Kessler]

(Disclaimer: I'm one of Sun's GlassFish engineers)

As with most Java applications, GlassFish's memory footprint depends
quite heavily on how much memory you tell it it can use. I've found
GlassFish V3 server running a complex JRuby app seems to like 128MB of
heap + 64MB of permgen, and about the same for GlassFish gem. You'll
likely have to increase that if you've got a very complicated app,
though. I wrote a blog about sizing GlassFish a while ago
(http://blogs.sun.com/Jacobkessler/entry/four_guidelines_for_sizing_jruby),
if you are really concerned with trying to reduce memory footprint as
much as possible.

While I can't refer to any published figures for threaded vs.
non-threaded rails, I've found that with GlassFish (either V3 server or
gem) it represents a 30% or so memory increase, but since you only need
a single instance it's worth it if you would need to run more than one
Rails instance to serve your load. As Joseph mentioned, GlassFish gem
should automatically detect that you are running Rails in multithreaded
mode and configure itself to take advantage of that.

Though GlassFish gem can serve your static content for you, if you are
talking about a large deployment you're likely better off putting a
static file server/load balancer in front of it. GlassFish gem should be
able to scale out to the limits of the machine you are running it on,
but if you want multiple machines serving your application (for
redundancy, to handle more load, whatever), you'll want a load balancer
anyway.

Hopefully that helps, I'd be happy to answer any other questions you had
about GlassFish.

Matthew Winter wrote:

> Hi,
>
> Thanks for the information.
>
> I have done some testing with Glassfish and found it to be super
> simple. My only concern was the memory footprint, which I guess is a
> trade off with being feature rich. I have not tried V3 yet, do you
> know if this version has a lower memory footprint?
>
> Regards
> Matthew Winter
>
>
> On 22/06/2009, at 1:36 AM, Frederic Jean wrote:
>
>> Hi Matthew,
>>
>> I think that you are on the right path with having a static HTTP
>> server fronting your application servers. Both Apache and nginx will
>> do a great job of serving the static content and load balancing
>> between the servlet container running your applications. The servlet
>> containers can certainly serve static content, but they are not as
>> effecient as Apache or nginx at doing so. My preference is to reserve
>> application severs (whether servlet containers, Mongrels or FastCGI
>> processes) to generate dynamic content.
>>
>> We currently use Apache HTTPD to front our application servers on
>> Project Kenai. We are still using Glassfish V2 to run our web
>> application (a JRuby on Rails app). It works well enough for us.
>>
>> I have used nginx to front another Rails application. I prefer the
>> nginx configuration file syntax to the Apache HTTPD one.
>>
>> I hope that this helps.
>>
>> Fred
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-4]

On Tue, Jun 23, 2009 at 4:37 PM, Jacob Kessler<Jacob.Kessler@...> wrote:
> While I can't refer to any published figures for threaded vs. non-threaded
> rails, I've found that with GlassFish (either V3 server or gem) it
> represents a 30% or so memory increase, but since you only need a single
> instance it's worth it if you would need to run more than one Rails instance
> to serve your load. As Joseph mentioned, GlassFish gem should automatically
> detect that you are running Rails in multithreaded mode and configure itself
> to take advantage of that.

There's another advantage to running threadsafe with Rails: faster
warmup. With many instances of Rails, each one has its own warmup
cycle before methods compile, caches fill, etc. Running in threadsafe
mode warms up a lot faster.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Christian Seiler-3]

Charles Oliver Nutter wrote:

> On Tue, Jun 23, 2009 at 4:37 PM, Jacob Kessler<Jacob.Kessler@...> wrote:
>> While I can't refer to any published figures for threaded vs. non-threaded
>> rails, I've found that with GlassFish (either V3 server or gem) it
>> represents a 30% or so memory increase, but since you only need a single
>> instance it's worth it if you would need to run more than one Rails instance
>> to serve your load. As Joseph mentioned, GlassFish gem should automatically
>> detect that you are running Rails in multithreaded mode and configure itself
>> to take advantage of that.
>
> There's another advantage to running threadsafe with Rails: faster
> warmup. With many instances of Rails, each one has its own warmup
> cycle before methods compile, caches fill, etc. Running in threadsafe
> mode warms up a lot faster.
>

When running not threadsafe: Doesn't it depend on how the app servers
handle the allocation of Ruby runtimes? I think JRuby-Rack doesn't use
round robin (I could be wrong there though), so - unless you have some
concurrent load - only one Ruby instance is being warmed up?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nick Sieger-2]

On Wed, Jul 1, 2009 at 12:00 PM, Christian Seiler<chr.seiler@...> wrote:

> Charles Oliver Nutter wrote:
>>
>> On Tue, Jun 23, 2009 at 4:37 PM, Jacob Kessler<Jacob.Kessler@...>
>> wrote:
>>>
>>> While I can't refer to any published figures for threaded vs.
>>> non-threaded
>>> rails, I've found that with GlassFish (either V3 server or gem) it
>>> represents a 30% or so memory increase, but since you only need a single
>>> instance it's worth it if you would need to run more than one Rails
>>> instance
>>> to serve your load. As Joseph mentioned, GlassFish gem should
>>> automatically
>>> detect that you are running Rails in multithreaded mode and configure
>>> itself
>>> to take advantage of that.
>>
>> There's another advantage to running threadsafe with Rails: faster
>> warmup. With many instances of Rails, each one has its own warmup
>> cycle before methods compile, caches fill, etc. Running in threadsafe
>> mode warms up a lot faster.
>>
>
> When running not threadsafe: Doesn't it depend on how the app servers handle
> the allocation of Ruby runtimes? I think JRuby-Rack doesn't use round robin
> (I could be wrong there though), so - unless you have some concurrent load -
> only one Ruby instance is being warmed up?

That's correct, it currently doesn't. Should it? Perhaps I should
treat the runtime pool like a queue and not a stack.

/Nick

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Christian Seiler-3]

Nick Sieger wrote:

> On Wed, Jul 1, 2009 at 12:00 PM, Christian Seiler<chr.seiler@...> wrote:
>> Charles Oliver Nutter wrote:
>>> On Tue, Jun 23, 2009 at 4:37 PM, Jacob Kessler<Jacob.Kessler@...>
>>> wrote:
>>>> While I can't refer to any published figures for threaded vs.
>>>> non-threaded
>>>> rails, I've found that with GlassFish (either V3 server or gem) it
>>>> represents a 30% or so memory increase, but since you only need a single
>>>> instance it's worth it if you would need to run more than one Rails
>>>> instance
>>>> to serve your load. As Joseph mentioned, GlassFish gem should
>>>> automatically
>>>> detect that you are running Rails in multithreaded mode and configure
>>>> itself
>>>> to take advantage of that.
>>> There's another advantage to running threadsafe with Rails: faster
>>> warmup. With many instances of Rails, each one has its own warmup
>>> cycle before methods compile, caches fill, etc. Running in threadsafe
>>> mode warms up a lot faster.
>>>
>> When running not threadsafe: Doesn't it depend on how the app servers handle
>> the allocation of Ruby runtimes? I think JRuby-Rack doesn't use round robin
>> (I could be wrong there though), so - unless you have some concurrent load -
>> only one Ruby instance is being warmed up?
>
> That's correct, it currently doesn't. Should it? Perhaps I should
> treat the runtime pool like a queue and not a stack.
>

I think I'd call it a feature that apps without much load (concurrency)
warm up as fast as they would with config.threadsafe!


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email