LiteSpeed & LSAPI

Posted by Mathew Abonyi Sat, 28 Oct 2006 12:00:00 GMT

As part of a series on the LiteSpeed server, which I’ve come to really love for its small memory footprint, speed and ease of use, I’m going to make a few articles on setting up LiteSpeed to work smoothly—or at least as it does for me.

Requirements

  • a working installation of LiteSpeed 2.2.x
  • prior knowledge of the LiteSpeed wiki

Quick Summary

There are two ways to deploy using LiteSpeed’s custom-built API for Ruby. The first is to use their latest Rails context, which is configured in Server > Rails. The second is to set up a custom LSAPI external application in either your Server or Virtual Host context. I prefer something a little more hands on in order to control ecah application, so I use the second method.

Step 1: Install Ruby LSAPI

sudo gem install ruby-lsapi

The latest version at the time of writing is 1.11.

Step 2: Copy LSAPI to RAILS_ROOT/public/dispatch.lsapi

Most people have their rubygems located in /usr/lib/ruby/gems or /usr/local/lib/ruby/gems. Copy over the dispatch.lsapi like this:

$ cp /usr/lib/ruby/gems/1.8/gems/ruby-lsapi-1.11/rails/dispatch.lsapi public/dispatch.lsapi

Be sure to commit your changes before continuing to step 3.

Step 3: Define Server or VHost External Application


Type: LSAPI App
Name: mywebapp
Address: uds://tmp/lshttpd/mywebapp.sock
Max Connections: 5
Environment:
  RAILS_ENV=production
  LSAPI_CHILDREN=5
Initial Request Timeout: 120
Retry Timeout: 60
Persistent Connection: Yes
Connection Keep-Alive Timeout: 1000
Response Buffering: No
Auto Start: Yes
Command: $VH_ROOT/public/dispatch.lsapi
Back Log: 100
Instances: 1
Run On Start Up: Yes
Max Idle Time: -1
Memory Soft Limit: 80M
Memory Hard Limit: 100M
Process Soft Limit: 200
Process Hard Limit: 250

Explanation

Max Connections and LSAPI_CHILDREN: In order to account for unresponsive LSAPI threads, you should expect in the worst case scenario to have twice the number of threads as your Max Connections. These extras will be killed off.

Initial Request Timeout: Generally, you want this value set pretty high so LiteSpeed doesn’t think the external application is unresponsive and spawns a new one.

Max Idle: Setting this to -1 ensures the application isn’t removed from the pool and the following request incurs a start-up delay.

Instances: We pretty much ignore this value because we’re using LSAPI_CHILDREN instead. We want Ruby LSAPI to be the application manager, not LiteSpeed itself.

Back Log: How many requests to queue up before giving a server error. This will almost never happen if your server is up to the job.

How Many Max Connections?

On even the smallest web server with 256MB memory, you can get away with Max Connections set to 3 and still have plenty of memory for other things. Roughly, if you have 512MB, you want 5 threads; for 1GB, push up to 10; for 2GB, push up to 20. These connections help your concurrency; they do not increase the speed. If you do not have [MaxConns x 86400] hits a day, then you don’t need it to be set so high. Be frugal. These numbers will, of course, need adjustment and will also depend on what else is running on the system.

Step 4: Some URL Rewrites

One of the things which puts LSAPI higher in my opinion than Mongrel as a deployment option is the ability to use the custom rewrites to feed out static content as well as serve that all-important maintenance splash screen effectively. Here is a working [Virtual Host] > Rewrite setup:

Enable Rewrite: Yes
Log Level: 0

Rewrite Rules:

RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{REQUEST_FILENAME} !/stylesheets*
RewriteCond %{REQUEST_FILENAME} !/images*
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^(.*)$ /system/maintenance.html [L]

RewriteRule ^/$ /index.html [QSA]
RewriteRule ^/([^.]+)$ /$1.html [QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ /dispatch.lsapi [QSA,L]

Explanation

You’ll notice in the first block of rules that there are some extras for the maintenance.html file check which you may not have seen before: stylesheets and images. This allows you to create your own maintenance splash with images and stylesheets—perhaps even the same ones used in the rest of your application.

The second block attempts to serve cached pages through LiteSpeed if Rails has made any.

The third block throws everything back at Rails if it isn’t found.

Step 5: Create Your VHost Context


Type: LiteSpeed API
URI: /dispatch.lsapi
LSAPI App: [Server Level]: mywebapp

Explanation

If you are wondering why we make the URI ’/dispatch.lsapi’ instead of ’/’, this is to use the rewrite rules from Step 4. Everything will route back to dispatch.lsapi if it doesn’t already exist, but if there are files which can be served, we want LiteSpeed to handle it. This is a pretty easy way to deal with it.

Step 6: `sudo lswsctrl restart`

Posted in ,  | 1 comment

Comments

  1. Nathanc said 8 months later:

    Thank you, thank you. The litespeed site did a poor job explaining how important the rewrite rules are. I have been working on this for over a day straight, trying different things. Then I found your blog, and it was fixed in less then 2 minutes.

    Thanks, Nathan

(leave url/email »)

   Comment Markup Help Preview comment