Tag: lighttpd

Lighttpd and the wonders of strace

I ran Lighttpd under strace today whilst debugging a problem with mod_deflate and I found two mis-configurations just from watching the system calls it was making. In case anyone is interested, this is what I found.

Firstly, I’d enabled the system.use-noatime option but I could see that it was failing to set this mode when opening a file to serve:


open("/home/john/.../newsniffer.css", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_NOATIME) = -1 EPERM (Operation not permitted)
open("/home/john/.../newsniffer.css", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 40

I realised that Lighty drops privileges on start-up, and the O_NOATIME option is privileged. No biggie, but a wasted system call is a wasted system call, so I disabled the option. To my surprise, this fixed the blank/empty page problem I was having with mod_deflate. Clearly a bug, but now I can file a slightly more helpful bug report (this is the Lighttpd dev trunk btw).

Secondly, I’d always assumed (having read it somewhere, I’m sure) that Lighttpd selected the most efficient event-handler available on the operating system – on my Linux 2.6 system this would be epoll, but strace showed Lighttp using regular poll:


poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}], 6, 1000) = 0

So, I explicitly configured it with server.event-handler = "linux-sysepoll" and now strace shows me:


epoll_wait(39, {}, 4096, 1000)          = 0

I’ve always found the strace tool very useful, but sometimes I forget and take it for granted. I love you strace tool.

29/7/2007 1 Comment

MoinMoin wiki with Lighttpd 1.5

This took me a little while to figure out, so I’ll blog here to help others (and me, next time I need to do it and can’t remember how).

I use the MoinMoin wiki software to run a couple of wikis and they run under the Lighttpd web server. With the current stable Lighttpd (1.4) you configure it to use the MoinMoin fastcgi service a bit like this:


  $HTTP["url"] =~ "^/wiki" {
    fastcgi.server =  ("/wiki" => ( "mywiki" =>
      ( "host" => "127.0.0.1",
        "port" => 22000,
        "check-local" => "disable",
        "broken-scriptfilename" => "enable" )
      ))
  }

The new Lighttpd (currently in development, but to be version 1.5) has reworked the way you define fastcgi backends, and has lost the “broken-scriptfilename” option in the process. Without it, MoinMoin doesn’t see what wiki page you’re trying to visit, and can’t build new links properly. Luckily you can reproduce this feature with some proxy-core rewrites:


  $HTTP["url"] =~ "^/wiki" {
    proxy-core.protocol = "fastcgi"
    proxy-core.backends = ( "127.0.0.1:22000" )
    proxy-core.rewrite-request = (
      "_pathinfo" => ( "^/wiki(/.*)" => "$1" ),
      "_scriptname" => ( "^(/wiki)" => "$1" )
    )
  }

And your MoinMoin lives to be spammed another day.

29/7/2007 2 Comments

Maintenance pages status codes and Lighttpd

I’ve noticed a few very broken maintenance page Lighttpd config examples around, including the one on the mod_magnet documentation page. They all manage to display the maintenance page ok, but they return a HTTP 200 status code to the client, rather than the more appropriate HTTP 503 code.

As with all 500 status codes, the 503 code is an error code but it signifies a temporary error. The client should try again later (in fact you can specify how much later using the Retry-After header).

A 200 code tells the client everything is normal and OK. So the user gets your nice maintenance page telling them of a temporary outage, whereas their browser gets told that everything is fine. Now this might not be a problem for a user, but if the client is a search engine or a caching proxy then it will assume the maintenance page is the new valid content for the request.

If the Google crawler hits your site when you have the maintenance page up, it will update its search index with your “we’re down for now” message, rather than your cash prizes blog content. Your page rank will drop, your fat Adsense cheque will diminish and you’ll have to go back to your regular nine to five job in the city with people you don’t like in clothes you hate wearing.

So, as you can see, it’s important to return the correct status code. Here’s how to do it with Lighty and mod_magnet:

(more…)

10/1/2007 2 Comments

Bruce Schneier whistles white noise

The new ELER strip is about Bruce Schneier and links to a Chuck Norris style Bruce Schneier Facts Database system I wrote. It got linked from Boingboing, Metafilter, Reddit and even Bruce Schneier’s own blog!

As you might imagine, it’s getting trabigillions of hits right now. Lucky I wrote it in Ruby on Rails with its built in page caching which (after first render) serves as fast as the webserver can serve. And since I’m using Lighttpd too, that is very fast.

17/8/2006 Add Comment

High performance WordPress

Of all the WordPress installations I manage, two of them bring in a rather large number of hits.

To speed up WordPress I usually just enable the MySQL query cache and install the eaccelerator PHP opcode cacher. On one particular box, an Intel 1.3Ghgz PIII this increased performance from around 3 requests per second to around 10.

Recently I came across the WP-Cache plugin for WordPress. This takes the finished output from any given wordpress request and caches it to disk, serving directly from the static cache for the next hour (configurable). Any new posts or comments in the mean time immediately mark the cached version stale, so you don’t need to wait around for an hour.

On the same hardware and blog, this increases performance from 10 requests per second to over 250. A 2500% increase in speed.
(more…)

5/6/2006 Add Comment

Lighttpd and Ruby on Rails: Secure and Fast Downloading

When controlling access to files on a webserver developers often use the web application itself as a file server. The request comes in, the script checks for some session authentication variable or something, then streams the file from disk (hopefully from outside the webroot) to the browser.

The problem with this from a performance standpoint is that a thread/process of the web application has to be running for the entire duration of the download. With a busy webserver serving many concurrent downloads, this is an immense overhead. The web server itself should be orders of magnitude faster at serving files directly than via a web application, but you can’t just stick the files in a different directory and hope nobody finds the secret urls. The new web server on the block, Lighttpd, has some clever solutions for this problem.
(more…)

16/3/2006 3 Comments

Turck MMCache speediness on Debian Sarge

UPDATE: The info in this post is deprecated. See the new post about eAccelerator instead.

I installed Turck MMCache PHP accelerator and I got a big improvement.

ApacheBench reported 4.52 pages per second before and 12.47 pages after installation (a WordPress 1.5.2 page on a 1.2Ghz PIII). That a 275% increase in performance, with currently no observed problems. I tested this with both Apache2 and lighttpd, and got a similar boost with both.

There is only a package for Debian unstable at the moment, so I downloaded the package source and backported it to Debian sarge. I put the package in my apt repository (along with a backported openswan package I’m using). Add to your sources.list:

deb http://johnleach.co.uk/downloads/debian sarge backports

and apt-get update ; apt-get install turck-mmcache

See PHP fly (comparatively)

UPDATE: I’m running into a few problems now actually. WordPress runs fine, but an application of my own is having some serious problems. MMTurck is kicking out the following log message:

[13072] MMCACHE: PHP crashed on opline 1 of main() at /path/to/webapp/cligs-app.php:24

I’ve disabled the extension for now until I investigate further.

UPDATE: S

12/1/2006 1 Comment