WordPress glitches with lighttpd on OpenWRT

When I started playing with wordpress as another service on my tiny server box I integrated it with basic OpenWRT webserver, the uhttpd. To leverage from pretty permalinks, secure administration, or to prevent from images hotlinking I decided to migrate to more advanced HTTP sever. My choice was either Apache webserver or lighttpd. With limited memory on router box obvious choice was the latter.

With many guidelines online migration was quite easy. Homepage was running properly, except for administrative dashboard, which was complety blocking wordpress for couple minutes. I opened resource monitor and found that memory consumption crossed easily 64MB of RAM and was asking for swap more and more. When 130MB of swap was allocated I decided to kill puffed up PHP processes.

It took me a while to understand that uhttpd process can run one PHP script at the time, while lighttpd run multiple PHPs in parallel. WordPress dashboard has couple widgets each of them running index-extra.php. I observed that with uhttpd widgets are processed one by one, and memory consumption was bumping up by 25-30MB RAM, still fitting into RAM limits. It was relatvely fast: 20-30 seconds to fill in all 5 defualt widgets. On lighttpd all widgets spawned 5 PHPs that started to compete for memory. Math was simple here, 5×25=125MB of additional memory necessary to complete scripts. Swap allocation and parallel processing on tiny processor completly blocked website.

To control resources I used fast cgi and set limit of PHP parallel scripts. Fast cgi is coordinator of pool of PHP interpreters that are kept running; coordinator listens for clients requesting script processing and runs them without need to spawn PHP process each time.

I have installed fast cgi and enabled mediating process listening on default port 1026.

opkg install lighttpd-mod-fastcgi php5-fastcgi
/etc/init.d/php enable
/etc/init.d/php start

then I have configured fast cgi in /etc/lighttpd/lighttp.conf enabling module and adding its configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

server.modules = (
      ...
      "mod_fastcgi",
      ... )
 
fastcgi.server = (
  ".php" => (
    "localhost" => (
      "host" => "127.0.0.1",
      "port" => "1026",
      "bin-path" => "/usr/bin/php-cgi",
      "max-procs" => "2"
    )
  )
)

Line 12 limits parallel processes to 2, which speeds up overall system throughput comparing to uhttpd, while keeping memory consumption within physical RAM limits. After lighttpd restart, wordpress dashboard started to work as expected.