|
»
»
« Return to Thread: JRuby on Rails - Deployment Options
Re: JRuby on Rails - Deployment Options
by Jacob Kessler
::
Rate this Message:
(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
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
« Return to Thread: JRuby on Rails - Deployment Options
| Free embeddable forum powered by Nabble | Forum Help |
