Tutorial in installing LiteSpeed with FastCGI and Catalyst

[Conundrum]

In case anyone is interested I put together a doc on getting LiteSpeed up and running with the Catalyst framework:

Installing LiteSpeed and FastCGI for Catalyst

[mistwang]

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.

[Conundrum]

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::ProcManager process managing a specified number of FastCGI servers. Is there a preferred way to set up LiteSpeed in this scenario?

[mistwang]

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.

[xing]

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.

[Conundrum]

Originally Posted by xing

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.

No problems on importing it into the LiteSpeed wiki. I agree more how-tos are better.

Originally Posted by xing

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.

Thanks for the update. Good to know.