Now though, PHP.net has made it’s documentation fully editable by members of the public through a web-based DocBook editor at https://edit.php.net. We’re hoping that this will lead to even greater quality of documentation and remove the need for some of the older comments (despite the occasional glaring inaccuracy, most “wiki” benefit hugely from peer review).

The PHP manual has also been released in some additional formats – an extended CHM file with all the user-contributed comments, and a text-based package accessed from the command-line in the same way as Unix man pages (in fact the command is simply “pman”). We’ve wasted no time in adding commands to our various editors to take advantage of this (previously we’d launch a browser window with a keyword search).

Finally, there’s an slightly odd footnote about a future release of the manual in JSON format. We’re not sure what their plan behind this was, but having the manual in an easy-to-use structured format can be no bad thing.

See the news on PHP.net here.

Amongst other issues, it was clear from the graphs that a large part of their speed increase between the two tests was the lack of a DNS lookup in the second test. In this case, there seemed to be many changes made at the same time, which understandably makes proper benchmarking somewhat difficult. Even if that wasn’t the case though, there is a lot that can be done to stop DNS from interfering with your tests.

Where’s the Cache?

The problem with DNS is that it is cached in so many different places. There’s a browser cache, an operating system cache, the cache at your ISP and possibly a few up-stream from them as well. We also need to think about other internal systems such as caching proxies that may be setup on your local network.

Only some of these caches are under our control – namely the browser, the operating system and possible a proxy. Clearing these between each test may help a little, but what of the caches located up-stream that we have no control over?

Compensating for DNS

Every tool we’ve seen for measuring website speed separates the retrieval of files into several stages, one of which is the time taken to process the DNS query. It’s possible to subtract these values from the overall retrieval time but if you’re doing in-depth analysis of page load then there may be two, three or more domains being accessed. It soon becomes unmanageable to carry these calculations forward through dependencies and blocking.

Eliminating It Altogether

Enter our saviour in this situation – the “hosts” file. A hosts file exists as an override to the DNS system. It is a tab-separated list of domains names and corresponding IP addresses. When doing any sort of performance work, we can manipulate the hosts file so DNS lookups are not performed at all. Instead, information is retrieved from our local filesystem – a task that won’t vary by much more than a few microseconds between tests.

Unix, Linux and Mac system are pretty standard and keep the hosts file under /etc/hosts or /etc/HOSTS. Hosts files on Windows vary depending on the version being run.

DNS Speed

Of course, this is not to say that you shouldn’t test your DNS speed as well. Many companies never move their domains away from the budget registrars they started with, so DNS can be a big contributor to slow-loading sites. Just try to test one thing at a time.

Getting the Source

As Silex draws on part of the Symfony framework, there’s quite a lot of source code to get down and into the right places. It uses git’s submodules system to pull in various other repositories that it requires. If you download our compiled Silex Phar file, you can pick up at the “Sample Application” step.

If you’re running one of the latest versions of git, you can use the “–resursive” option to sort the submodules out, but it’s more likely that you’ll need to take a couple of extra steps:

git clone https://github.com/fabpot/Silex.git
cd Silex
git submodules init
git submodules update

To compile to a Phar file, run the following:

php Silex/compile

If you run into problems at this stage you may need to alter a couple of the configuration options for Phar. Open up your “php.ini” file and make sure the following options are set:

phar.readonly = Off
phar.require_hash = Off

Sample Application

With the compile script run without any problems, we have an archive called “silex.phar” in the folder we were working from. We copy this file into the root of our web application and create an “index.php” to hold our code.

Silex makes it very simple to create a basic application through the use of simple REST-like functions and PHP 5.3′s closures (or anonymous functions). First, we set up Silex by including the autoloader, telling it that we’re using the namespaced Silex\Application class and then instantiating that class:

require 'phar://silex.phar/autoload.php';
use Silex\Application;
$app = new Application();

We can now start to configure the routes of our application, starting with a standard output for “/”, the document root. At the end of the script we call the application’s run method to kick things off.

$app->get('/', function() {
	return "Index Page";
});
$app->run();

Now if we visit “http://localhost/app/index.php”, we’ll see the message “Index Page” in the browser. The real flexibility comes when we use variables in our routing and in our closures. We add this code to our script before the application’s run method.

$app->get('/hello/{name}', function($name) {
	return 'Hello '.$name;
});

By creating a route with part of it surrounded by braces, we annex that part as a variable. This then gets passed into our function so it can be used like any other variable within a function. If we visit our application at “http://localhost/app/index.php/hello/Kryten”, we’ll see the message “Hello Kryten” in the browser.

Futher Reading

We love Silex so we’ll be featuring it a lot over the coming months as it matures. In the meantime, there’s the Silex page on GitHub and slides from this Silex presentation by Igor Wielder. Be careful though as some of the examples used in the presentation are no longer valid.

This could be seen as a surprising move considering Google’s views on website speed, but is it?

Claibourne assures those that use the Connection Speed reports “to understand the effect of page load time and latency” that they’re working on an alternative solution. But have people been able to glean any useful information from these reports?

Profiling visitors on connection speed does nothing to improve the speed of a website. We actually believe the opposite to be true. Consider a report that shows 80% of a sites’ visitors are on high-speed connections – does a designer take the decision to include a fancy graphic as 80% will be largely unaffected? Most likely yes, but this is flawed reasoning.

The crux of any design element – especially when there is a performance overhead – is whether or not it is necessary. If the graphic is necessary then it belongs there – if it’s not, remove it. If it is necessary, what’s the level of quality required? If an image looks fine at JPEG60 then you wouldn’t host it at JPEG100, regardless of how many visitors are on high-speed connections.

Reports like this go against the ideas of website optimization – they encourage those whose visitors are on fast connections to abuse those connections by adding unnecessary content to their sites. A site should never be slower that it needs to be, whatever your audience, and all this report has ever done is detail that audience.

Most frameworks have a templating system that simplifies theme design and obscures as much of the PHP code as possible. WordPress has no such system in place, so we’ve started to develop one for it. We’ve used the Twig templating system, a powerful system with a straightforward syntax.

We’ve started to expose the various parts of the WordPress system through the use of objects and arrays, allowing familiar control structures to be used in themes rather that WordPress’ own system of functions and conditionals. Here’s a simple WordPress loop to run through some posts, echoing links and titles, using the existing WordPress templating:

<?php if(have_posts()): while(have_posts()): the_post() ;?>
    <a href="<?php the_permalink(); ?>"><h2><?php the_title(); ?></h2></a>
    <p><?php the_excerpt(); ?></p>
<?php endwhile; endif; ?>

Here’s the same loop using Twig templates from within WordPress themes:

{% for post in posts %}
    <a href="{{ post.permalink }}"><h2>{{ post.title }}</h2></a>
    <p>{{ post.excerpt }}</p>
{% endfor %}

Looks a lot simpler doesn’t it? It is. Twig has a huge feature set that can be used in templating, with well though out control structures. See Twig for Designers for a no-nonsense rundown of what it can do.

We’ve recreated most of the WordPress TwentyTen theme using Twig, which is available on GitHub. It’s in it’s early stages and there’s still quite some work to do, but it’s certainly interesting code to look at. We’ve also got an object reference for WordPress templates up on the GitHub wiki to guide you if you are having a play.

Feel free to get in touch via Twitter @acleon with any questions or suggestions.

Download Twig for WordPress from GitHub

A CDN can be run in-house but more often it is handled by a large third-party hosting company. Good examples of CDN providers are Amazon or Edgecast. The disadvantage of CDNs is one of latency as content takes time to spread across the network. Without proper application design that takes this into consideration users can be requesting content that is not yet downloadable in their region

It would however be inefficient to index all the columns in a table as this would slow down the write speed. Every time a new row is created, or an existing one altered, the database server wold have to update the table as well as all the indexes. Usually only the columns most used in queries are indexed.

For example, the primary key may be 7 and there may be three shards. 7 % 3 = 1 (when seven is divided by three there is a remainder of one?) so this record would be stored on the first shard.

Sharding can boost performance dramatically but is heavily disadvantaged when writing complex queries as these may need to have aggregate results from multiple servers. Applications should be designed so that they shard across dimensions that don’t usual mix (e.g. Users of an e-mail system).