There are tools that cache the wordpress web pages or imporve PHP performance but basically all of them try to work around quering the database and PHP interpreter and serving static files instead..

To add to the CPU limitations of the Pi , using an SD card also means delays when writing/and reading to disk ( not to mention the finite read/write cycles ) when performing automatic caching operations , so instead of this I decided to add a script ( basically an alias for a wget call with the needed parameters ) that clones the whole site without hassle..

If you want to try it and after cloning AmmarServer ( with “git clone git://github.com/AmmarkoV/AmmarServer ” ) you can use the bash script provided in the repository and called “MirrorAmmarServer.sh”
Lets say that your WordPress blog is hosted on http://ammar.gr .
STEP 1 ) Being on the parent directory of AmmarServer issue “./MirrorAmmarServer.sh http://ammar.gr”
wget will gradually start to mirror the site into static files and create a subdirectory called ammar.gr/ where the files will be stored
STEP 2 ) Edit the file src/main.c and change char webserver_root[MAX_FILE_PATH]=”public_html/”; to char webserver_root[MAX_FILE_PATH]=”ammar.gr/”;
If you want you can change the DEFAULT_BINDING_PORT to another port ( you may want to set it to port 80 because the default is 8080 )
STEP 3 ) issue “./make && ./run_ammarserver” and voila your site will be availiable at http://127.0.0.1:8080 ( or any other port you choose )

Here is a comparison of pinging the Raspberry Pi and pinging my Intel Based Server PC on a LAN

The ping times of the intel system have an average of 0.158 ms while the raspberry pi has an average time of 0.543 ms , almost 3-4 times worse..

Here are some benchmarks conducted with chromium that give an overview of the performance difference ( all of the tests are done in a LAN so bandwidth is not a limiting factor ) :

Left : First Uncached Hit , Apache Serving regular WordPress on my regular PC ( 1.33MB transferred , DOMContent loaded @ 494 ms , onload @ 1.35s )
Right : First Uncached Hit , AmmarServer serving cached static files on Raspberry Pi ( 1.39MB transferred , DOMContent loaded @ 159 ms , onload @ 968ms )

Left : Second Hit after clicking Home , Apache Serving regular WordPress on my regular PC ( 22.67KB transferred , DOMContent loaded @ 566 ms , onload @ 2.04s )
Right : Second Hit after clicking Home , AmmarServer serving cached static files on Raspberry Pi ( 61.54KB transferred , DOMContent loaded @ 140 ms , onload @ 515ms )

Left : Apache Serving cached static files on my Regular PC
Right : AmmarServer serving cached static files on Raspberry Pi

Some things to notice is that in the static files version of the site , the image links on the menu bar that come directly from github , and the youtube embeds are the most laggy parts of the page and this distorts loading times. The onload event would drop by almost 400ms if they were part of the site..

Performance also gets better by increasing the priority of the webserver ( IRL decreasing it to -15 ) , removing cross-site content and making some other small tweaks. I have managed to drop times to around 50-60ms and I hope to further improve those numbers..

Network latency of course is the biggest bottleneck when dropping times so low and in any case even if i managed to serve the whole site from 60ms ( transaction latency ) + 150ms ( network latency ) in say 20ms ( transaction latency ) + 150 ms ( network latency ) the perceived difference from the average client will be very small..

Thats it for now..

To profile my server’s behaviour I am using chromium and the very handy Developer Tools that come integrated in it , Especially the Network Timeline feature is great for debugging this sort of things.. RedBot is also a very useful tool! that I use for debugging HTTP handshakes..

Although my implementation isn’t ready yet I am getting some very weird results when I emmit 304 Not Changed responses illustrated in the screenshots bellow ..!

The screenshots are that big due to my dual 1080p screen setup

I can’t seem to grasp the reason why a 304 response has such a large “Waiting Time” , Is it my Response header that is missing something , is it the whole Keep Alive thing not being handled properly , or is the waiting time supposed to mean something else in the graph..
How is it possible when only 200 byte headers get served that the response time is 4 times worse than when the full files get served from memory ?

I haven’t still figured it out and it is driving me crazy , but I will get to the bottom of this ..

UPDATE
After some tweaking around and with the help of redbot it turns out that the 304 Not Modified header should retransmit all of the original fields transmitted with the first “200 OK” message.. This means all of the E-Tag , Date etc fields.. I was missing out some of them so including them fixed the behaviour..

Having the opportunity to first-hand test the pi I immediately apt-got git and cloned my AmmarServer repo to test it with the board

The results look very promising since the pi with ammarserver beats my current mini-itx intel atom based setup which is running the heavier apache webserver..

In more detail subsequently querying a static version of the the page you see right now ( as described in a previous post ) gave the following times..

Raspberry Pi using AmmarServer :
00:00:02.64 <- first uncached try with actual sd read time ( also worth to note that a Class 10 sd card is used )
00:00:00.706 <- rasp cached , no file reading involved
00:00:00.787 <- rasp cached , no file reading involved
00:00:00.818 <- rasp cached , no file reading involved
00:00:00.833 <- rasp cached , no file reading involved
00:00:00.788 <- rasp cached , no file reading involved
00:00:00.810 <- rasp cached , no file reading involved

My current webserver using apache ( and dynamic content [ php/mysql/wordpress ] ) :
00:00:02.802 <- ammar.gr with apache
00:00:01.561 <- ammar.gr with apache (some images etc. cached probably)

My current webserver using AmmarServer ( and static saved pages ) :
00:00:01.72 <- ammar.gr first uncached try with actual hd read time
00:00:00.678 <- ammar.gr with ammarserver cached , no file reading involved
00:00:00.652 <- ammar.gr with ammarserver cached , no file reading involved

As one can see the best times of the pi 00:00:00.706 are pretty damn close to the 00:00:00.652 of my current machine when the content is already cached in memory so I may be changing my web hosting setup soon..!

I will probably keep my current webserver as a platform to make dynamic webpages using the really nice GUI of wordpress and then pass static versions of them to the pi which will act as the always on webserver..
An additional thing that I didn't test was performance using more processes like a mumble server, an ftp server or an actual php/apache setup but..

When I'll order my own pi I will try all of them and blog back with my results..!