in ,

Optimizing lighttpd web server

Optimizing lighttpd web server

lighttpd

lighttpd (pronounced “lighty“) is a fast, secure and flexible webserver. The build-in module system allows it be extended as much as the more mature Apache server, and its featureset is pretty complete right out of the box.

Compression

Like most other web-servers lighttpd supports the use of gzip-compression.

Enabling compression generally involves a making trade-off between using the CPU to perform compression, versus just sending more traffic out to the network, however lighttpd does allow you to work around this problem by writing the compressed content to disk.

Compressing the content on-disk means that multiple requests for a compressible document do not need to burn CPU-cycles repeatedly compressing the same document.

The only caveat to this behaviour is that you need to both specify and create the cache-directory. The following is a reasonable example:

server.modules  = (
                    # Your modules here ..
                    "mod_compress",
                    # Your modules here ..
                  )


#### compress module
compress.allowed-encodings = ("gzip", "deflate")
compress.filetype          = ("text/plain", "text/html", "text/javascript", "text/css", "text/xml" )

# You must create this directory.
compress.cache-dir = "/srv/tweaked.io/cache"

The compression-cache is keyed upon the document name, size, and E-tag, to avoid issues when the original document changes. That said it is still recommended you setup a script to purge the cached content which is older than a few days.

Client Caching

A simple way of avoiding your server handling requests is if remote clients believe their content is already up-to-date.

To do this you want to set suitable cache-friendly headers, and a simple way of doing that is to declare that all images, etc, are fixed for a given period of time.

To do this load mod_access, and define patterns:

server.modules  = (
                     # Put mod_access first.
                     "mod_access",
                     # Your modules here ..
                  )

# Cache based on suffix
$HTTP["url"] =~ "\.(jpg|gif|png|css|js)$" {
     expire.url = ( "" => "access plus 2 months" )
}

# Cache based on path
expire.url = ( "/fonts/" => "access plus 2 months",
               "/i/"     => "access plus 2 months",
               "/media/" => "access plus 2 months",
             )

Tuning for PHP

Lighttpd supports the use of PHP plain CGI or via FastCGI. For performance you want to use the FastCGI + PHP FPM combination.

Install the PHP5-FPM package, such that you can get a persistant pool of workers, then configure lighttped to use them like so:

server.modules += ( "mod_fastcgi" )

index-file.names += ( "index.php" )

fastcgi.server = (
    ".php" => (
      "localhost" => (
        "socket"                => "/var/run/php5-fpm.sock",
        "broken-scriptfilename" => "enable"
      ))
)

Notice that this uses a Unix domain-socket to connect to FPM, so you need to ensure that you change /etc/php5/fpm/pool.d/www.conf to read:

listen = /var/run/php5-fpm.sock

This ensures that FPM will listen on a domain socket, rather than the default of listening on a network-socket (the default is “listen=127.0.0.1:9000“).

By default PHP-FPM will start a number of dedicated workers, each running an instance of PHP. If you're not swamped for memory you can increase the number of workers to increase concurrent-throughput.

Edit the file /etc/php5/fpm/pool.d/www.conf to change the number of children:

; set a fixed number of php workers
pm = static

; start up 12 php processes
pm.max_children = 12

This is an example setting, of the kind we mention in the considerations section – the value of 12 is just an example, which you will need to test under-load to see if it is reasonable for your particular setup.

General Webserver Notes

We also have a page of general notes for webservers.

#
# Don't resolve requesting IPs into hostnames for logging.
#
HostnameLookups Off

 

When you just can't scale further

When you can't scale any further you might gain additional performance by placing a caching proxy in front of your server.

The Varnish Cache is highly regarded, but there are also other alternatives such as the venerable Squid cache.

 

Author: Steve Kemp, of  tweaked.io

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *

      General Webserver Tips

      General Webserver Tips

      Tuning GNU/Linux Kernel

      Tuning GNU/Linux Kernel