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.
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: [email protected]
To: [email protected]
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:
JettyGlassfishJBossApache + TomcatApache + JettyNginx + TomcatNginx +
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.
RegardsMatthew W.
utilisation.
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 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.
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?
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?
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.
(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 W. wrote:
Matthew W.
containers can certainly serve static content, but they are not as
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.