Lets start with the last thing u said. Litespeed has basically the same kind of stability of apache. Do you really need monit to monitor apache? Maybe if you're seriously having some kind of major app that will break the underlying web server, then yes, but for 99% of us, no.
I think what you're forgetting I can also set litespeed to adjust based on memory AND process limits per user. I can set 2 min and 10 max and forget about it. Litespeed adds more if necessary, then based on capacity, gracefully ramps down if I dont need them, thus leaving the system for other things. A great example is if I'm running CRON's in the middle of the night, this is when my traffic is low. Why would I want 10 instances running? I can use the resources used from not having 8 useless instances running doing nothing. My point in all of this is not to knock the great open source software out there which I have used and will continue to do so, but just to point out that Litespeed is an extremely credible contender for Rails. It really makes it super simple to get going with top-notch performance as a great side bonus. For guys like me who want to spend time coding and dealing with the strategic issues on my site (our core competence), Litespeed is a godsend. - Ericson Smith CTO http://www.funadvice.com On Jan 5, 2008 3:38 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Jan 5, 6:02am, "Ericson Smith" <[EMAIL PROTECTED]> wrote: > > > Of course unlimited scaling will destabilize your environment. That's > why > > you do some basic investigations and set your min and max values for > spawned > > lsapi children. Its the same issue if the startup 20 mongrels on a dual > core > > machine. > > No, it's decidedly not the same. If you startup 20 mongrels on a dual > core machine, then the performance will be the same whether those 20 > are in use or not. It's not an issue of CPU, to a large extent, but of > memory... > > > The point is if I know that my theorerical maximums are 10 mongrels > > (lsapi clients). Then once I set that, I no longer have to worry about > it. > > But why wouldn't you want all 10 running if 10 is the maximum? > > > Litespeed will put them up or tear them down -- up to the maximums I > set, or > > down to the minimums -- based on traffic, memory and load. > > Why would you pay the penalty of processes startup and teardown? > > > So destabilizing your environment is not an issue. > > Sure it is. What happens if you have high traffic during a cron job? > You'll have max mongrels running, using all available RAM with enough > left over to allow the machine to run efficiently. The cron job starts > and *bam* you're in swap. > > Now, I know what you're going to say: You've set the maximum too high. > Yes, I agree with that technically, but in practice, a LOT of people > forget about daily, weekly, and monthly cron jobs, etc. > > Also, people tend to log into production machine and run code for > various purposes, sometimes as part of routine. With fluctuating > number of mongrel processes, this can work for a long time, then > suddenly take the machine into swap for no apparent reason. > > Technically, you're 100% right, all of this can be avoided with your > method. Operationally, I'm quite convinced it's not a good idea. :-) > > > After all Apache does the same thing governed my max child clients. > > Yes, and in my experience large websites don't use this feature for > the reasons I've mentioned above. :-) > > > And the gravy on the steak? You don't need monit for all of that. > > > But you do need monit to monitor lightspeed itself, so you've gained > nothing. :-) > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
