I often wondered how sites detected the number of users online. After some digging I’ll admit to be no closer to the answer. The problem is that once a page is delivered to someone you have no idea what they’re doing unless, and if, they then do something – go to another page of yours, click a button, etc. They could have immediately left the site and gone elsewhere… you simply don’t get back the level of interaction that would tell you this.

So my solution was based on simple maths. Using Google Analytics and the like I work out how long an average user spends looking at a page on the site. Let’s say it’s 90 seconds.

I’m using PHP and MySQL for this example. So, create a new table named users_online and create two fields for it – the first named timestamp and the second ip_address.

With your database already open execute the following PHP, pre-setting the variable $online_seconds with the figure we discussed a couple of sentences ago (in my example, 90). This should be at the top of each page.

$timestamp = time();
$timeout = $timestamp-$online_seconds;
$insert=mysql_query("INSERT INTO users_online VALUES('$timestamp','$REMOTE_ADDR')");
$delete=mysql_query("DELETE FROM users_online WHERE timestamp<'$timeout'");
$result=mysql_query("SELECT DISTINCT ip_address FROM users_online");
$user_num=mysql_num_rows($result);

This will add the period of time (90 seconds) to the current timestamp and insert a row into the table with that as a “timeout”. We then delete any rows where this timeour has now passed. Finally, we read the number of distinct IP addresses – this is the number of users currently online and is returned as $user_num.

How does this work? Well, the idea is that after 90 seconds if the user hasn’t moved onto another page or refreshed the current one then they’re gone. If they do, a new row with their IP address is created and they’re counted once more as still being active. Quite simple really. Possibly not the most accurate but without using host-side JavaScript, for instance, then I’m not sure how you would.

If nothing else it’s handy to have an idea as to how many people are online before you upgrade your site and potentially break it

Earlier this year I made the decision to stop updating the BMTG site as-and-when and more formally as packages. Yesterday I launched the 4th such package – Deoxys.

Unlike some of my other packages which have had more visible changes, this is more “back end”. Having said that, to me, it’s exciting stuff. The site is performing more caching and I’ve completely re-written most of the MySQL – it’s more efficient and protected against SQL injection (I hope).

There’s also detection of MySQL failures – when this happens a message bar appears at the top of each page indicating that a problem is occuring and that the site may be affected. The site pages are then designed to degrade gracefully – in other words, either cope with the lack of database access (easier for some pages) or simply display an appropriate message to indicate that no information is currently unavailable. In the past any database problems have simply lead to the site erroring and generally looking shabby.

Additionally, I’ve added some flags to the back-end database. These indicate either a major problem or that the site is undergoing maintenace – I can then flick these flags on when required and a message will appear on the site. The maintenance is particularly handy to turn on whilst I’m upgrading the site.

Lastly, and one of the few visible changes, I updated the member profiles – they’re a bit plainer than before but I think they work a lot more effectively now, as they’re less “fussy”.

Now I’ve started work on the Eevee package – I’ve already written the maintenance changes (including the width of the pages being increased, whilst still ensuring that a horizontal scrollbar doesn’t appear on 800 pixel wide monitors), but the main changes is to the online shop, which helps to generate some much-needed cash for the society.

Meantime, if you can guess (no looking on Wikipedia!) the naming convention I’m using then… you’re sad. Ok, that makes me sad too. And Catherine Furber, who also knew it.

I’m in the process, at the moment, of some interesting changes to the BMTG site. Instead of each show/concert page being individually written (with a few calls to scripts to display photos, etc) I’m creating a totally automated page generation system – simply tell it the show name, call the generator script and you get a show page out the other end. This includes the automatic detection of photos (just drag and drop a new photo into the appropriate folder and it then appears on the page) and the fetching of descriptions from the JPG data. Nice (if I do say so myself).

However, all of this has had an impact of server times. In the past I’ve not measured server times for performance monitoring, as they’ve been so insignificant. Now, I’m having to for the show pages. In fact the changes have pretty much negated recent performance improvements.

The next package, though, should help with this as I bring in some further performance improvements (including image caching and sorting out some shoddy MySQL programming of mine).

However, going forward (and I hate that expression), performance is something I will look at it with each package update.

After that there are packages due to SEO and Accessibility. So, they too will become part of the “standard” package check. Indeed, I have 4 things on my radar…

1. Accessibility
2. SEO
3. Security
4. Performance

Security, which will be tackled in the next package along with performance, is mainly around MySQL injection and the like – making the site as hacker-proof as possible.

It’s actually quite exciting as SEO and Accessibility is not something I’ve really concentrated on in the past, so I’m looking forward to the research and learning that will go with this.