Tutorial in installing LiteSpeed with FastCGI and Catalyst
- Thread starter Conundrum
- Start date
Hi Conundrum,
Thank you for the tutorial. A few comments:
1) Initial Request Timeout is too short, should be set to something like "60", otherwise, litespeed may think the request has been failed for a request that needs more than 1 seconds to process.
2) Instead of starting the FastCGI server manually, you can have LiteSpeed start it automatically. Set "instances" to match "Max Connections", no need for those command line options.
3) LiteSpeed does support Load Balancing, to do that, you need to define multiple FastCGI app, and one "Load balancer" app.
Thank you for the tutorial. A few comments:
1) Initial Request Timeout is too short, should be set to something like "60", otherwise, litespeed may think the request has been failed for a request that needs more than 1 seconds to process.
2) Instead of starting the FastCGI server manually, you can have LiteSpeed start it automatically. Set "instances" to match "Max Connections", no need for those command line options.
3) LiteSpeed does support Load Balancing, to do that, you need to define multiple FastCGI app, and one "Load balancer" app.
Thanks for the reply. I've updated the page to change Initial Request Timeout and mention LiteSpeed has built-in load balancing support. I'll try the load balancing soon but just mentioned it is available for now.
Regarding having LiteSpeed automatically start the requested number of FastCGI servers, my understanding is other frameworks like Rails typically have one FastCGI process per external server. For Catalyst, each external server is a FCGI:
rocManager process managing a specified number of FastCGI servers. Is there a preferred way to set up LiteSpeed in this scenario?
Regarding having LiteSpeed automatically start the requested number of FastCGI servers, my understanding is other frameworks like Rails typically have one FastCGI process per external server. For Catalyst, each external server is a FCGI:
rocManager process managing a specified number of FastCGI servers. Is there a preferred way to set up LiteSpeed in this scenario?It is preferred to let LiteSpeed start FCGI applications no matter which Process Manager is used. I personally prefer LiteSpeed's built-in process manager. It is more intelligent, and have the following advantages
1) On-demand dynamic spawning, uses system resource more efficiently.
2) Fault tolerance. Some FastCGI app is not very reliable and may stop working after running for a while, LiteSpeed can start a new group of processes automatically, most FCGI built-in proc manager cannot do that.
3) Simple and easy, you don't need to worry about starting the app manually.
Even when an application's internal process manager is prefered, you can still let LiteSpeed start the parent process automatically, in that case, just set "instances" to "1", and set the command line parameter '-n' to match "Max Connections" and get rid of "-d" option.
1) On-demand dynamic spawning, uses system resource more efficiently.
2) Fault tolerance. Some FastCGI app is not very reliable and may stop working after running for a while, LiteSpeed can start a new group of processes automatically, most FCGI built-in proc manager cannot do that.
3) Simple and easy, you don't need to worry about starting the app manually.
Even when an application's internal process manager is prefered, you can still let LiteSpeed start the parent process automatically, in that case, just set "instances" to "1", and set the command line parameter '-n' to match "Max Connections" and get rid of "-d" option.
Conondrum,
The world need more indepth how-tos. =) Is it okay with you if we import your how-to into our wiki? We will obviously link to your/original site with proper credits given.
One problem I see is the line "LiteSpeed's Persistent FastCGI connection, which is known to have problems with Ruby, also was not tested."
The problem is not with LiteSpeed but rather with Ruby's FastCGI implementation. LiteSpeed supports persistent connections to FastCGI but Ruby's FCGI does not support this. Thus you have to disable "Persistent Connection" when using Ruby with via LiteSpeed FCGI config. This is one of the reasons LiteSpeed developed LSAPI for Ruby after conversations with developers at TextDrive which are heavy users of everything Ruby/Rails. Instead of relying on 3rd party maintainers to upgrade the Ruby's FCGI module, might as well create a best of breed SAPI for LiteSpeed and Ruby minus the short-comings of Ruby FCGI.
The world need more indepth how-tos. =) Is it okay with you if we import your how-to into our wiki? We will obviously link to your/original site with proper credits given.
One problem I see is the line "LiteSpeed's Persistent FastCGI connection, which is known to have problems with Ruby, also was not tested."
The problem is not with LiteSpeed but rather with Ruby's FastCGI implementation. LiteSpeed supports persistent connections to FastCGI but Ruby's FCGI does not support this. Thus you have to disable "Persistent Connection" when using Ruby with via LiteSpeed FCGI config. This is one of the reasons LiteSpeed developed LSAPI for Ruby after conversations with developers at TextDrive which are heavy users of everything Ruby/Rails. Instead of relying on 3rd party maintainers to upgrade the Ruby's FCGI module, might as well create a best of breed SAPI for LiteSpeed and Ruby minus the short-comings of Ruby FCGI.
I'm looking for making Mono work with LiteSpeed. I thought above mentioned HowTo would be helpfull, but that link is no longer working and you guys didn't link your ported HowTo doc. I was trying to setup FastCGI with LS too, but I couldn't find a nice doc too.
Please let me know any links to help me
Please let me know any links to help me
I've added the original to Github at the link below so you can see if it's useful.
https://github.com/grokify/cookbook...ookbook_install_litespeed-fastcgi-catalyst.md
Hope it helps!
https://github.com/grokify/cookbook...ookbook_install_litespeed-fastcgi-catalyst.md
Hope it helps!