Apologies in advance if this ignites a war of comflicting opinions.... I''m a few days away from going live with my first RoR application. It is completely database centric and each user will have his own queries so cacheing will not really help. I have a dedicated linux server being built by my hosting provider and I need to tell them which webserver to use. The databse is MySQL btw. Should it be Apache with FastCGI or lighttpd? I''ve not idea yet on the number of users but if this took off then maybe 5000? Maybe I''ll need 10 boxes!!! I suppose the best I could liken it to is Hotmail. So the question how much gear will I need to support 5000 concurrent users? Of course it could take 100 years to get to 5000 users in which case I''ll need to think of something else for my pension! -- Posted via http://www.ruby-forum.com/.
for lots of concurrent users i''d recommend Apache since lighttpd has 0 support for concurrent users being a single process single threaded application. Lighttpd is very good at what it does though, and is very fast for what it is, however apache is tried and true for this kind of large scale deployment. On 7/24/06, jh100000 <john.henderson@mac.com> wrote:> Apologies in advance if this ignites a war of comflicting opinions.... > > I''m a few days away from going live with my first RoR application. It > is completely database centric and each user will have his own queries > so cacheing will not really help. > > I have a dedicated linux server being built by my hosting provider and I > need to tell them which webserver to use. The databse is MySQL btw. > > Should it be Apache with FastCGI or lighttpd? > > I''ve not idea yet on the number of users but if this took off then maybe > 5000? Maybe I''ll need 10 boxes!!! > > I suppose the best I could liken it to is Hotmail. So the question how > much gear will I need to support 5000 concurrent users? > > Of course it could take 100 years to get to 5000 users in which case > I''ll need to think of something else for my pension! > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Ryan McGovern UCIT Public Computer Labs Lab assistant / "web guy" 412a Teachers College 513-556-2418
On 07/24/06 07:11, ryan mcgovern wrote:> for lots of concurrent users i''d recommend Apache since lighttpd has 0 > support for concurrent users being a single process single threaded > application. Lighttpd is very good at what it does though, and is > very fast for what it is, however apache is tried and true for this > kind of large scale deployment. > > On 7/24/06, jh100000 <john.henderson@mac.com> wrote: >> Apologies in advance if this ignites a war of comflicting opinions.... >> >> I''m a few days away from going live with my first RoR application. It >> is completely database centric and each user will have his own queries >> so cacheing will not really help. >> >> I have a dedicated linux server being built by my hosting provider and I >> need to tell them which webserver to use. The databse is MySQL btw. >> >> Should it be Apache with FastCGI or lighttpd? >> >> I''ve not idea yet on the number of users but if this took off then maybe >> 5000? Maybe I''ll need 10 boxes!!! >> >> I suppose the best I could liken it to is Hotmail. So the question how >> much gear will I need to support 5000 concurrent users? >> >> Of course it could take 100 years to get to 5000 users in which case >> I''ll need to think of something else for my pension!Ryan, I''m not sure how you''re making those determinations about Lighttpd being unsuitable for concurrent users... select-based servers like lighty or thttpd are documented (google some benchmarks) as being quite capable of serving multiple users at once. -Marshall
jh100000 wrote:> Should it be Apache with FastCGI or lighttpd?How about neither? Or if you really want Apache toss Mongrel behind it. FastCGI is not a good solution and is not really stable. The FastCGI project for Apache last I recall has been dead for some time now. FastCGI for Lighttpd has issues right now unless they''ve been addressed. Other options: 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly easy) 2. Pound + Mongrel (Simple) -- Posted via http://www.ruby-forum.com/.
I use Pound with mongrel_cluster behind Apache with mod_proxy, because I''m running Apache 2.0 and using it for vhosting some other apps. If you can get ''em to install Apache 2.2 you can use Apache + mod_proxy_balancer and mongrel_cluster. Mongrel is super-simple to set up and use, seems quite stable, and mongrel_cluster makes it very easy to manage. I used Lighty on a web app that saw pretty intense usage earlier this year, and I had some problems with zombie FastCGI processes, and reviving it usually required a reboot. This only happened a couple times, though, so my overall experience with Lighty was very good. It''s also easy to set up and use. My biggest concern with Lighty is that it seems that development has stalled... They haven''t released an update in some time. Matt On 7/24/06, Mark Hall <markh@networld.com> wrote:> > jh100000 wrote: > > > Should it be Apache with FastCGI or lighttpd? > > How about neither? Or if you really want Apache toss Mongrel behind it. > FastCGI is not a good solution and is not really stable. The FastCGI > project for Apache last I recall has been dead for some time now. > FastCGI for Lighttpd has issues right now unless they''ve been addressed. > > Other options: > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly > easy) > 2. Pound + Mongrel (Simple) > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/a523d2ef/attachment.html
Are you sure you mean concurrent users? That means handling 5000 simultaneous requests. I doubt there are more then a couple of dozen sites on the whole internet that come close to that. Remember, 5000 logged in users on your site does not translate to 5000 concurrent users. Depending on your traffic patterns it probably translates to less than 100 or so.
There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) Not only because we are the developers of LiteSpeed Web Server, but also LiteSpeed + LSAPI has solve some problems that other setup cannot. There is my take based on information collected, please correct me if I were wrong. Not to criticize others, just want to help people making decisions. Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI persistent connections, lighttpd FCGI has reliability issue. Cannot do dynamic spawning due to high cost at Rails framework initialization time, system resource could be wasted under some situation like Rails hosting services. Mongrel is very easy to use, and Rails performance is pretty good as well. Its weakness is on serving static files, usually need to be use with other web servers in production environment that receiving high traffic. Need to run multiple instances with mongrel_cluster to take advantage a SMP server and serving multiple clients at the same time, the setup has been complicated a little bit. Same as FCGI, you cannot do dynamic spawning with mongrel either. Since Pound cannot serve static content, Pound + mongrel_cluster is not a optimum solution unless most of traffic is dynamically generated, adding an extra layer of web server helps, but it will complicate things even more and introduce higher latency and server load. Lighttpd + mongrel_cluster is not recommended by Zed, the developer of mongrel, due to bug in lighttpd proxy, at this moment. LiteSpeed + mongrel_cluster probably is the best solution for user who prefers Mongrel right now. Jason from textdrive.com has written that Apache 2.2 + mongrel_cluster has the best performance in his blog, We cannot confirm that because we haven''t played with Apache 2.2 yet, however, textdrive.com and strongspace.com are all powered by LiteSpeed currently. ;-) LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned above after analysis their Pros and Cons. Here is a Rails benchmark by third party. It is in Japanese, but the graph is an universal language. http://wota.jp/ac/?date=20060608 Tutorial on LiteSpeed + Ruby is in our Wiki http://www.litespeedtech.com/community/wiki/doku.php Best Regards, George Wang Matt White wrote:> I use Pound with mongrel_cluster behind Apache with mod_proxy, because > I''m running Apache 2.0 and using it for vhosting some other apps. If > you can get ''em to install Apache 2.2 you can use Apache + > mod_proxy_balancer and mongrel_cluster. > > Mongrel is super-simple to set up and use, seems quite stable, and > mongrel_cluster makes it very easy to manage. I used Lighty on a web > app that saw pretty intense usage earlier this year, and I had some > problems with zombie FastCGI processes, and reviving it usually > required a reboot. This only happened a couple times, though, so my > overall experience with Lighty was very good. It''s also easy to set up > and use. My biggest concern with Lighty is that it seems that > development has stalled... They haven''t released an update in some time. > > Matt > > On 7/24/06, *Mark Hall* <markh@networld.com > <mailto:markh@networld.com>> wrote: > > jh100000 wrote: > > > Should it be Apache with FastCGI or lighttpd? > > How about neither? Or if you really want Apache toss Mongrel > behind it. > FastCGI is not a good solution and is not really stable. The FastCGI > project for Apache last I recall has been dead for some time now. > FastCGI for Lighttpd has issues right now unless they''ve been > addressed. > > Other options: > 1. http://www.litespeedtech.com <http://www.litespeedtech.com> > Litespeed + LSAPI (Fast and fairly > easy) > 2. Pound + Mongrel (Simple) > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/73081aea/attachment.html
I''ve never tried LiteSpeed before, so this is a totally naive question... How would you scale LiteSpeed across multiple machines? At some point you''re going to hit a wall where one machine can''t handle the load, no matter how powerful it is... In my experience, the FastCGI or Mongrel solution of having a server like Lighty or Apache balance across multiple app instances on multiple machines seemed attractive and easy to scale. Deployment is easy, too. If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed servers and balance across them with another LiteSpeed server acting as a static load balancer? Or use Pound or some other specialized load balancer to balance across the LiteSpeed servers? Also, is there any documention on deploying into LiteSpeed with Capistrano? I know there''s a lot of hooks in mongrel_cluster for Capistrano, but I''m unaware of how it would work with LiteSpeed... Thanks, Matt On 7/24/06, George Wang <gwang@litespeedtech.com> wrote:> > There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) > Not only because we are the developers of LiteSpeed Web Server, but also > LiteSpeed + LSAPI has solve some problems that other setup cannot. > > There is my take based on information collected, please correct me if I > were wrong. Not to criticize others, just want to help people making > decisions. > > Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI > persistent connections, lighttpd FCGI has reliability issue. Cannot do > dynamic spawning due to high cost at Rails framework initialization time, > system resource could be wasted under some situation like Rails hosting > services. > > Mongrel is very easy to use, and Rails performance is pretty good as well. > Its weakness is on serving static files, usually need to be use with other > web servers in production environment that receiving high traffic. Need to > run multiple instances with mongrel_cluster to take advantage a SMP server > and serving multiple clients at the same time, the setup has been > complicated a little bit. Same as FCGI, you cannot do dynamic spawning with > mongrel either. > > Since Pound cannot serve static content, Pound + mongrel_cluster is not a > optimum solution unless most of traffic is dynamically generated, adding an > extra layer of web server helps, but it will complicate things even more and > introduce higher latency and server load. Lighttpd + mongrel_cluster is not > recommended by Zed, the developer of mongrel, due to bug in lighttpd proxy, > at this moment. > > LiteSpeed + mongrel_cluster probably is the best solution for user who > prefers Mongrel right now. Jason from textdrive.com has written that > Apache 2.2 + mongrel_cluster has the best performance in his blog, We > cannot confirm that because we haven''t played with Apache 2.2 yet, > however, textdrive.com and strongspace.com are all powered by LiteSpeed > currently. ;-) > > LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned above > after analysis their Pros and Cons. > > Here is a Rails benchmark by third party. It is in Japanese, but the graph > is an universal language. > http://wota.jp/ac/?date=20060608 > > Tutorial on LiteSpeed + Ruby is in our Wiki > http://www.litespeedtech.com/community/wiki/doku.php > > Best Regards, > George Wang > > Matt White wrote: > > I use Pound with mongrel_cluster behind Apache with mod_proxy, because I''m > running Apache 2.0 and using it for vhosting some other apps. If you can > get ''em to install Apache 2.2 you can use Apache + mod_proxy_balancer and > mongrel_cluster. > > Mongrel is super-simple to set up and use, seems quite stable, and > mongrel_cluster makes it very easy to manage. I used Lighty on a web app > that saw pretty intense usage earlier this year, and I had some problems > with zombie FastCGI processes, and reviving it usually required a reboot. > This only happened a couple times, though, so my overall experience with > Lighty was very good. It''s also easy to set up and use. My biggest concern > with Lighty is that it seems that development has stalled... They haven''t > released an update in some time. > > Matt > > On 7/24/06, Mark Hall <markh@networld.com> wrote: > > > > jh100000 wrote: > > > > > Should it be Apache with FastCGI or lighttpd? > > > > How about neither? Or if you really want Apache toss Mongrel behind it. > > FastCGI is not a good solution and is not really stable. The FastCGI > > project for Apache last I recall has been dead for some time now. > > FastCGI for Lighttpd has issues right now unless they''ve been addressed. > > > > Other options: > > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly > > easy) > > 2. Pound + Mongrel (Simple) > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > ------------------------------ > > _______________________________________________ > Rails mailing list > > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/bf3ed486/attachment.html
Matt White wrote:> I''ve never tried LiteSpeed before, so this is a totally naive > question... > How would you scale LiteSpeed across multiple machines? At some point > you''re > going to hit a wall where one machine can''t handle the load, no matterThere is a litespeed enterprise version that I assume handles this. -- Posted via http://www.ruby-forum.com/.
There is no big differences between LiteSpeed and other solutions for scaling across multiple servers. Like you said, you can use LiteSpeed web server as a load balancer in front of a LiteSpeed cluster just like what you will do with lighttpd or Apache. LiteSpeed has better performance as we knew. Enterprise Edition is recommended for the load balancer role. We are going to release a dedicate load balancer which can do stateful load balancing if the internal stateless load balancer does not meet your needs. Since Pond is multi-threaded, its scalability is not as good. Deploying Rails applications into LiteSpeed with Capistrano should be easier than that with mongrel_cluster, I think, since you don''t need to patch deploy.rb at all. With LiteSpeed + LSAPI, there is no need to start mongrel manually, everything has been taken care of by web server. Just read a tutorial on "Rails + Mongrel + Apache + Capistrano", I have to say, that are a heck lot of configurations, and it is only a single server setup. Similar setup can be done much more easily with LiteSpeed + LSAPI + Capistrano, and performance should be better. Unless rails are deployed on multiple servers, you don''t need to bother load balancing at all. :-) If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :-) Best Regards, George Wang Matt White wrote:> I''ve never tried LiteSpeed before, so this is a totally naive > question... How would you scale LiteSpeed across multiple machines? At > some point you''re going to hit a wall where one machine can''t handle > the load, no matter how powerful it is... In my experience, the > FastCGI or Mongrel solution of having a server like Lighty or Apache > balance across multiple app instances on multiple machines seemed > attractive and easy to scale. Deployment is easy, too. > > If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed > servers and balance across them with another LiteSpeed server acting > as a static load balancer? Or use Pound or some other specialized load > balancer to balance across the LiteSpeed servers? > > Also, is there any documention on deploying into LiteSpeed with > Capistrano? I know there''s a lot of hooks in mongrel_cluster for > Capistrano, but I''m unaware of how it would work with LiteSpeed... > > Thanks, > > Matt > > On 7/24/06, *George Wang* <gwang@litespeedtech.com > <mailto:gwang@litespeedtech.com>> wrote: > > There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) > Not only because we are the developers of LiteSpeed Web Server, > but also LiteSpeed + LSAPI has solve some problems that other > setup cannot. > > There is my take based on information collected, please correct me > if I were wrong. Not to criticize others, just want to help people > making decisions. > > Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI > persistent connections, lighttpd FCGI has reliability issue. > Cannot do dynamic spawning due to high cost at Rails framework > initialization time, system resource could be wasted under some > situation like Rails hosting services. > > Mongrel is very easy to use, and Rails performance is pretty good > as well. Its weakness is on serving static files, usually need to > be use with other web servers in production environment that > receiving high traffic. Need to run multiple instances with > mongrel_cluster to take advantage a SMP server and serving > multiple clients at the same time, the setup has been complicated > a little bit. Same as FCGI, you cannot do dynamic spawning with > mongrel either. > > Since Pound cannot serve static content, Pound + mongrel_cluster > is not a optimum solution unless most of traffic is dynamically > generated, adding an extra layer of web server helps, but it will > complicate things even more and introduce higher latency and > server load. Lighttpd + mongrel_cluster is not recommended by Zed, > the developer of mongrel, due to bug in lighttpd proxy, at this > moment. > > LiteSpeed + mongrel_cluster probably is the best solution for user > who prefers Mongrel right now. Jason from textdrive.com > <http://textdrive.com> has written that Apache 2.2 + > mongrel_cluster has the best performance in his blog, We cannot > confirm that because we haven''t played with Apache 2.2 yet, > however, textdrive.com <http://textdrive.com> and strongspace.com > <http://strongspace.com> are all powered by LiteSpeed currently. ;-) > > LiteSpeed + Rails via LSAPI is designed to overcome issues > mentioned above after analysis their Pros and Cons. > > Here is a Rails benchmark by third party. It is in Japanese, but > the graph is an universal language. > http://wota.jp/ac/?date=20060608 > > Tutorial on LiteSpeed + Ruby is in our Wiki > http://www.litespeedtech.com/community/wiki/doku.php > <http://www.litespeedtech.com/community/wiki/doku.php> > > Best Regards, > George Wang > > Matt White wrote: > I use Pound with mongrel_cluster behind Apache with mod_proxy, > because I''m running Apache 2.0 and using it for vhosting some > other apps. If you can get ''em to install Apache 2.2 you can use > Apache + mod_proxy_balancer and mongrel_cluster. > > Mongrel is super-simple to set up and use, seems quite stable, and > mongrel_cluster makes it very easy to manage. I used Lighty on a > web app that saw pretty intense usage earlier this year, and I had > some problems with zombie FastCGI processes, and reviving it > usually required a reboot. This only happened a couple times, > though, so my overall experience with Lighty was very good. It''s > also easy to set up and use. My biggest concern with Lighty is > that it seems that development has stalled... They haven''t > released an update in some time. > > Matt > > On 7/24/06, *Mark Hall* < markh@networld.com > <mailto:markh@networld.com>> wrote: > > jh100000 wrote: > > > Should it be Apache with FastCGI or lighttpd? > > How about neither? Or if you really want Apache toss Mongrel > behind it. > FastCGI is not a good solution and is not really stable. The > FastCGI > project for Apache last I recall has been dead for some time now. > FastCGI for Lighttpd has issues right now unless they''ve been > addressed. > > Other options: > 1. http://www.litespeedtech.com > <http://www.litespeedtech.com> Litespeed + LSAPI (Fast and > fairly > easy) > 2. Pound + Mongrel (Simple) > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > > > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060725/77d181ff/attachment.html
On 7/25/06, George Wang <gwang@litespeedtech.com> wrote:> > Since Pond is multi-threaded, its scalability is not as good.Does it mean that multi-threading is in general slower? How does litespeed handle this problem?> > > If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :-) >Interesting. What is the difference between LSAPI and FastCGI?> > Best Regards, > George Wang > >-- Kent --- http://www.datanoise.com
When you deploy a new version of an app with Capistrano, the /current symlink is updated to point to the new version of the app... Usually Capistrano calls reaper to kill any running FastCGI processes, and spawner to start up a the new version that''s pointed to by /current. Does LiteSpeed + LSAPI circumvent this and automatically detect the switch between the two versions of the app, and then start immediately handling requests with the new version? If so, that would rock... I''m getting ready to look into deployment with a poetentially high-traffic app, and this would be a really cool solution. Thanks! Matt On 7/25/06, George Wang <gwang@litespeedtech.com> wrote:> > There is no big differences between LiteSpeed and other solutions for > scaling across multiple servers. Like you said, you can use LiteSpeed web > server as a load balancer in front of a LiteSpeed cluster just like what you > will do with lighttpd or Apache. LiteSpeed has better performance as we > knew. Enterprise Edition is recommended for the load balancer role. We are > going to release a dedicate load balancer which can do stateful load > balancing if the internal stateless load balancer does not meet your needs. > > Since Pond is multi-threaded, its scalability is not as good. > > Deploying Rails applications into LiteSpeed with Capistrano should be > easier than that with mongrel_cluster, I think, since you don''t need to > patch deploy.rb at all. With LiteSpeed + LSAPI, there is no need to start > mongrel manually, everything has been taken care of by web server. > > Just read a tutorial on "Rails + Mongrel + Apache + Capistrano", I have to > say, that are a heck lot of configurations, and it is only a single server > setup. Similar setup can be done much more easily with LiteSpeed + LSAPI + > Capistrano, and performance should be better. Unless rails are deployed on > multiple servers, you don''t need to bother load balancing at all. :-) > > If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :-) > > > Best Regards, > George Wang > > Matt White wrote: > > I''ve never tried LiteSpeed before, so this is a totally naive question... > How would you scale LiteSpeed across multiple machines? At some point you''re > going to hit a wall where one machine can''t handle the load, no matter how > powerful it is... In my experience, the FastCGI or Mongrel solution of > having a server like Lighty or Apache balance across multiple app instances > on multiple machines seemed attractive and easy to scale. Deployment is > easy, too. > > If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed > servers and balance across them with another LiteSpeed server acting as a > static load balancer? Or use Pound or some other specialized load balancer > to balance across the LiteSpeed servers? > > Also, is there any documention on deploying into LiteSpeed with > Capistrano? I know there''s a lot of hooks in mongrel_cluster for Capistrano, > but I''m unaware of how it would work with LiteSpeed... > > Thanks, > > Matt > > On 7/24/06, George Wang <gwang@litespeedtech.com> wrote: > > > > There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) > > Not only because we are the developers of LiteSpeed Web Server, but also > > LiteSpeed + LSAPI has solve some problems that other setup cannot. > > > > There is my take based on information collected, please correct me if I > > were wrong. Not to criticize others, just want to help people making > > decisions. > > > > Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI > > persistent connections, lighttpd FCGI has reliability issue. Cannot do > > dynamic spawning due to high cost at Rails framework initialization time, > > system resource could be wasted under some situation like Rails hosting > > services. > > > > Mongrel is very easy to use, and Rails performance is pretty good as > > well. Its weakness is on serving static files, usually need to be use with > > other web servers in production environment that receiving high traffic. > > Need to run multiple instances with mongrel_cluster to take advantage a SMP > > server and serving multiple clients at the same time, the setup has been > > complicated a little bit. Same as FCGI, you cannot do dynamic spawning with > > mongrel either. > > > > Since Pound cannot serve static content, Pound + mongrel_cluster is not > > a optimum solution unless most of traffic is dynamically generated, adding > > an extra layer of web server helps, but it will complicate things even more > > and introduce higher latency and server load. Lighttpd + mongrel_cluster is > > not recommended by Zed, the developer of mongrel, due to bug in lighttpd > > proxy, at this moment. > > > > LiteSpeed + mongrel_cluster probably is the best solution for user who > > prefers Mongrel right now. Jason from textdrive.com has written that > > Apache 2.2 + mongrel_cluster has the best performance in his blog, We > > cannot confirm that because we haven''t played with Apache 2.2 yet, > > however, textdrive.com and strongspace.com are all powered by LiteSpeed > > currently. ;-) > > > > LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned > > above after analysis their Pros and Cons. > > > > Here is a Rails benchmark by third party. It is in Japanese, but the > > graph is an universal language. > > http://wota.jp/ac/?date=20060608 > > > > Tutorial on LiteSpeed + Ruby is in our Wiki > > http://www.litespeedtech.com/community/wiki/doku.php > > > > Best Regards, > > George Wang > > > > Matt White wrote: > > I use Pound with mongrel_cluster behind Apache with mod_proxy, because > > I''m running Apache 2.0 and using it for vhosting some other apps. If you > > can get ''em to install Apache 2.2 you can use Apache + > > mod_proxy_balancer and mongrel_cluster. > > > > Mongrel is super-simple to set up and use, seems quite stable, and > > mongrel_cluster makes it very easy to manage. I used Lighty on a web app > > that saw pretty intense usage earlier this year, and I had some problems > > with zombie FastCGI processes, and reviving it usually required a reboot. > > This only happened a couple times, though, so my overall experience with > > Lighty was very good. It''s also easy to set up and use. My biggest concern > > with Lighty is that it seems that development has stalled... They haven''t > > released an update in some time. > > > > Matt > > > > On 7/24/06, Mark Hall < markh@networld.com> wrote: > > > > > > jh100000 wrote: > > > > > > > Should it be Apache with FastCGI or lighttpd? > > > > > > How about neither? Or if you really want Apache toss Mongrel behind > > > it. > > > FastCGI is not a good solution and is not really stable. The FastCGI > > > project for Apache last I recall has been dead for some time now. > > > FastCGI for Lighttpd has issues right now unless they''ve been > > > addressed. > > > > > > Other options: > > > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly > > > easy) > > > 2. Pound + Mongrel (Simple) > > > > > > -- > > > Posted via http://www.ruby-forum.com/. > > > _______________________________________________ > > > Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > ------------------------------ > > > > _______________________________________________ > > Rails mailing list > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > ------------------------------ > > _______________________________________________ > Rails mailing list > > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060725/b735d298/attachment-0001.html
I am also curious about this. I''m writing a rails app for a high traffic site and it can''t afford to be unreachable for more about 1 second. ed On 7/25/06, Matt White <stockliasteroid@gmail.com> wrote:> > When you deploy a new version of an app with Capistrano, the /current > symlink is updated to point to the new version of the app... Usually > Capistrano calls reaper to kill any running FastCGI processes, and spawner > to start up a the new version that''s pointed to by /current. Does LiteSpeed > + LSAPI circumvent this and automatically detect the switch between the two > versions of the app, and then start immediately handling requests with the > new version? > > If so, that would rock... I''m getting ready to look into deployment with a > poetentially high-traffic app, and this would be a really cool solution. > > Thanks! > > Matt > > On 7/25/06, George Wang <gwang@litespeedtech.com> wrote: > > > > There is no big differences between LiteSpeed and other solutions for > > scaling across multiple servers. Like you said, you can use LiteSpeed web > > server as a load balancer in front of a LiteSpeed cluster just like what you > > will do with lighttpd or Apache. LiteSpeed has better performance as we > > knew. Enterprise Edition is recommended for the load balancer role. We are > > going to release a dedicate load balancer which can do stateful load > > balancing if the internal stateless load balancer does not meet your needs. > > > > Since Pond is multi-threaded, its scalability is not as good. > > > > Deploying Rails applications into LiteSpeed with Capistrano should be > > easier than that with mongrel_cluster, I think, since you don''t need to > > patch deploy.rb at all. With LiteSpeed + LSAPI, there is no need to > > start mongrel manually, everything has been taken care of by web server. > > > > Just read a tutorial on "Rails + Mongrel + Apache + Capistrano", I have > > to say, that are a heck lot of configurations, and it is only a single > > server setup. Similar setup can be done much more easily with LiteSpeed + > > LSAPI + Capistrano, and performance should be better. Unless rails are > > deployed on multiple servers, you don''t need to bother load balancing at > > all. :-) > > > > If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :-) > > > > > > Best Regards, > > George Wang > > > > Matt White wrote: > > > > I''ve never tried LiteSpeed before, so this is a totally naive > > question... How would you scale LiteSpeed across multiple machines? At some > > point you''re going to hit a wall where one machine can''t handle the load, no > > matter how powerful it is... In my experience, the FastCGI or Mongrel > > solution of having a server like Lighty or Apache balance across multiple > > app instances on multiple machines seemed attractive and easy to scale. > > Deployment is easy, too. > > > > If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed > > servers and balance across them with another LiteSpeed server acting as a > > static load balancer? Or use Pound or some other specialized load balancer > > to balance across the LiteSpeed servers? > > > > Also, is there any documention on deploying into LiteSpeed with > > Capistrano? I know there''s a lot of hooks in mongrel_cluster for Capistrano, > > but I''m unaware of how it would work with LiteSpeed... > > > > Thanks, > > > > Matt > > > > On 7/24/06, George Wang < gwang@litespeedtech.com> wrote: > > > > > > There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) > > > Not only because we are the developers of LiteSpeed Web Server, but > > > also LiteSpeed + LSAPI has solve some problems that other setup cannot. > > > > > > There is my take based on information collected, please correct me if > > > I were wrong. Not to criticize others, just want to help people making > > > decisions. > > > > > > Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI > > > persistent connections, lighttpd FCGI has reliability issue. Cannot do > > > dynamic spawning due to high cost at Rails framework initialization time, > > > system resource could be wasted under some situation like Rails hosting > > > services. > > > > > > Mongrel is very easy to use, and Rails performance is pretty good as > > > well. Its weakness is on serving static files, usually need to be use with > > > other web servers in production environment that receiving high traffic. > > > Need to run multiple instances with mongrel_cluster to take advantage a SMP > > > server and serving multiple clients at the same time, the setup has been > > > complicated a little bit. Same as FCGI, you cannot do dynamic spawning with > > > mongrel either. > > > > > > Since Pound cannot serve static content, Pound + mongrel_cluster is > > > not a optimum solution unless most of traffic is dynamically generated, > > > adding an extra layer of web server helps, but it will complicate things > > > even more and introduce higher latency and server load. Lighttpd + > > > mongrel_cluster is not recommended by Zed, the developer of mongrel, due to > > > bug in lighttpd proxy, at this moment. > > > > > > LiteSpeed + mongrel_cluster probably is the best solution for user who > > > prefers Mongrel right now. Jason from textdrive.com has written that > > > Apache 2.2 + mongrel_cluster has the best performance in his blog, We > > > cannot confirm that because we haven''t played with Apache 2.2 yet, > > > however, textdrive.com and strongspace.com are all powered by > > > LiteSpeed currently. ;-) > > > > > > LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned > > > above after analysis their Pros and Cons. > > > > > > Here is a Rails benchmark by third party. It is in Japanese, but the > > > graph is an universal language. > > > http://wota.jp/ac/?date=20060608 > > > > > > Tutorial on LiteSpeed + Ruby is in our Wiki > > > http://www.litespeedtech.com/community/wiki/doku.php > > > > > > Best Regards, > > > George Wang > > > > > > Matt White wrote: > > > I use Pound with mongrel_cluster behind Apache with mod_proxy, because > > > I''m running Apache 2.0 and using it for vhosting some other apps. If > > > you can get ''em to install Apache 2.2 you can use Apache + > > > mod_proxy_balancer and mongrel_cluster. > > > > > > Mongrel is super-simple to set up and use, seems quite stable, and > > > mongrel_cluster makes it very easy to manage. I used Lighty on a web app > > > that saw pretty intense usage earlier this year, and I had some problems > > > with zombie FastCGI processes, and reviving it usually required a reboot. > > > This only happened a couple times, though, so my overall experience with > > > Lighty was very good. It''s also easy to set up and use. My biggest concern > > > with Lighty is that it seems that development has stalled... They haven''t > > > released an update in some time. > > > > > > Matt > > > > > > On 7/24/06, Mark Hall < markh@networld.com> wrote: > > > > > > > > jh100000 wrote: > > > > > > > > > Should it be Apache with FastCGI or lighttpd? > > > > > > > > How about neither? Or if you really want Apache toss Mongrel behind > > > > it. > > > > FastCGI is not a good solution and is not really stable. The > > > > FastCGI > > > > project for Apache last I recall has been dead for some time now. > > > > FastCGI for Lighttpd has issues right now unless they''ve been > > > > addressed. > > > > > > > > Other options: > > > > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and > > > > fairly > > > > easy) > > > > 2. Pound + Mongrel (Simple) > > > > > > > > -- > > > > Posted via http://www.ruby-forum.com/. > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails@lists.rubyonrails.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > Rails mailing list > > > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Rails mailing list > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060725/d5ab5a97/attachment.html
Ed, I''m actually pretty amazed with how transparent Capistrano deployments are, regardless of the web server. I had a shortlived data entry app running earlier this year that had a large number of people working round the clock on it, and I ran several deployments while they were working without a single problem. As long as your deployment itself works, it shouldn''t be much of an issue for downtime. Matt On 7/25/06, Ed Hickey <bassnode@gmail.com> wrote:> > I am also curious about this. I''m writing a rails app for a high traffic > site and it can''t afford to be unreachable for more about 1 second. > > ed > > On 7/25/06, Matt White <stockliasteroid@gmail.com> wrote: > > > When you deploy a new version of an app with Capistrano, the /current > symlink is updated to point to the new version of the app... Usually > Capistrano calls reaper to kill any running FastCGI processes, and spawner > to start up a the new version that''s pointed to by /current. Does LiteSpeed > + LSAPI circumvent this and automatically detect the switch between the two > versions of the app, and then start immediately handling requests with the > new version? > > If so, that would rock... I''m getting ready to look into deployment with a > poetentially high-traffic app, and this would be a really cool solution. > > Thanks! > > Matt > > On 7/25/06, George Wang <gwang@litespeedtech.com > wrote: > > > > There is no big differences between LiteSpeed and other solutions for > > scaling across multiple servers. Like you said, you can use LiteSpeed web > > server as a load balancer in front of a LiteSpeed cluster just like what you > > will do with lighttpd or Apache. LiteSpeed has better performance as we > > knew. Enterprise Edition is recommended for the load balancer role. We are > > going to release a dedicate load balancer which can do stateful load > > balancing if the internal stateless load balancer does not meet your needs. > > > > Since Pond is multi-threaded, its scalability is not as good. > > > > Deploying Rails applications into LiteSpeed with Capistrano should be > > easier than that with mongrel_cluster, I think, since you don''t need to > > patch deploy.rb at all. With LiteSpeed + LSAPI, there is no need to > > start mongrel manually, everything has been taken care of by web server. > > > > Just read a tutorial on "Rails + Mongrel + Apache + Capistrano", I have > > to say, that are a heck lot of configurations, and it is only a single > > server setup. Similar setup can be done much more easily with LiteSpeed + > > LSAPI + Capistrano, and performance should be better. Unless rails are > > deployed on multiple servers, you don''t need to bother load balancing at > > all. :-) > > > > If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :-) > > > > > > Best Regards, > > George Wang > > > > Matt White wrote: > > > > I''ve never tried LiteSpeed before, so this is a totally naive > > question... How would you scale LiteSpeed across multiple machines? At some > > point you''re going to hit a wall where one machine can''t handle the load, no > > matter how powerful it is... In my experience, the FastCGI or Mongrel > > solution of having a server like Lighty or Apache balance across multiple > > app instances on multiple machines seemed attractive and easy to scale. > > Deployment is easy, too. > > > > If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed > > servers and balance across them with another LiteSpeed server acting as a > > static load balancer? Or use Pound or some other specialized load balancer > > to balance across the LiteSpeed servers? > > > > Also, is there any documention on deploying into LiteSpeed with > > Capistrano? I know there''s a lot of hooks in mongrel_cluster for Capistrano, > > but I''m unaware of how it would work with LiteSpeed... > > > > Thanks, > > > > Matt > > > > On 7/24/06, George Wang < gwang@litespeedtech.com> wrote: > > > > > > There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) > > > Not only because we are the developers of LiteSpeed Web Server, but > > > also LiteSpeed + LSAPI has solve some problems that other setup cannot. > > > > > > There is my take based on information collected, please correct me if > > > I were wrong. Not to criticize others, just want to help people making > > > decisions. > > > > > > Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI > > > persistent connections, lighttpd FCGI has reliability issue. Cannot do > > > dynamic spawning due to high cost at Rails framework initialization time, > > > system resource could be wasted under some situation like Rails hosting > > > services. > > > > > > Mongrel is very easy to use, and Rails performance is pretty good as > > > well. Its weakness is on serving static files, usually need to be use with > > > other web servers in production environment that receiving high traffic. > > > Need to run multiple instances with mongrel_cluster to take advantage a SMP > > > server and serving multiple clients at the same time, the setup has been > > > complicated a little bit. Same as FCGI, you cannot do dynamic spawning with > > > mongrel either. > > > > > > Since Pound cannot serve static content, Pound + mongrel_cluster is > > > not a optimum solution unless most of traffic is dynamically generated, > > > adding an extra layer of web server helps, but it will complicate things > > > even more and introduce higher latency and server load. Lighttpd + > > > mongrel_cluster is not recommended by Zed, the developer of mongrel, due to > > > bug in lighttpd proxy, at this moment. > > > > > > LiteSpeed + mongrel_cluster probably is the best solution for user who > > > prefers Mongrel right now. Jason from textdrive.com has written that > > > Apache 2.2 + mongrel_cluster has the best performance in his blog, We > > > cannot confirm that because we haven''t played with Apache 2.2 yet, > > > however, textdrive.com and strongspace.com are all powered by > > > LiteSpeed currently. ;-) > > > > > > LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned > > > above after analysis their Pros and Cons. > > > > > > Here is a Rails benchmark by third party. It is in Japanese, but the > > > graph is an universal language. > > > http://wota.jp/ac/?date=20060608 > > > > > > Tutorial on LiteSpeed + Ruby is in our Wiki > > > http://www.litespeedtech.com/community/wiki/doku.php > > > > > > Best Regards, > > > George Wang > > > > > > Matt White wrote: > > > I use Pound with mongrel_cluster behind Apache with mod_proxy, because > > > I''m running Apache 2.0 and using it for vhosting some other apps. If > > > you can get ''em to install Apache 2.2 you can use Apache + > > > mod_proxy_balancer and mongrel_cluster. > > > > > > Mongrel is super-simple to set up and use, seems quite stable, and > > > mongrel_cluster makes it very easy to manage. I used Lighty on a web app > > > that saw pretty intense usage earlier this year, and I had some problems > > > with zombie FastCGI processes, and reviving it usually required a reboot. > > > This only happened a couple times, though, so my overall experience with > > > Lighty was very good. It''s also easy to set up and use. My biggest concern > > > with Lighty is that it seems that development has stalled... They haven''t > > > released an update in some time. > > > > > > Matt > > > > > > On 7/24/06, Mark Hall < markh@networld.com> wrote: > > > > > > > > jh100000 wrote: > > > > > > > > > Should it be Apache with FastCGI or lighttpd? > > > > > > > > How about neither? Or if you really want Apache toss Mongrel behind > > > > it. > > > > FastCGI is not a good solution and is not really stable. The > > > > FastCGI > > > > project for Apache last I recall has been dead for some time now. > > > > FastCGI for Lighttpd has issues right now unless they''ve been > > > > addressed. > > > > > > > > Other options: > > > > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and > > > > fairly > > > > easy) > > > > 2. Pound + Mongrel (Simple) > > > > > > > > -- > > > > Posted via http://www.ruby-forum.com/ . > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails@lists.rubyonrails.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > Rails mailing list > > > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Rails mailing list > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060725/15c20a89/attachment-0001.html
matt - thanks for the input. when mongrel restarts, does it do it gracefully and separately? for instance, if you have 3 mongrel processes for your app and you do a restart, does it kill one (one the client''s connection is dead), restart it with the new code and then continue to the next mongrel process? that way you''d never have a totally dead system. if it waits till all 3 processes are down before restarting, there could be some considerable downtime. On 7/25/06, Matt White <stockliasteroid@gmail.com> wrote:> > Ed, > > I''m actually pretty amazed with how transparent Capistrano deployments > are, regardless of the web server. I had a shortlived data entry app running > earlier this year that had a large number of people working round the clock > on it, and I ran several deployments while they were working without a > single problem. As long as your deployment itself works, it shouldn''t be > much of an issue for downtime. > > Matt > > On 7/25/06, Ed Hickey <bassnode@gmail.com> wrote: > > > I am also curious about this. I''m writing a rails app for a high > traffic site and it can''t afford to be unreachable for more about 1 second. > > ed > > On 7/25/06, Matt White <stockliasteroid@gmail.com> wrote: > > > When you deploy a new version of an app with Capistrano, the /current > symlink is updated to point to the new version of the app... Usually > Capistrano calls reaper to kill any running FastCGI processes, and spawner > to start up a the new version that''s pointed to by /current. Does LiteSpeed > + LSAPI circumvent this and automatically detect the switch between the two > versions of the app, and then start immediately handling requests with the > new version? > > If so, that would rock... I''m getting ready to look into deployment with a > poetentially high-traffic app, and this would be a really cool solution. > > Thanks! > > Matt > > On 7/25/06, George Wang < gwang@litespeedtech.com > wrote: > > > > There is no big differences between LiteSpeed and other solutions for > > scaling across multiple servers. Like you said, you can use LiteSpeed web > > server as a load balancer in front of a LiteSpeed cluster just like what you > > will do with lighttpd or Apache. LiteSpeed has better performance as we > > knew. Enterprise Edition is recommended for the load balancer role. We are > > going to release a dedicate load balancer which can do stateful load > > balancing if the internal stateless load balancer does not meet your needs. > > > > Since Pond is multi-threaded, its scalability is not as good. > > > > Deploying Rails applications into LiteSpeed with Capistrano should be > > easier than that with mongrel_cluster, I think, since you don''t need to > > patch deploy.rb at all. With LiteSpeed + LSAPI, there is no need to > > start mongrel manually, everything has been taken care of by web server. > > > > Just read a tutorial on "Rails + Mongrel + Apache + Capistrano", I have > > to say, that are a heck lot of configurations, and it is only a single > > server setup. Similar setup can be done much more easily with LiteSpeed + > > LSAPI + Capistrano, and performance should be better. Unless rails are > > deployed on multiple servers, you don''t need to bother load balancing at > > all. :-) > > > > If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :-) > > > > > > Best Regards, > > George Wang > > > > Matt White wrote: > > > > I''ve never tried LiteSpeed before, so this is a totally naive > > question... How would you scale LiteSpeed across multiple machines? At some > > point you''re going to hit a wall where one machine can''t handle the load, no > > matter how powerful it is... In my experience, the FastCGI or Mongrel > > solution of having a server like Lighty or Apache balance across multiple > > app instances on multiple machines seemed attractive and easy to scale. > > Deployment is easy, too. > > > > If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed > > servers and balance across them with another LiteSpeed server acting as a > > static load balancer? Or use Pound or some other specialized load balancer > > to balance across the LiteSpeed servers? > > > > Also, is there any documention on deploying into LiteSpeed with > > Capistrano? I know there''s a lot of hooks in mongrel_cluster for Capistrano, > > but I''m unaware of how it would work with LiteSpeed... > > > > Thanks, > > > > Matt > > > > On 7/24/06, George Wang < gwang@litespeedtech.com> wrote: > > > > > > There is no doubt that we will recommend LiteSpeed + LSAPI. ;-) > > > Not only because we are the developers of LiteSpeed Web Server, but > > > also LiteSpeed + LSAPI has solve some problems that other setup cannot. > > > > > > There is my take based on information collected, please correct me if > > > I were wrong. Not to criticize others, just want to help people making > > > decisions. > > > > > > Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI > > > persistent connections, lighttpd FCGI has reliability issue. Cannot do > > > dynamic spawning due to high cost at Rails framework initialization time, > > > system resource could be wasted under some situation like Rails hosting > > > services. > > > > > > Mongrel is very easy to use, and Rails performance is pretty good as > > > well. Its weakness is on serving static files, usually need to be use with > > > other web servers in production environment that receiving high traffic. > > > Need to run multiple instances with mongrel_cluster to take advantage a SMP > > > server and serving multiple clients at the same time, the setup has been > > > complicated a little bit. Same as FCGI, you cannot do dynamic spawning with > > > mongrel either. > > > > > > Since Pound cannot serve static content, Pound + mongrel_cluster is > > > not a optimum solution unless most of traffic is dynamically generated, > > > adding an extra layer of web server helps, but it will complicate things > > > even more and introduce higher latency and server load. Lighttpd + > > > mongrel_cluster is not recommended by Zed, the developer of mongrel, due to > > > bug in lighttpd proxy, at this moment. > > > > > > LiteSpeed + mongrel_cluster probably is the best solution for user who > > > prefers Mongrel right now. Jason from textdrive.com has written that > > > Apache 2.2 + mongrel_cluster has the best performance in his blog, We > > > cannot confirm that because we haven''t played with Apache 2.2 yet, > > > however, textdrive.com and strongspace.com are all powered by > > > LiteSpeed currently. ;-) > > > > > > LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned > > > above after analysis their Pros and Cons. > > > > > > Here is a Rails benchmark by third party. It is in Japanese, but the > > > graph is an universal language. > > > http://wota.jp/ac/?date=20060608 > > > > > > Tutorial on LiteSpeed + Ruby is in our Wiki > > > http://www.litespeedtech.com/community/wiki/doku.php > > > > > > Best Regards, > > > George Wang > > > > > > Matt White wrote: > > > I use Pound with mongrel_cluster behind Apache with mod_proxy, because > > > I''m running Apache 2.0 and using it for vhosting some other apps. If > > > you can get ''em to install Apache 2.2 you can use Apache + > > > mod_proxy_balancer and mongrel_cluster. > > > > > > Mongrel is super-simple to set up and use, seems quite stable, and > > > mongrel_cluster makes it very easy to manage. I used Lighty on a web app > > > that saw pretty intense usage earlier this year, and I had some problems > > > with zombie FastCGI processes, and reviving it usually required a reboot. > > > This only happened a couple times, though, so my overall experience with > > > Lighty was very good. It''s also easy to set up and use. My biggest concern > > > with Lighty is that it seems that development has stalled... They haven''t > > > released an update in some time. > > > > > > Matt > > > > > > On 7/24/06, Mark Hall < markh@networld.com> wrote: > > > > > > > > jh100000 wrote: > > > > > > > > > Should it be Apache with FastCGI or lighttpd? > > > > > > > > How about neither? Or if you really want Apache toss Mongrel behind > > > > it. > > > > FastCGI is not a good solution and is not really stable. The > > > > FastCGI > > > > project for Apache last I recall has been dead for some time now. > > > > FastCGI for Lighttpd has issues right now unless they''ve been > > > > addressed. > > > > > > > > Other options: > > > > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and > > > > fairly > > > > easy) > > > > 2. Pound + Mongrel (Simple) > > > > > > > > -- > > > > Posted via http://www.ruby-forum.com/ . > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails@lists.rubyonrails.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > Rails mailing list > > > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Rails mailing list > > > > Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > _______________________________________________ > > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060725/ef1b2731/attachment-0001.html
This is also an area of interest to me as we will be releasing our RoR app too. I have to say I hadn''t given much consideration to LiteSpeed much before reading this post. After some research it really does seem like an excellent solution, especially from a performance and security perspective. -- Posted via http://www.ruby-forum.com/.
Generally speaking, what happens is that the web server is switched to serving a static maintenance page while the code is switched out, the reenabled for dynamic content once the update is done. On Jul 25, 2006, at 1:54 PM, Matt White wrote:> When you deploy a new version of an app with Capistrano, the / > current symlink is updated to point to the new version of the > app... Usually Capistrano calls reaper to kill any running FastCGI > processes, and spawner to start up a the new version that''s pointed > to by /current. Does LiteSpeed + LSAPI circumvent this and > automatically detect the switch between the two versions of the > app, and then start immediately handling requests with the new > version? > > If so, that would rock... I''m getting ready to look into deployment > with a poetentially high-traffic app, and this would be a really > cool solution.
> Does it mean that multi-threading is in general slower?No necessarily, but usually, thread scheduling and synchronization are extra costs, and it requires more memory for per-thread stack space, that''s usually limits the scalability of multi-thread application.> How does litespeed handle this problem?LiteSpeed is single threaded and uses event-driven non-blocking socket.> > Interesting. What is the difference between LSAPI and FastCGI?Similar. You can think LSAPI as specially optimized FastCGI for LiteSpeed. :-) George
Ed, Can you share a little bit about your current rails setup with minimum downtime? I am interested to know and it will benefit others. With LiteSpeed, there is no downtime during a graceful restart, even during a server software upgrade, so front-end web server is always available. However, the server will queue up requests when back-end Rails restart. Unfortunately, the Rails framework takes some time to get initialized for each instance, usually longer than 1 second, I believe. LSAPI reduced this to minimum by forking all new Rails processes off an already initialized parent process. Only the parent process need to take time to initialize the framework once. The saving is significant if you need to start many rails instances all at once. Best Regards, George Ed Hickey wrote:> matt - thanks for the input. > > when mongrel restarts, does it do it gracefully and separately? for > instance, if you have 3 mongrel processes for your app and you do a > restart, does it kill one (one the client''s connection is dead), > restart it with the new code and then continue to the next mongrel > process? that way you''d never have a totally dead system. if it > waits till all 3 processes are down before restarting, there could be > some considerable downtime. > > > > On 7/25/06, *Matt White* <stockliasteroid@gmail.com > <mailto:stockliasteroid@gmail.com>> wrote: > > Ed, > > I''m actually pretty amazed with how transparent Capistrano > deployments are, regardless of the web server. I had a shortlived > data entry app running earlier this year that had a large number > of people working round the clock on it, and I ran several > deployments while they were working without a single problem. As > long as your deployment itself works, it shouldn''t be much of an > issue for downtime. > > Matt > > On 7/25/06, *Ed Hickey* < bassnode@gmail.com > <mailto:bassnode@gmail.com>> wrote: > I am also curious about this. I''m writing a rails app for a high > traffic site and it can''t afford to be unreachable for more about > 1 second. > > ed > > On 7/25/06, * Matt White* <stockliasteroid@gmail.com > <mailto:stockliasteroid@gmail.com>> wrote: > When you deploy a new version of an app with Capistrano, the > /current symlink is updated to point to the new version of the > app... Usually Capistrano calls reaper to kill any running FastCGI > processes, and spawner to start up a the new version that''s > pointed to by /current. Does LiteSpeed + LSAPI circumvent this and > automatically detect the switch between the two versions of the > app, and then start immediately handling requests with the new > version? > > If so, that would rock... I''m getting ready to look into > deployment with a poetentially high-traffic app, and this would be > a really cool solution. > > Thanks! > > Matt > > On 7/25/06, *George Wang* < gwang@litespeedtech.com > <mailto:gwang@litespeedtech.com>> wrote: > > There is no big differences between LiteSpeed and other > solutions for scaling across multiple servers. Like you said, > you can use LiteSpeed web server as a load balancer in front > of a LiteSpeed cluster just like what you will do with > lighttpd or Apache. LiteSpeed has better performance as we > knew. Enterprise Edition is recommended for the load balancer > role. We are going to release a dedicate load balancer which > can do stateful load balancing if the internal stateless load > balancer does not meet your needs. > > Since Pond is multi-threaded, its scalability is not as good. > > Deploying Rails applications into LiteSpeed with Capistrano > should be easier than that with mongrel_cluster, I think, > since you don''t need to patch deploy.rb at all. With LiteSpeed > + LSAPI, there is no need to start mongrel manually, > everything has been taken care of by web server. > > Just read a tutorial on "Rails + Mongrel + Apache + > Capistrano", I have to say, that are a heck lot of > configurations, and it is only a single server setup. Similar > setup can be done much more easily with LiteSpeed + LSAPI + > Capistrano, and performance should be better. Unless rails are > deployed on multiple servers, you don''t need to bother load > balancing at all. :-) > > If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a > try. :-) > > > Best Regards, > George Wang > > Matt White wrote: > I''ve never tried LiteSpeed before, so this is a totally naive > question... How would you scale LiteSpeed across multiple > machines? At some point you''re going to hit a wall where one > machine can''t handle the load, no matter how powerful it is... > In my experience, the FastCGI or Mongrel solution of having a > server like Lighty or Apache balance across multiple app > instances on multiple machines seemed attractive and easy to > scale. Deployment is easy, too. > > If you use LiteSpeed with LSAPI, would you just keep adding > LiteSpeed servers and balance across them with another > LiteSpeed server acting as a static load balancer? Or use > Pound or some other specialized load balancer to balance > across the LiteSpeed servers? > > Also, is there any documention on deploying into LiteSpeed > with Capistrano? I know there''s a lot of hooks in > mongrel_cluster for Capistrano, but I''m unaware of how it > would work with LiteSpeed... > > Thanks, > > Matt > > On 7/24/06, *George Wang* < gwang@litespeedtech.com > <mailto:gwang@litespeedtech.com>> wrote: > > There is no doubt that we will recommend LiteSpeed + > LSAPI. ;-) > Not only because we are the developers of LiteSpeed Web > Server, but also LiteSpeed + LSAPI has solve some problems > that other setup cannot. > > There is my take based on information collected, please > correct me if I were wrong. Not to criticize others, just > want to help people making decisions. > > Apache/lighttpd + FCGI: Apache and lighttpd does not > support FCGI persistent connections, lighttpd FCGI has > reliability issue. Cannot do dynamic spawning due to high > cost at Rails framework initialization time, system > resource could be wasted under some situation like Rails > hosting services. > > Mongrel is very easy to use, and Rails performance is > pretty good as well. Its weakness is on serving static > files, usually need to be use with other web servers in > production environment that receiving high traffic. Need > to run multiple instances with mongrel_cluster to take > advantage a SMP server and serving multiple clients at the > same time, the setup has been complicated a little bit. > Same as FCGI, you cannot do dynamic spawning with mongrel > either. > > Since Pound cannot serve static content, Pound + > mongrel_cluster is not a optimum solution unless most of > traffic is dynamically generated, adding an extra layer of > web server helps, but it will complicate things even more > and introduce higher latency and server load. Lighttpd + > mongrel_cluster is not recommended by Zed, the developer > of mongrel, due to bug in lighttpd proxy, at this moment. > > LiteSpeed + mongrel_cluster probably is the best solution > for user who prefers Mongrel right now. Jason from > textdrive.com <http://textdrive.com>has written that > Apache 2.2 + mongrel_cluster has the best performance in > his blog, We cannot confirm that because we haven''t played > with Apache 2.2 yet, however, textdrive.com > <http://textdrive.com>and strongspace.com > <http://strongspace.com> are all powered by LiteSpeed > currently. ;-) > > LiteSpeed + Rails via LSAPI is designed to overcome issues > mentioned above after analysis their Pros and Cons. > > Here is a Rails benchmark by third party. It is in > Japanese, but the graph is an universal language. > http://wota.jp/ac/?date=20060608 > <http://wota.jp/ac/?date=20060608> > > Tutorial on LiteSpeed + Ruby is in our Wiki > http://www.litespeedtech.com/community/wiki/doku.php > <http://www.litespeedtech.com/community/wiki/doku.php> > > Best Regards, > George Wang > > Matt White wrote: > I use Pound with mongrel_cluster behind Apache with > mod_proxy, because I''m running Apache 2.0 and using it for > vhosting some other apps. If you can get ''em to install > Apache 2.2 you can use Apache + mod_proxy_balancer and > mongrel_cluster. > > Mongrel is super-simple to set up and use, seems quite > stable, and mongrel_cluster makes it very easy to manage. > I used Lighty on a web app that saw pretty intense usage > earlier this year, and I had some problems with zombie > FastCGI processes, and reviving it usually required a > reboot. This only happened a couple times, though, so my > overall experience with Lighty was very good. It''s also > easy to set up and use. My biggest concern with Lighty is > that it seems that development has stalled... They haven''t > released an update in some time. > > Matt > > On 7/24/06, *Mark Hall* < markh@networld.com > <mailto:markh@networld.com>> wrote: > > jh100000 wrote: > > > Should it be Apache with FastCGI or lighttpd? > > How about neither? Or if you really want Apache toss > Mongrel behind it. > FastCGI is not a good solution and is not really > stable. The FastCGI > project for Apache last I recall has been dead for > some time now. > FastCGI for Lighttpd has issues right now unless > they''ve been addressed. > > Other options: > 1. http://www.litespeedtech.com > <http://www.litespeedtech.com> Litespeed + LSAPI > (Fast and fairly > easy) > 2. Pound + Mongrel (Simple) > > -- > Posted via http://www.ruby-forum.com/ > <http://www.ruby-forum.com/>. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > > > Rails@lists.rubyonrails.org > <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > > > Rails@lists.rubyonrails.org > <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060726/250b2a44/attachment-0001.html
> When you deploy a new version of an app with Capistrano, the /current > symlink is updated to point to the new version of the app... Usually > Capistrano calls reaper to kill any running FastCGI processes, and > spawner to start up a the new version that''s pointed to by /current. > Does LiteSpeed + LSAPI circumvent this and automatically detect the > switch between the two versions of the app, and then start immediately > handling requests with the new version?If you run LiteSpeed + LSAPI on a cluster node, you only need to let Capistrano to call "lsws/bin/lswsctrl restart" to archive the same result. restart is graceful without any downtime.
On 7/24/06, Mark Hall <markh@networld.com> wrote:> jh100000 wrote: > > > Should it be Apache with FastCGI or lighttpd? > > How about neither? Or if you really want Apache toss Mongrel behind it. > FastCGI is not a good solution and is not really stable. The FastCGI > project for Apache last I recall has been dead for some time now. > FastCGI for Lighttpd has issues right now unless they''ve been addressed. > > Other options: > 1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly > easy) > 2. Pound + Mongrel (Simple)3. Apache + mod_fcgid Isak
> I''m not exactly sure how mongrel_cluster handles that... However, startup > time for Mongrel isn''t long at all, under a second to start three of them on > my VPS. This would seem to indicate that you''d have a second of downtime or > less during a deployment. If you''re running high enough load that a second > isn''t good enough, then it would be interesting to find out if > mongrel_cluster already supports what you''re talking about, or if it could > be patched to do it. >Yes, for the app I''m writing, 1 second downtime is not a good thing. It''s not a frontend type app, it''s a web service which needs to handle 2M+ requests a day. Therefore, It can''t be down for every code push. This makes the LiteSpeed LSAPI solution sound interesting... If I could> throw a temp page up for two seconds while it restarts, that doesn''t seem > that bad either. You could just as easily do the same with Lighty or Apache > with Capistrano, too, though... >In general the temp html page would be ok, but not for a service-based app like I''m working on. If the server was down, you''d have to just ignore the incoming requests. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060726/2ad4e184/attachment-0001.html
On Jul 26, 2006, at 8:16 AM, Ed Hickey wrote:> Yes, for the app I''m writing, 1 second downtime is not a good > thing. It''s not a frontend type app, it''s a web service which > needs to handle 2M+ requests a day. Therefore, It can''t be down > for every code push. > > > This makes the LiteSpeed LSAPI solution sound interesting... If I > could throw a temp page up for two seconds while it restarts, that > doesn''t seem that bad either. You could just as easily do the same > with Lighty or Apache with Capistrano, too, though... > > In general the temp html page would be ok, but not for a service- > based app like I''m working on. If the server was down, you''d have > to just ignore the incoming requests.Include a response in your web service specification that means: "I''m undergoing maintenance, try again!" Make the temporary page send back that response. When people shoot for zero downtime, it''s generally understood that means zero *unplanned* downtime. -- -- Tom Mornini