The astonishing power of modern computing

Being very old (or at least, that’s how I feel being in tech!) means that after coming up to nearly forty years in technology, I’ve seen some changes.

My first computer at home, that I owned, that I could truly call my own, was a Dragon 32. It was a small, 32KB computer using the rather lovely little 6809 processor. This CPU ran at 2MHz and the system as a whole allowed me to learn a heck of a lot about computer science as a geeky teenager who was busy ignoring sports.

It didn’t exactly prepare me for my first coding job, working on an IBM MVS mainframe computer handling the payroll of 70,000 people, and distributing over £1bn a year. In fact, it prepared me terribly, because mainframes back then were similar to desktop computers today – powerful, with a ton of security features, online storage and a lot of data pipelines. But still, I knew various algorithms, knew what compilers were (though I’d only used an assembler really, but it got me half way there) and how to do a lot with a little.

That mainframe, when I started, could do about two hundred megaflops.

And today, in the picture above, I have an M5Stack on my desk. It uses the Xtensa LX7 processor. As you can see from the picture it’s absolutely tiny. And it can handle the integrated digital camera, WiFi, Bluetooth, USB… everything, really. The little CPU can run at low speeds and high speeds as appropriate to workload, and can reach over 1GHz.

Let’s put things into perspective.

The 6809 was addressing 32KB. The S3 Stack has 16MB of Flash and 8MB RAM. So 750 times the onboard storage of my Dragon 32. You can insert a 16GB microSD Card. You could put 200KB onto a C60 cassette tape back then. So that’s 80,000 times the unloadable storage! Running a lot faster too.

In terms of CPU performance, I’m struggling to find comparable benchmarks, but if we look at a 6809 you used to get 2-3 clock cycles per simple instruction – so you’d max out at around one million per second. Complex instructions would be far worse, and moving memory around was slow and expensive. The LX7 seems to get through around 0.8 instructions per clock cycle, so we can see it can max out at over a billion instructions per second. Or at least a couple of thousand times faster than the 6809.

But here’s the thing… the little computer I’m holding in my hand is at least as capable as the  contents of the data centre I started to work at in 1987.

And that, my friends, is why I feel very very old in this sector! Things have changed so much.

Yet at the same time, they haven’t. UX didn’t have a name back then, but careful thought into the design of a screen could save people a huge amount of time or reduce data errors. Saving CPU cycles then meant less of a bill (we paid by CPU time on mainframes) and could save tens of thousands a year for our team. Today, it may feel as if the CPUs are endlessly powerful, but using lower power techniques can dramatically cut down on resource use – meaning less environmental damage. I know at work we’ve taken systems running on 32GB, top spec web servers down to 512MB machines! It’s incredibly satisfying to reduce resource consumption by so much.

Let’s look at it another way. The sophisticated corporate payroll, for 70,000 people that I worked on in the eighties and nineties could easily be run today, if suitably considered, on the tiny little computer I’m holding in my hand here.

Which leads me to the real point of this piece – we as software engineers and designers have a duty to minimise resource usage. Yes, that enormous library you’ve included in your project might save you an hour of time today, but if it increases the memory and power consumption of your system so much that you need loads of cloud computing to support your system then it’s not a job well done – it’s a kludge you can hide. We have an ethical imperative to do better in systems development.

Also, low power computing is awesome and fun. Try it!

Bye Bye Skoda

It’s always sad when you decide to get rid of a car that you’ve enjoyed owning.  Not because it’s no good, but because your needs have changed.  And the biggest problem was that we’re now parents to one growing toddler and another relatively new baby.

Which nearly did my back in.  Both the Skoda and the Audi are relatively low cars, and as I have a weak back as it is, this proved too much and I recently found myself barely able to move for a weekend.  Not good.  I decided it was time to find a taller car.

So, with a heavy heart, I’m selling my 77,000 mile late 2004 Skoda Octavia vRS.  As you might expect from me, it’s been well looked after, has a full service history and no expense has been spared in its maintenance.  It’s a cracking car with great performance, handling and pretty good refinement.

I’ll let the pictures do the rest of the talking.  If you’re interested, drop me a line in the comments below.  I’ll be adding a contact number on here shortly once the Telesafe number’s come through.

Price? Just £3100 – a lot of car for little money.  I’ll be sad to see it go.

Getting Quicker

One of the most important things that gets forgotten about when running a WP site is that performance is important.  We see many sites with page load times way in excess of 2,000ms per page.  Often the site just gets progressively slower over time and the change isn’t really noticed.  That had happened with mine, though I’d made tweaks in the past to help, I still wasn’t happy.

This is bad, especially now that Google rewards speedy load times with higher rankings.

So I knew that the increasingly sluggish performance of my site was an issue.  The crud had built up, and in rebooting I hoped to dramatically improve responsiveness.

And I did:

It’ll be interesting to see the impact of this over time, but I’m pleased with the results so far.

An interesting graph of site performance over the past few years:

As you can see – the performance early last year got particularly bad.

It’s worth noting that I don’t run any caching or CDN on this site – it’s never that busy to be worth the work.

I’m hoping that I can now keep responsiveness down to <700ms average.

One lesson I hope you do take away from this is the importance of continuously monitoring your site’s responsiveness by using a service such as Pingdom.com.

Blog “Reboot”

Hello – here’s the refreshed blog. I’ve decided to revert to a more typical blog format, after many months of soul searching on the issue. I previously had a layout based on a framework we used at interconnect/it for a couple of clients

But not only have I opted to switch to a blog layout, I’ve decided to use an off-the-shelf theme.  I’m now using Khoi Vinh‘s Basic Maths WordPress theme.

Why?

Well, it’s a lovely theme, for starters.  The typography is pretty good.  The archives page is brilliant (check it out) and should be the standard bearer for all themes archive pages.

But the real question for many, I suspect, is why I’m not using an interconnect/it designed theme.  Well, for starters, interconnect/it hasn’t produced an off-the-shelf theme in years.  It’s just not our business.  So rather than use a product of ours, we’d have to spend good and valuable time on creating a new theme.  And, well, why would we want to do that?

Lots of reasons, actually.  I could have a theme coded at the office that really shows off what we can do.  But the problem with that is that there’s not much need.  My blog is not an important one.  It isn’t about WordPress (most WP related content will be on our company site, not my personal one) and it just doesn’t get much traffic.

I run a business.  Its purpose is to make money, employ five people, and, with a bit of luck, turn a reasonable profit.  Its job is not to service my ego or make me look good.  A really good theme costs the equivalent of around £10k-£20k of chargeable time to design, code, test and implement.

Given that we’re turning work away, I thought “why bother?”  And decided to go shopping for something.

So What’s It Like?

It’s actually quite weird using somebody else’s theme.  I actually tried a few out and here are the things I learned that will hold us in good stead.

Themes don’t do enough to make life easy.

No really, they don’t.  One of interconnect/it’s biggest challenges is making sure that WP is as easy to use for clients as possible.  This means following standards, but it also means using some little tricks that help out – for example, registering and setting plenty of different image sizes, and setting/over-ruling whatever the media settings say.

Migrating WP content really sucks.

There’s a fundamental flaw with the default WP export/import.  If you have inline images, although the importer has the ability to download and attach the image in your new site it won’t change the links.  And if you do a search and replace, and your image sizes have changes, your lost.  Totally – the img tag will point to a file that doesn’t exist.

So what do you do?  Well, usually if I’m moving a site from one server to another, even switching domains, it’s a non-issue.  I have my tools.  But if you’re starting from fresh and working like an end-user would then you have to go through every single damn post in order to fix the images.  Every post with an image in it.  That’ll take a while.

If you’re really geeky, you’ll sort it, but it takes time.  Way too much time.  This kind of stuff needs to be sorted and it’s something we may look into as a contribution to the WP project.

Some Plugins Leave Lots of Crud

The reason for a reboot was that I felt that my site’s DB had been filled up with all sorts of crud.  Lots of plugins create tables, leave options, and so on.  Surplus tables have little impact, but they clutter the place up.  But options, lots and lots of them, do have a minor performance hit, and they add up.

Other plugins leave hooks, don’t deactivate properly and so on.  And over the years, I’d been through an awful lot of plugins.  The site hadn’t been redone since WP 2.0 had been set up on it.  I felt it was getting sluggish.

So… there are beautiful and amazing themes out there, and WP is wonderful, but there are little things that could make life just that bit better.  Better migration tools, a better system of managing images within content and their migration, and a better system for activating themes so that image sizes are better handled.

Is it a lot to ask?  Well, we’ll see what we can do about that!

WordPress Performance, Make it 3x Quicker!

I’d started to notice that my site could often be slow to load – other sites on the same server weren’t suffering the same way, so I wanted to document a simple way in which one can identify performance issues on the site. This is one of them.

A little while ago I reported that my site, since some WordPress upgrades, had started to slow down. I’d wondered whether it was WP becoming increasingly bloated, or some other problem.

Well, it took me a while to get back to the issue (babies and a booming business don’t help!) it’s continued to get worse and worse, until a recent change has improved things… but only marginally, as shown by the Pingdom chart below:

Not looking good…

This is dreadful, really – daily average of 4,000ms responses just aren’t acceptable where, two years ago, I was getting 800ms.

So, now the process starts.  The recent small improvement came after installing our Spectacu.la Advanced Search Plugin, which runs a regular database optimisation to help keep things nippy, but it was still dreadful.

Is it Pluginitis?

My first suspicion is always that of plugins (and sometimes themes, if they’re complex).  In our office we have a term called ‘pluginitis’ which refers to the problem of a site having too many plugins installed, many of which are poorly written.  I hate to say it, but when clients call to ask for a plugin to be installed that we’ve never tested we go through it and, 90% of the time, discover serious performance or security flaws that will cause long-term issues.

And this site here is old – I’ve been running a WP install for four and a half years with nothing more than upgrades and, like an old PC that’s been upgraded too many times, that causes issues with old drivers and code.  Same can apply to WordPress.  So let’s see what we can do to improve things.

First stage is to disable as many plugins as possible so as to isolate the issue.  I’m using a division based approach – ie, I’m going to disable half of my plugins to see what happens.  If I get full performance back, then the problem lies in that half.  I can then reactivate half the plugins and see what happens.  If the performance is still good, the problem is in the other half.  I think you can see where I’m going here.

I’m also going to go for plugins that aren’t written by us. Not because I’m biased (ok, maybe a little) but because I know all of ours are carefully tested for performance – many are run on major sites such as the Telegraphs blogs site.  Speed is of the essence.

I’m also going to skip plugins like Akismet, because anything that’s essentially ‘core’ is usually going to be reasonably performant – at least on a small site like this one.

It’s worth noting that I could easily delve into SQL statements and code efficiency – but that’s only interesting to developers – if you’re simply a WordPress user, performance is interesting but what you can do to find problems is somewhat more limiting.

Plugins being disabled:

Add to feed – a simple plugin, but sometimes simple plugins miss simple tricks.

Headspace2 – I have my suspicions about this plugin as it’s massive. Could be fine, may not be.  Only way definite way to know – measure it.

Search Meter – a nice plugin to see what people are searching for, but is it adding load somewhere?

Social Bookmarks – it shouldn’t cause issues, but you can never be sure.

wp-typography – I love what it does for the typography on the site, but it’s also running a lot of javascript.

First results:

I do use YSlow to test the site, but one of the problems is that it’s hard to get a large enough series of data to be statistically relevant.  It’s good for seeing the extra load (and why I knew the amount of javascript was an issue) but for longer term analysis it’s flawed.

So, we go back to Pingdom and look at the one day chart.  As I type this it’s now an hour since disabling the plugins above – so let’s see what’s happened:

A dramatic improvement!

As you can see, in this afternoon alone there’s been a dramatic improvement – from around 2500ms per visit to 1230ms per visit.  In one single step I’ve halved the load time of the page.

What we don’t know so far is whether that’s because the page got smaller to load or whether it’s down to a reduction in database load – but that’s really for another article.  What this is all about is trying to document how I’m improving the responsiveness of the site in a way which relatively non-technical folk can follow.

What I’ll do in the next feature is to turn off some more plugins to measure the impact they had.  I’ll also be interested to see if the spikeyness of the response times has varied much – are they caused by simple server load, or is there something else at play?

I will then start to switch plugins on again in a structured way in order to measure which was causing the heaviest loads on the site.

Keep watching!

Is WordPress Slowing My Site Down?

I noticed on my pingdom stats recently that this site has been slowing down recently. But why? Is it WordPress? Some plugins? Time for research!

I don’t really look at server response times too much, because generally it’s a bit dull, really.  If our server is really sick then the automatic alerts and text messages from Pingdom tell me to get fixing.

Anyway, tonight I just thought I’d have a look at some graphs.  And hey, there’s a bit of a shock… my own site, this one here, is getting slower.  Here’s the graph:

 

Now, what you’ll notice is that generally everything looked nice and brisk until early August 2009 when there was a marked deterioration in performance.  Then it plodded along just fine until December 2009 when it got worse again.

Is It WordPress Bloat?

I wondered what had happened to cause this – I’m especially shocked that a page load is now so slow.  I haven’t changed the theme in use for at least a year, and the plugins are generally ones I use elsewhere.  So I did a bit of thinking, and then it dawned on me when I found this list of release dates at WordPress.org:

The dates correlate exactly with the worsening performance of this site.

Now, correlation absolutely does not relate to causality.  At upgrade time I usually take a moment to review plugins, upgrade the theme, etc.  It could be that an upgrade or change to one of the many plugins in use here that has caused the slowdown.  I know it’s not traffic to my site – that’s been flat for ages, with only the occasional blip.  The server is a dedicated machine running about fourty sites that we manage, but the load is generally quite consistent and impact on different websites is fairly well managed.

But I’m a speed freak.  I like it when a website zings into view.  I love fast cars.  I love computers that don’t dither.  I love telephones that respond instantly.  So I hate that response times are now below 1s.  That’s not on!

So I’m going to try to find the cause of this slowdown – I’ll be running some experiments on this site, profiling queries, checking the database over and so on.  And I’ll document it all as a way of showing you how we at Interconnect IT do our performance tuning.  Whether I document it here or there I haven’t decided yet – I think it would make a good case study for the site.  We’ll see!  Watch both sites…

note 1 – deactivated Twitme on 03/02/2010