Core Settings

Using this scenario as a starting point, we will enumerate the knobs to be turned. Here are some configuration settings that will make our Lighttpd serve large files faster and more reliably than the defaults. First, we make sure range requests are enabled using the following command:

# if we have disabled range requests for some reason:
server.range-requests = "enable"

We want to use the optimal network backend for sending out content. If in doubt, take a file of the size we want to serve or create (for example, we can use dd to create a 1GB file):

$ dd if=/dev/zero of=our_file bs=1024 count=10480576

Now, put this file into our document root and run an http_load test (refer to Chapter 9 for further details) with each network backend that we get to run. Then, pick the fastest network backend. Probably it is one of the following, depending on your system. Take your pick and be sure to test on our system; when in doubt, test all of them:

server.backend = "writev"             # optimal for 1.4 versions
server.backend = "posix-aio"          # the fastest for large files
server.backend = "gthread-aio"        # using threads to multiplex
server.backend = "linux-aio-sendfile" # optimized for linux

In the next step, ramp up the idle write timeouts:

server.max-write-idle = 720   # double to 12 minutes.

This allows clients to keep a connection-on-hold a little longer, which they might do for any old reason (for example, their network might be down for a second), without killing their download. On the other hand, we might want to reduce the maximum keep-alive requests to free up connections sooner (because we will not have as many requests, but the ones we have will last longer):

server.max-keepalive-requests = 8 # half the requests
# if we have a different setting than the default, set
server.max-keepalive-idle = 5     # seconds

This should be all it needs to make our Lighttpd large-file friendly. Note that some of the settings may be pessimizations in other scenarios, for example, say some small requests. Therefore, we might want to limit the impact of these options to where we need them.