Hi I''m running several smallish apps each with small audiences and few users, all on the same server. We''re currently deploying on Apache+FastCGI with few problems, except the fact that each app starts a new dedicated Ruby process. The combined performance demand on the server shouldn''t be very high, but since the amount of apps is in the thirties and since each and every one uses its own Ruby process, this results in quite a bit of overhead. My question is if this can be avoided. Is it possible to run many apps that reuse the same Ruby processes and thus result in less pressure on the server? What are my options? Best regards, Tomas Jogin, Sweden --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Tomas Jogin wrote:> Hi > > I''m running several smallish apps each with small audiences and few > users, all on the same server. We''re currently deploying on > Apache+FastCGI with few problems, except the fact that each app starts > a new dedicated Ruby process. The combined performance demand on the > server shouldn''t be very high, but since the amount of apps is in the > thirties and since each and every one uses its own Ruby process, this > results in quite a bit of overhead. > > My question is if this can be avoided. Is it possible to run many apps > that reuse the same Ruby processes and thus result in less pressure on > the server? What are my options? > > Best regards, > Tomas Jogin, Swedenthis part is pretty hard. I just ran into the same situation and i still havent found an answer. I was able to lessen the load. In lighttpd you can set the number of FCGI processes per app. I set this to 1 for each app and was able to push the server (Athlon XP 2600, 1.5GB RAM) to about 90 sites with decent traffic. i think you can do this with Apache also. The problem is that each app needs its own FCGI process. With the current Capistrano type deployment, you have one app with many users. This type of installation is much easier, because all of your users go to one app, but in your case, you would need to separate them and that''s when stuff gets a little crazy. Sorry, --jake -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Right now I don''t think there is. You have to run at least 1 process per Rails app. This is true with FCGI and Mongrel. CGI runs and completes its process after Rails does its business (I believe) The only hope for situations like this _might_ be the jRuby project. http://headius.blogspot.com/2006/04/beginning-of-jruby-on-rails.html On 12/28/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Hi > > I''m running several smallish apps each with small audiences and few > users, all on the same server. We''re currently deploying on > Apache+FastCGI with few problems, except the fact that each app starts > a new dedicated Ruby process. The combined performance demand on the > server shouldn''t be very high, but since the amount of apps is in the > thirties and since each and every one uses its own Ruby process, this > results in quite a bit of overhead. > > My question is if this can be avoided. Is it possible to run many apps > that reuse the same Ruby processes and thus result in less pressure on > the server? What are my options? > > Best regards, > Tomas Jogin, Sweden > > > >-- -------------------- seth at subimage interactive ----- http://www.subimage.com http://sublog.subimage.com ----- http://www.getcashboard.com http://dev.subimage.com/projects/substruct --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 28, 2006, at 3:58 PM, subimage interactive wrote:> Right now I don''t think there is. You have to run at least 1 > process per Rails app. This is true with FCGI and Mongrel. CGI runs > and completes its process after Rails does its business (I believe) > > The only hope for situations like this _might_ be the jRuby project. > > http://headius.blogspot.com/2006/04/beginning-of-jruby-on-rails.html >_why has been doing some interesting work with sandboxing in the ruby interpreter that may help with this someday too: http://redhanded.hobix.com/inspect/ theThrillingFreakyFreakySandboxHack.html -JD Harrington --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Yes, there is. Take a look at LiteSpeed. It creates processes as necessary, that is, dynamically. / Peter On 28 dec 2006, at 21.58, subimage interactive wrote:> Right now I don''t think there is. You have to run at least 1 > process per Rails app. This is true with FCGI and Mongrel. CGI runs > and completes its process after Rails does its business (I believe) > > The only hope for situations like this _might_ be the jRuby project. > > http://headius.blogspot.com/2006/04/beginning-of-jruby-on-rails.html > > On 12/28/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Hi > > I''m running several smallish apps each with small audiences and few > users, all on the same server. We''re currently deploying on > Apache+FastCGI with few problems, except the fact that each app starts > a new dedicated Ruby process. The combined performance demand on the > server shouldn''t be very high, but since the amount of apps is in the > thirties and since each and every one uses its own Ruby process, this > results in quite a bit of overhead. > > My question is if this can be avoided. Is it possible to run many apps > that reuse the same Ruby processes and thus result in less pressure on > the server? What are my options? > > Best regards, > Tomas Jogin, Sweden > > > > > > > -- > -------------------- > seth at subimage interactive > ----- > http://www.subimage.com > http://sublog.subimage.com > ----- > http://www.getcashboard.com > http://dev.subimage.com/projects/substruct > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
That''s what I was afraid of.. Peter, I think you misunderstood the question; I believe LiteSpeed too creates one process per app (key word: per app) and THEN creates more as necessary as per your description. If you, indeed, didn''t misunderstand, and isn''t mistaking, I''d love it if you could confirm it. However, I don''t think it''s possible, because I suspect this is an issue with Rails itself, not the various dispatching solutions, since the processes cache the model classes in memory, how could they possibly contain several apps per process? Severe changes to Rails itself would be necessary for a single Ruby process to be used *by multiple Rails apps at once*. Again, I''m only almost certain of this, if somebody with definite knowledge on the subject can confirm or deny this, I''d really appreciate it. Does anyone know if this issue is being investigated at all, if anyone has addressed this concern before? As it stands now, Rails is an excellent choice if you only run one or a couple of big apps on the same server.. but for many smallish apps, its barely useable, which IMHO is a damn shame. Best regards, Tomas Jogin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote:> Does anyone know if this issue is being investigated at all, if anyone > has addressed this concern before? As it stands now, Rails is an > excellent choice if you only run one or a couple of big apps on the > same server.. but for many smallish apps, its barely useable, which > IMHO is a damn shame.It''s only a usability problem with respect to resources, and the only way to measure that is against the entire pool of resources required to create and maintain the application as well. For instance, let''s say that Ruby is 16 times as expensive in terms of memory as something else. What is the cost of that memory compared to the cost advantage (if any!) of development speed and maintainability of the application itself? Memory is not expensive these days, and it''s getting less expensive each and every day. -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
What does the development speed have to do with being able to run multiple apps per process, or not being able to? I fail to see how the two have any relation what so ever. On 12/29/06, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote:> > On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote: > > > Does anyone know if this issue is being investigated at all, if anyone > > has addressed this concern before? As it stands now, Rails is an > > excellent choice if you only run one or a couple of big apps on the > > same server.. but for many smallish apps, its barely useable, which > > IMHO is a damn shame. > > It''s only a usability problem with respect to resources, and the only > way to measure that is against the entire pool of resources required > to create and maintain the application as well. > > For instance, let''s say that Ruby is 16 times as expensive in terms > of memory as something else. What is the cost of that memory compared > to the cost advantage (if any!) of development speed and maintainability > of the application itself? > > Memory is not expensive these days, and it''s getting less expensive > each and every day. > > -- > -- Tom Mornini, CTO > -- Engine Yard, Ruby on Rails Hosting > -- Reliability, Ease of Use, Scalability > -- (866) 518-YARD (9273) > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Tomas Jogin wrote:> > What does the development speed have to do with being able to run > multiple apps per process, or not being able to? I fail to see how the > two have any relation what so ever.Both contribute to the total cost of ownership of the application. Rails may use more memory than other web technologies, but memory is cheap - if Rails saves development and maintenance effort, and gets you to market faster, that''s an overall win. regards Justin Forder> On 12/29/06, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote: >> >> On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote: >> >> > Does anyone know if this issue is being investigated at all, if anyone >> > has addressed this concern before? As it stands now, Rails is an >> > excellent choice if you only run one or a couple of big apps on the >> > same server.. but for many smallish apps, its barely useable, which >> > IMHO is a damn shame. >> >> It''s only a usability problem with respect to resources, and the only >> way to measure that is against the entire pool of resources required >> to create and maintain the application as well. >> >> For instance, let''s say that Ruby is 16 times as expensive in terms >> of memory as something else. What is the cost of that memory compared >> to the cost advantage (if any!) of development speed and maintainability >> of the application itself? >> >> Memory is not expensive these days, and it''s getting less expensive >> each and every day. >> >> -- >> -- Tom Mornini, CTO >> -- Engine Yard, Ruby on Rails Hosting >> -- Reliability, Ease of Use, Scalability >> -- (866) 518-YARD (9273) >> >> >> > >> > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
So, in what way are they mutually exclusive? How would it negatively impact he development speed if Rails apps could share processes? I''m not a newbie to Rails, I''ve been using it for over two years and I''m quite familiar with the productivity gains. Nowhere have I claimed otherwise. I''m just having a performance problem even though I have small audiences and few users. If apps could share processes, it would decrease costs significantly, since each server could be used with less overhead. On 12/29/06, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote:> > Tomas Jogin wrote: > > > > What does the development speed have to do with being able to run > > multiple apps per process, or not being able to? I fail to see how the > > two have any relation what so ever. > > Both contribute to the total cost of ownership of the application. > > Rails may use more memory than other web technologies, but memory is > cheap - if Rails saves development and maintenance effort, and gets you > to market faster, that''s an overall win. > > regards > > Justin Forder > > > On 12/29/06, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote: > >> > >> On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote: > >> > >> > Does anyone know if this issue is being investigated at all, if anyone > >> > has addressed this concern before? As it stands now, Rails is an > >> > excellent choice if you only run one or a couple of big apps on the > >> > same server.. but for many smallish apps, its barely useable, which > >> > IMHO is a damn shame. > >> > >> It''s only a usability problem with respect to resources, and the only > >> way to measure that is against the entire pool of resources required > >> to create and maintain the application as well. > >> > >> For instance, let''s say that Ruby is 16 times as expensive in terms > >> of memory as something else. What is the cost of that memory compared > >> to the cost advantage (if any!) of development speed and maintainability > >> of the application itself? > >> > >> Memory is not expensive these days, and it''s getting less expensive > >> each and every day. > >> > >> -- > >> -- Tom Mornini, CTO > >> -- Engine Yard, Ruby on Rails Hosting > >> -- Reliability, Ease of Use, Scalability > >> -- (866) 518-YARD (9273) > >> > >> > >> > > >> > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Tomas, did you consider trying out mod_ruby? Andre --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Is mod_ruby even a viable alternative? I''ve never heard of anyone using it for RoR? Actually I did *think* about it, but wrote it off based on what I just said. Was that in haste? On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Tomas, did you consider trying out mod_ruby? > > Andre > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Tomas Jogin wrote:> So, in what way are they mutually exclusive? How would it negatively > impact he development speed if Rails apps could share processes?In principle they are orthogonal. In practice, they are constrained by the way Rails is at present. Nobody has suggested that it would be a bad thing if a process could host more than one Rails application - Dave Thomas has suggested it would be good for Rails to have a ''container'' that applications could be deployed into, and Why''s sandbox appears to be a step in that direction.> I''m not a newbie to Rails, I''ve been using it for over two years and > I''m quite familiar with the productivity gains. Nowhere have I claimed > otherwise. I''m just having a performance problem even though I have > small audiences and few users. If apps could share processes, it would > decrease costs significantly, since each server could be used with > less overhead.I picked up on the memory aspect, because it is frequently discussed and because Tom gave memory use as an example of resource use - but you seem to be saying that you have performance problems relating to the number of processes running, before memory becomes a problem. Can you say more about this? regards Justin> On 12/29/06, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: >> >> Tomas Jogin wrote: >> > >> > What does the development speed have to do with being able to run >> > multiple apps per process, or not being able to? I fail to see how the >> > two have any relation what so ever. >> >> Both contribute to the total cost of ownership of the application. >> >> Rails may use more memory than other web technologies, but memory is >> cheap - if Rails saves development and maintenance effort, and gets you >> to market faster, that''s an overall win. >> >> regards >> >> Justin Forder >> >> > On 12/29/06, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote: >> >> >> >> On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote: >> >> >> >> > Does anyone know if this issue is being investigated at all, if >> anyone >> >> > has addressed this concern before? As it stands now, Rails is an >> >> > excellent choice if you only run one or a couple of big apps on the >> >> > same server.. but for many smallish apps, its barely useable, which >> >> > IMHO is a damn shame. >> >> >> >> It''s only a usability problem with respect to resources, and the only >> >> way to measure that is against the entire pool of resources required >> >> to create and maintain the application as well. >> >> >> >> For instance, let''s say that Ruby is 16 times as expensive in terms >> >> of memory as something else. What is the cost of that memory compared >> >> to the cost advantage (if any!) of development speed and >> maintainability >> >> of the application itself? >> >> >> >> Memory is not expensive these days, and it''s getting less expensive >> >> each and every day. >> >> >> >> -- >> >> -- Tom Mornini, CTO >> >> -- Engine Yard, Ruby on Rails Hosting >> >> -- Reliability, Ease of Use, Scalability >> >> -- (866) 518-YARD (9273)--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I''m using it for internal applications here and it''s working fine. Version 1.2.6 has a RailsDispatcher that addresses the problems that occurred with the shared interpreters in previous versions. I still haven''t made it available for our customers, but it might be worth giving it a try, since at least in theory it should do what you need. Regards, Andre On 12/29/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Is mod_ruby even a viable alternative? I''ve never heard of anyone > using it for RoR? Actually I did *think* about it, but wrote it off > based on what I just said. Was that in haste? > > On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Tomas, did you consider trying out mod_ruby? > > > > Andre > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > I''m not a newbie to Rails, I''ve been using it for over two years and > > I''m quite familiar with the productivity gains. Nowhere have I claimed > > otherwise. I''m just having a performance problem even though I have > > small audiences and few users. If apps could share processes, it would > > decrease costs significantly, since each server could be used with > > less overhead. > > I picked up on the memory aspect, because it is frequently discussed and > because Tom gave memory use as an example of resource use - but you seem > to be saying that you have performance problems relating to the number > of processes running, before memory becomes a problem. Can you say more > about this?I''m the same guy. I''m asking questions related to how to improve the per-server performance of Rails. Since I''m running several apps, the server starts a new Ruby process for each app. This means I have thirty or more Ruby processes running. However, just one or two processes would suffice to handle the combined load. That means the server uses 15 to 30 times more processes than necessary, simply because of how Rails internals work. If Rails apps could share processes, I would get 15-30 times more performance or more PER SERVER. That''s one of them... "limitations", to misquote Bush. So I''m here to ask if anyone else has run into this particular problem of running many small apps and having the performance sucked out of the server NOT due to overwhelming amounts of visitors, but because apps can''t share processes. That''s all. I''m already aware of the productivity gains of using Rails, have been for over two years. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
That''s very interesting. I just read a blog post by Shugo regarding the topic: http://blog.shugo.net/articles/2005/08/03/running-rails-on-mod_ruby Running Rails on mod_ruby, does it come with any pitfalls or limitations? Regards, Tomas On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I''m using it for internal applications here and it''s working fine. > Version 1.2.6 has a RailsDispatcher that addresses the problems that > occurred with the shared interpreters in previous versions. > > I still haven''t made it available for our customers, but it might be > worth giving it a try, since at least in theory it should do what you > need. > > Regards, > Andre > > > On 12/29/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Is mod_ruby even a viable alternative? I''ve never heard of anyone > > using it for RoR? Actually I did *think* about it, but wrote it off > > based on what I just said. Was that in haste? > > > > On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Tomas, did you consider trying out mod_ruby? > > > > > > Andre > > > > > > > > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Yes, I decided to try it after reading Shugo''s blog. The only pitfall I found so far is that everything in your application is "packed" into the Apache::RailsDispatcher::CURRENT_MODULE module. I had some code that depended on the the class of a given object to choose the action it would take, and I had to fix it by using "self.class.to_s.demodulize" instead of just "self.class.to_s" to get just "Foo" instead of "Apache::RailsDispatcher::CURRENT_MODULE::Foo". It''s no big issue after you realize what''s going on, I guess. Andre On 12/29/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > That''s very interesting. I just read a blog post by Shugo regarding > the topic: http://blog.shugo.net/articles/2005/08/03/running-rails-on-mod_ruby > > Running Rails on mod_ruby, does it come with any pitfalls or limitations? > > Regards, > Tomas > > On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > I''m using it for internal applications here and it''s working fine. > > Version 1.2.6 has a RailsDispatcher that addresses the problems that > > occurred with the shared interpreters in previous versions. > > > > I still haven''t made it available for our customers, but it might be > > worth giving it a try, since at least in theory it should do what you > > need. > > > > Regards, > > Andre > > > > > > On 12/29/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Is mod_ruby even a viable alternative? I''ve never heard of anyone > > > using it for RoR? Actually I did *think* about it, but wrote it off > > > based on what I just said. Was that in haste? > > > > > > On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Tomas, did you consider trying out mod_ruby? > > > > > > > > Andre > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks, that''s very interesting. I''ll have to investigate this further. Best regards, Tomas Jogin On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Yes, I decided to try it after reading Shugo''s blog. > > The only pitfall I found so far is that everything in your application > is "packed" into the Apache::RailsDispatcher::CURRENT_MODULE module. I > had some code that depended on the the class of a given object to > choose the action it would take, and I had to fix it by using > "self.class.to_s.demodulize" instead of just "self.class.to_s" to get > just "Foo" instead of "Apache::RailsDispatcher::CURRENT_MODULE::Foo". > It''s no big issue after you realize what''s going on, I guess. > > Andre > > On 12/29/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > That''s very interesting. I just read a blog post by Shugo regarding > > the topic: http://blog.shugo.net/articles/2005/08/03/running-rails-on-mod_ruby > > > > Running Rails on mod_ruby, does it come with any pitfalls or limitations? > > > > Regards, > > Tomas > > > > On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > I''m using it for internal applications here and it''s working fine. > > > Version 1.2.6 has a RailsDispatcher that addresses the problems that > > > occurred with the shared interpreters in previous versions. > > > > > > I still haven''t made it available for our customers, but it might be > > > worth giving it a try, since at least in theory it should do what you > > > need. > > > > > > Regards, > > > Andre > > > > > > > > > On 12/29/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Is mod_ruby even a viable alternative? I''ve never heard of anyone > > > > using it for RoR? Actually I did *think* about it, but wrote it off > > > > based on what I just said. Was that in haste? > > > > > > > > On 12/29/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > Tomas, did you consider trying out mod_ruby? > > > > > > > > > > Andre > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Tomas Jogin wrote:> >> > I''m not a newbie to Rails, I''ve been using it for over two years and >> > I''m quite familiar with the productivity gains. Nowhere have I claimed >> > otherwise. I''m just having a performance problem even though I have >> > small audiences and few users. If apps could share processes, it would >> > decrease costs significantly, since each server could be used with >> > less overhead. >> >> I picked up on the memory aspect, because it is frequently discussed and >> because Tom gave memory use as an example of resource use - but you seem >> to be saying that you have performance problems relating to the number >> of processes running, before memory becomes a problem. Can you say more >> about this? > > I''m the same guy.Tom = Tom Mornini, the person whose answer caused you to ask why he brought up the issue of speed of development.> I''m asking questions related to how to improve the > per-server performance of Rails. Since I''m running several apps, the > server starts a new Ruby process for each app. This means I have > thirty or more Ruby processes running. However, just one or two > processes would suffice to handle the combined load. That means the > server uses 15 to 30 times more processes than necessary, simply > because of how Rails internals work. If Rails apps could share > processes, I would get 15-30 times more performance or more PER > SERVER. That''s one of them... "limitations", to misquote Bush.You would get the same performance with much less memory use. Having 30 idle processes should nave negligible impact on performance, unless their memory use is causing paging or swapping.> So I''m here to ask if anyone else has run into this particular problem > of running many small apps and having the performance sucked out of > the server NOT due to overwhelming amounts of visitors, but because > apps can''t share processes. > > That''s all. I''m already aware of the productivity gains of using > Rails, have been for over two years.Has anyone suggested you are not? regards Justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I wasn''t suggesting that they are mutually exclusive or that I wouldn''t like the situation to be different. But, right now, they *are* mutually exclusive: There''s no way to use Rails (and therefore gain it''s benefits) without incurring this cost. -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) On Dec 29, 2006, at 3:52 AM, Tomas Jogin wrote:> > So, in what way are they mutually exclusive? How would it negatively > impact he development speed if Rails apps could share processes? > > I''m not a newbie to Rails, I''ve been using it for over two years and > I''m quite familiar with the productivity gains. Nowhere have I claimed > otherwise. I''m just having a performance problem even though I have > small audiences and few users. If apps could share processes, it would > decrease costs significantly, since each server could be used with > less overhead. > > On 12/29/06, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote: >> >> Tomas Jogin wrote: >> > >> > What does the development speed have to do with being able to run >> > multiple apps per process, or not being able to? I fail to see >> how the >> > two have any relation what so ever. >> >> Both contribute to the total cost of ownership of the application. >> >> Rails may use more memory than other web technologies, but memory is >> cheap - if Rails saves development and maintenance effort, and >> gets you >> to market faster, that''s an overall win. >> >> regards >> >> Justin Forder >> >> > On 12/29/06, Tom Mornini <tmornini-W/9V78bTXriB+jHODAdFcQ@public.gmane.org> wrote: >> >> >> >> On Dec 28, 2006, at 4:58 PM, Tomas Jogin wrote: >> >> >> >> > Does anyone know if this issue is being investigated at all, >> if anyone >> >> > has addressed this concern before? As it stands now, Rails is an >> >> > excellent choice if you only run one or a couple of big apps >> on the >> >> > same server.. but for many smallish apps, its barely useable, >> which >> >> > IMHO is a damn shame. >> >> >> >> It''s only a usability problem with respect to resources, and >> the only >> >> way to measure that is against the entire pool of resources >> required >> >> to create and maintain the application as well. >> >> >> >> For instance, let''s say that Ruby is 16 times as expensive in >> terms >> >> of memory as something else. What is the cost of that memory >> compared >> >> to the cost advantage (if any!) of development speed and >> maintainability >> >> of the application itself? >> >> >> >> Memory is not expensive these days, and it''s getting less >> expensive >> >> each and every day. >> >> >> >> -- >> >> -- Tom Mornini, CTO >> >> -- Engine Yard, Ruby on Rails Hosting >> >> -- Reliability, Ease of Use, Scalability >> >> -- (866) 518-YARD (9273) >> >> >> >> >> >> > >> >> >> > >> > > >> > >> > >> >> >> > >> > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I feel your pain and understand your issue. I think however, that this is part of being ''opinionated software'' ... it really is about developer productivity, not server productivity. Again, I know your asking to improve server productivity and it''s a nobel cause ... I just don''t see the rails core guys caring or wanting to work on it anytime soon. Second, it''s also about using the right tool for the job and rails just isn''t the right tool for web ''pages'' or really small apps to be shared hosted with hundreds of other accounts. Sure, we all *want* to use it in that space, because we know it and it is great for productivity, but the very overhead you''re discussing is why it''s the wrong tool in ''small''space. I''ll be right there with you cheering on the solution when/if it comes, but for right now, the answer you seek doesn''t exist. On 12/28/06, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Hi > > I''m running several smallish apps each with small audiences and few > users, all on the same server. We''re currently deploying on > Apache+FastCGI with few problems, except the fact that each app starts > a new dedicated Ruby process. The combined performance demand on the > server shouldn''t be very high, but since the amount of apps is in the > thirties and since each and every one uses its own Ruby process, this > results in quite a bit of overhead. > > My question is if this can be avoided. Is it possible to run many apps > that reuse the same Ruby processes and thus result in less pressure on > the server? What are my options? > > Best regards, > Tomas Jogin, Sweden > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> But, right now, they *are* mutually exclusive: There''s no way to use > Rails (and therefore gain it''s benefits) without incurring this cost.Tomas Jogin - What you need is LiteSpeed as suggested by Peter originally. It spawns and manages application processes. If a process is idle for X seconds, the process dies (you set X obviously). You can even choose to not spawn rails processes on a server restart in which case they would be spawned when the application get hit for the first time. If you get very little traffic, you will probably see very few processes running at any given time, even if your hosting 30 rails apps. Joe --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Joe: I''ll have to look into LiteSpeed, but based on what I''ve read, neither LiteSpeed is capable of having apps share Ruby processes between themselves (which doesn''t surprise me at all). Some responses in this thread suggest that is the case: http://www.litespeedtech.com/support/forum/archive/index.php/t-581.html On 12/30/06, Joe Noon <joenoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > But, right now, they *are* mutually exclusive: There''s no way to use > > Rails (and therefore gain it''s benefits) without incurring this cost. > > Tomas Jogin - What you need is LiteSpeed as suggested by Peter > originally. It spawns and manages application processes. If a > process is idle for X seconds, the process dies (you set X obviously). > You can even choose to not spawn rails processes on a server restart > in which case they would be spawned when the application get hit for > the first time. If you get very little traffic, you will probably see > very few processes running at any given time, even if your hosting 30 > rails apps. > > Joe > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Tomas, there is no *point* in sharing Ruby processes, when they are spawned and killed according to need. On 30 dec 2006, at 08.52, Tomas Jogin wrote:> > Joe: I''ll have to look into LiteSpeed, but based on what I''ve read, > neither LiteSpeed is capable of having apps share Ruby processes > between themselves (which doesn''t surprise me at all). > > Some responses in this thread suggest that is the case: > http://www.litespeedtech.com/support/forum/archive/index.php/ > t-581.html > > On 12/30/06, Joe Noon <joenoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> > But, right now, they *are* mutually exclusive: There''s no way to >> use >> > Rails (and therefore gain it''s benefits) without incurring this >> cost. >> >> Tomas Jogin - What you need is LiteSpeed as suggested by Peter >> originally. It spawns and manages application processes. If a >> process is idle for X seconds, the process dies (you set X >> obviously). >> You can even choose to not spawn rails processes on a server restart >> in which case they would be spawned when the application get hit for >> the first time. If you get very little traffic, you will probably >> see >> very few processes running at any given time, even if your hosting 30 >> rails apps. >> >> Joe >> >> > >> > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> On 30 dec 2006, at 08.52, Tomas Jogin wrote: > > > > > Joe: I''ll have to look into LiteSpeed, but based on what I''ve read, > > neither LiteSpeed is capable of having apps share Ruby processes > > between themselves (which doesn''t surprise me at all).You I cant think of a good reason why you would want/need that (not that there isn''t one maybe). But I don''t think the problem your seeking to solve now is answered by sharing ruby processes. On 12/30/06, Peter Bengtson <peter-7KpGIyJoDGqUry1sbql4ngC/G2K4zDHf@public.gmane.org> wrote:> > Tomas, there is no *point* in sharing Ruby processes, when they are > spawned and killed according to need. >Exactly. Tomas, think in terms of total memory. Traditionally if you have 30 apps, 1 process each at 20 mb ram, your using 600 mb of ram on your server. Now say you figured out that on average only 1 of your apps is "in use". If you were running litespeed that would mean on average you would see 20 mb ram dedicated to rails apps. You should still make sure your server *can* run everything at the same time... otherwise you would be dependent on under-use which just isn''t good design in any server environment. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I suppose I might have jumped to conclusions regarding the nature of the problem. The facts are that the server is running perhaps 30 Ruby processes, and the server is equipped with 1.5 GB of RAM. I''m not able to check more details right now, but I''ll definitely have to make a proper check later. Regards, Tomas Jogin On 12/30/06, Joe Noon <joenoon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On 30 dec 2006, at 08.52, Tomas Jogin wrote: > > > > > > > > Joe: I''ll have to look into LiteSpeed, but based on what I''ve read, > > > neither LiteSpeed is capable of having apps share Ruby processes > > > between themselves (which doesn''t surprise me at all). > > You I cant think of a good reason why you would want/need that (not > that there isn''t one maybe). But I don''t think the problem your > seeking to solve now is answered by sharing ruby processes. > > On 12/30/06, Peter Bengtson <peter-7KpGIyJoDGqUry1sbql4ngC/G2K4zDHf@public.gmane.org> wrote: > > > > Tomas, there is no *point* in sharing Ruby processes, when they are > > spawned and killed according to need. > > > > Exactly. Tomas, think in terms of total memory. Traditionally if you > have 30 apps, 1 process each at 20 mb ram, your using 600 mb of ram on > your server. Now say you figured out that on average only 1 of your > apps is "in use". If you were running litespeed that would mean on > average you would see 20 mb ram dedicated to rails apps. > > You should still make sure your server *can* run everything at the > same time... otherwise you would be dependent on under-use which just > isn''t good design in any server environment. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Joe Noon wrote:> Exactly. Tomas, think in terms of total memory. Traditionally if you > have 30 apps, 1 process each at 20 mb ram, your using 600 mb of ram on > your server. Now say you figured out that on average only 1 of your > apps is "in use". If you were running litespeed that would mean on > average you would see 20 mb ram dedicated to rails apps.Peter Bengtson wrote:> Tomas, there is no *point* in sharing Ruby processes, when they are > spawned and killed according to need.Spawning a Rails process is about as expensive as handling 20 requests. Let''s say you have 60 apps, each gets hit twice per minute with uniform distribution, so the server has to handle about 2 request per second. No big deal. But if you do on-demand-spawning, it has to handle the load equivalent of 42 requests per second. Of course, this is a worst-case scenario, but you get the point. On-demand-spawning is no silver bullet. In many cases it is better to just load everything and leave it to the OS to swap unneeded applications to the disk if memory gets low. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Well, if processes were spawned every time they are needed and then killed again after use, each time, you would have something very inefficient. But that''s not the way it works. Your example is about as extreme as is possible. Apache as a webserver manages do spawn threads pretty efficiently and can sustain high hitrates. If processes are left idle for a long time, they are killed, otherwise they are left to live to serve future requests. If all processes are busy and another request comes in, another process may be spawned, depending on configuration, to handle that request, and that process is subject to the same life- span restriction as the others. That''s very common knowledge. And yes, there is a overhead involved in firing up another process. You don''t want to do it too often. But that''s elementary resource management. LiteSpeed does exactly the same thing but with Rails processes. However it also uses a FCGI implementation of its own to drastically reduce the startup overhead. The result is that you can let it handle the resulting resource allocation dynamically - without being overly bothered by process startup. As for silver bullets, I''ve never seen one within the field of computer science, so that''s not what we''re talking about here. / Peter On 1 jan 2007, at 15.46, Andreas Schwarz wrote:> > Joe Noon wrote: >> Exactly. Tomas, think in terms of total memory. Traditionally if >> you >> have 30 apps, 1 process each at 20 mb ram, your using 600 mb of >> ram on >> your server. Now say you figured out that on average only 1 of your >> apps is "in use". If you were running litespeed that would mean on >> average you would see 20 mb ram dedicated to rails apps. > > Peter Bengtson wrote: >> Tomas, there is no *point* in sharing Ruby processes, when they are >> spawned and killed according to need. > > Spawning a Rails process is about as expensive as handling 20 > requests. Let''s say you have 60 apps, each gets hit twice per > minute with uniform distribution, so the server has to handle about > 2 request per second. No big deal. But if you do on-demand- > spawning, it has to handle the load equivalent of 42 requests per > second. > > Of course, this is a worst-case scenario, but you get the point. On- > demand-spawning is no silver bullet. In many cases it is better to > just load everything and leave it to the OS to swap unneeded > applications to the disk if memory gets low. > > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Peter Bengtson wrote:> Well, if processes were spawned every time they are needed and then > killed again after use, each time, you would have something very > inefficient.> As for silver bullets, I''ve never seen one within the field of > computer science, so that''s not what we''re talking about here.>>> Tomas, there is no *point* in sharing Ruby processes, when they are >>> spawned and killed according to need.I just wanted to show you that there IS a point in sharing ruby processes between apps. When you have a high number of small apps that get hit with roughly equal probability, you gain almost nothing with dynamic process spawning. That''s a common scenario for 99ct mass web hosters. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
We''re running Apache 1.3.something plus FastCGI, is this setup especially bad at handling Ruby processes? Is LiteSpeed recommended for serving static content too or just dynamic stuff via proxy? On 1/1/07, Andreas Schwarz <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Peter Bengtson wrote: > > Well, if processes were spawned every time they are needed and then > > killed again after use, each time, you would have something very > > inefficient. > > > As for silver bullets, I''ve never seen one within the field of > > computer science, so that''s not what we''re talking about here. > > >>> Tomas, there is no *point* in sharing Ruby processes, when they are > >>> spawned and killed according to need. > > I just wanted to show you that there IS a point in sharing ruby > processes between apps. When you have a high number of small apps that > get hit with roughly equal probability, you gain almost nothing with > dynamic process spawning. That''s a common scenario for 99ct mass web > hosters. > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
No, and you don''t want to. That is why processes were invented in the first place. They provide separation. Unix has a good set of tools to manage and monitor processes - which would have to be duplicated inside any application server. Why bother complicating matters with another layer of software that may go wrong?. Memory is cheap and swap space is very cheap. Unix is a superb multi-user operating system - providing wonderful memory separation, process management and reasonable security controls. Why do you want to use it like it was an early version of MS-DOS? For ease of management though, I would suggest using Mongrel rather than FCGI. It''s just a lot easier when everything is talking HTTP. Tomas Jogin wrote:> My question is if this can be avoided. Is it possible to run many apps > that reuse the same Ruby processes and thus result in less pressure on > the server? What are my options? > > Best regards, > Tomas Jogin, Sweden--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Neil Wilson wrote:> For ease of management though, I would suggest using Mongrel rather > than FCGI. It''s just a lot easier when everything is talking HTTP.If memory IS an issue then that''s not a good idea, Mongrel uses almost twice as much as FCGI/LSAPI. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---