So, Fire­fox 3.6 is finally here, and on aver­age it’s 20% faster than 3.5. It’s actu­ally a really notice­able improve­ment for both ren­der­ing and scrolling around pages; I’d say it’s more or less on a par with Safari on most pages. I hear from Win­dows using friends that it’s sim­il­arly quicker on that plat­form too, approach­ing the speed of Chrome, in places. All of which makes this a little odd.

I noticed, not long after the upgrade that my blog (this page, unless you’re read­ing a syn­dic­ated copy,) was scrolling really, really slowly in Fire­fox, which it had never done before I upgraded. I checked it in Safari to reas­sure myself that it wasn’t some­thing wrong with the site, and everything was fine; scrolling was smooth and respons­ive just like it has always been. I checked Fire­fox 3.5 on my mac­book; same thing. I dis­abled all my fire­fox addons and tried again on the desktop: still pain­fully slow. So I re-​​enabled some of them and star­ted mess­ing around with fire­bug, dis­abling vari­ous style ele­ments to see if I could fig­ure out where the slow­down was com­ing from.

It didn’t take me long to find the cul­prit: shad­ows. I try to avoid using images in my pages as much as pos­sible to improve page load speed, so I use box-​​shadows to give a bit of depth to the wid­get box-​​outs; they look even more flat and drab without them. I also find that a subtle text-​​shadow is a great way to increase text con­trast without mak­ing the page harder on the eyes, which is a big deal for any light-​​on-​​dark dis­play (at least until someone intro­duces a decent super-​​light web­safe font,) so I make heavy use of that too. None of this has ever had any notice­able per­form­ance impact before, but here we are; with the new, optim­ised, gecko engine it renders like arse.

I thought per­haps there was some­thing else about my CSS that was con­fus­ing the ren­der­ing engine — it’s hardly the most min­imal or eleg­ant set of style defin­i­tions in the world — so I knocked together this abuse of text-​​shadow to prove that it’s the prob­lem. As expec­ted, it renders fine in Safari and older Fire­foxes, but incred­ibly slowly in Fire­fox 3.6, so it’s def­in­itely some­thing to do with the new browser.

Next check was to see if it affects FF3.6 on other plat­forms, so I fired up my Win­tendo, upgraded Fire­fox and tried the page. No slow­down. I don’t know how rep­res­ent­at­ive that is though; that box is a quad-​​core 3GHz Nehalem with 6GB of RAM and a GTX295 in it; it’s got about twice the graph­ics oomph of my Mac (which is a 3GHz Core2 Duo with an 8800GS), and I don’t have a slower win­dows box to test on. So this is a bit incon­clus­ive; I can’t really det­mine whether the issue is con­fined to the Mac ver­sion of Fire­fox, or to Fire­fox on machines that can’t run Crysis at 60fps. But, hon­estly, I don’t think it matters.

Long story short; my site renders really slowly on the latest, greatest ver­sion of Fire­fox, which is an issue. I make no bones about the fact that I don’t give a monkey’s how it renders in IE, but I do like to make sure it gives a good exper­i­ence in decent browsers, which by my defin­i­tion means any­thing web­kit or gecko based. Fire­fox is by far the most pop­u­lar browser in that cat­egory, so I can’t just ignore this. The ques­tion is what to do?

I can sit around and hope that 3.61 fixes the prob­lem, but that is basic­ally just ignor­ing it, tak­ing no respons­ib­il­ity, and means that my site sucks until someone else fixes their browser, which might never happen.

Or I can reskin the whole site such that it looks OK (or at least as OK as it looks now) without rely­ing on shad­ows. The prob­lem is, I’m not a web designer, so that’ll take me ages, and I only just got the place look­ing how I want with this design. It’ll also, inev­it­ably, mean mov­ing back towards the bad old way of doing things, using back­ground PNGs to try to give the site any sense depth or char­ac­ter, and I really don’t want to do that; I want to be able to use stylesheets to define the style of my page, not rely on image-​​based work­arounds. Admit­ting that I need those work­arounds feels like giv­ing up. Maybe the state of browser tech­no­logy just isn’t up to that out­look yet.

Basic­ally, I see no entirely sat­is­fact­ory way out of this situ­ation; I’m just going to have to decide which solu­tion is the least unsat­is­fact­ory. I’m going to have to give it some thought.

Tonight I upgraded the Word­press install on the site to ver­sion 2.8, res­ul­ted in about half-an-hour’s down­time while I untangled some merge con­flicts the svn update to 2.8 com­bined with a move to the new Word­press core svn server cre­ated. Inter­est­ingly the pro­cess went fine on my test server, but not on live; I’ll have to look into that. Any­way, apo­lo­gies for any incon­veni­ence the down­time may have caused you.

The 2.8 upgrade itself is almost entirely back-​​end, admin stuff, and shouldn’t have any impact on the vis­ible site at all.

A few months back, I quietly added gravatar sup­port to the site for com­menters. I didn’t men­tion it, as I (appar­ently incor­rectly) assumed almost every­one had a gravatar.

Since that’s turned out not to be the case, I’ve installed the excel­lent WP-​​monsterID plu­gin to gen­er­ate avatars for those com­menters that don’t have one. It’s really quite clever: it takes a hash of the commenter’s email address and uses some of it as a seed for a pro­ced­ur­ally gen­er­ated mon­ster. There are mil­lions of pos­sible com­bin­a­tions, and as long as you keep using the same email address in your com­ments, you’ll always get the same mon­ster. An even cooler side effect is that, you’ll take that mon­ster with you to any other site that uses the same (sort-​​of-​​standard-​​ish) monster-​​generation code.

Of course, if you cre­ate your­self a gravatar, that will over­ride your mon­ster avatar, as well as appear­ing on all of the many sites around the net with gravatar support.

If you’ve com­men­ted here before, you can check back to the old posts, to see what your mon­ster looks like. If you haven’t; feel free to com­ment on this post, for an example.

I just switched the site to route sub­scrip­tions through feed­burner (mainly out of interest.) It should be pretty seam­less, but if you find your feed has repeated entries or any­thing, that’ll be why; it shouldn’t persist.

If you’re both obser­v­ant and one of the rare people that actu­ally vis­its the site, rather than just read­ing via RSS, you might have noticed that I’ve decided to exper­i­ment with Twit­ter. My user­name is Aggro­Boy, and you should be able to see my updates in all the usual twit­ter ways. Or you can just look at them there on the sidebar.

Why Twit­ter? Well, it’s a bit more imme­di­ate than reg­u­lar blog­ging, and should allow me to just throw ran­dom thoughts or things that have happened to me on the spur of the moment, rather than hav­ing to wait and com­pose a full blog post about it, which almost never hap­pens. Of course the worry is that more or less exactly noth­ing ever hap­pens in my life, so my twit­ter feed runs the risk of being either empty or mind-​​destroyingly bor­ing. And that’s why it’s an exper­i­ment; I’ll give it a couple of months and see if I’m actu­ally using it, and if I’m happy with it. If I am then I’ll keep at it, if not it gets releg­ated to the recycle bin.

Obvi­ously, I’ll keep updat­ing the main blog with the things I want to express elo­quently (well, as elo­quently as I can,) or at length; the intent is that twit­ter con­tains an entirely dif­fer­ent kind of information.

You should now be able to edit your com­ments for half an hour after sub­mis­sion. I had a bit of trouble get­ting it work­ing along­side the com­ment sub­scrip­tions, but I think I’ve got it sor­ted now. It all worked in my tests anyway.

Let me know if you have any trouble with com­ment­ing, or not being noti­fied with your subscriptions.

Those of you who don’t read this through an aggreg­ator will have noticed that I’ve got a new theme on the site; and those of you who do might want to actu­ally visit the site briefly to check it out. It’s called Red Wave, and it’s designed by Askgraph­ics (there’s a link at the bot­tom of every page,) who seem to have done a bang up job of it. They had a couple of other nice look­ing ones on their site, but one of them was blue (which just so main­stream,) and the other had a couple of weird ren­der­ing arti­facts, so this was the one I went with.

This was a pretty hard thing for me to do, since I’d always inten­ded to put my own theme together, but it’s about time I admit­ted to myself that that isn’t going to hap­pen (I’m a good pro­gram­mer and a pass­able writer, but my web-​​site design skills are sorely lack­ing,) and it’s bet­ter to bite the bul­let now, face facts and get myself a look that isn’t the same as every other word­press blog on the net.

So, what do you all think of the new look? Bet­ter? Worse? Don’t care?

The obser­v­ant amongst you will have noticed that I went for option 3. MT was just not doing what I needed it to, and when I installed Word­press in par­al­lel to trial it, it did everything I need more or less without fail.

It’s taken me a couple of days to trans­ition (which, com­bined with a new job, is why the blog has been quiet,) but I’m there now, and shouldn’t be chan­ging again¹. Expect the blog to be back to normal(ish) levels of posting.

1. Until the next big thing comes along. [↩]

About a month ago, I upgraded the blog to run on the new release of Mov­able Type: 4.0. It has a nicer inter­face, plenty of neat fea­tures out of the box (without hav­ing to man­age a host of plu­gins) and fea­tures some handy improve­ments to the tem­plate lan­guage it uses to build pages. It deliv­ers on everything it prom­ised, and in all, I’d call it a good upgrade over the ven­er­able ver­sion 3, which I had been using. Of course this is tech­no­logy and there are no abso­lutes, and MT4 has some ser­i­ous gotchas, which I’m hav­ing a vary­ing degree of suc­cess work­ing around.

The first thing I noticed when I upgraded was all those improve­ments to the tem­plate lan­guage made my exist­ing tem­plates obsol­ete. This one’s not a deal-​​breaker; I just picked my favour­ite stock theme and ran with it; I can change it later. In fact, you could call this a win, since my exist­ing tem­plates were a mess, and had been hacked together before I really knew what I was doing; this is a chance to make a clean start — isn’t that what every developer always wants?

Slightly more ser­i­ously many of the well known and pop­u­lar com­munity plu­gins don’t work with MT4 — they’ve changed the way cer­tain things work, and that means trouble for any plu­gin that relied on things hap­pen­ing the old way. The big loss is the blogroll plu­gin. There’s an upgrade to the plu­gin on the way, and I can live without it for a while, I just wish I didn’t have to. Actu­ally, I’m not sure why SixA­part haven’t rolled that par­tic­u­lar plu­gin into the main dis­tri­bu­tion yet. Many of the new fea­tures present in MT4 are actu­ally just plu­gins that have been made part of the default dis­tri­bu­tion, so why not some­thing so widely used as the blogroll plu­gin? Beats me.

Of course, if all of the prob­lems were little issues like that, which will go away with a bit of time and/​or effort, I wouldn’t even be writ­ing this. There’s a great big chunking prob­lem that is actu­ally start­ing to make me regret going with MT: performance.

MT4 is slow, and when I say slow, I mean really slow. It pre-​​generates the site (the much maligned re-​​building step you’ll hear the Word­press users going on about,) so the user facing side of the site remains nice and quick, but the admin­is­trat­ive inter­face feels like it’s run­ning on a ZX-​​81. When I first installed the MT4 upgrade, the dash­board took about 6 seconds to load, com­pared to well under a second for any of the gen­er­ated pages, so I know it’s the MT backend cgi scripts that are at fault, rather than my web­server or the net­work infra­struc­ture between here and my host. Installing mem­cached and mov­ing my vir­tual server to a much faster machine have made a notice­able dif­fer­ence, but it’s still tak­ing 3 – 4 seconds to load any of the admin­is­trat­ive pages, and when you’ve got a few things to do that gets really annoy­ing, really quickly.

Enter Fast­CGI. This is an apache exten­sion that keeps the perl runtime and com­piled perl code of cgi scripts in memory, drastic­ally redu­cing the start-​​up time of those scripts. Cre­at­ing and start­ing a new pro­cess is a rel­at­ively time con­sum­ing oper­a­tion, and com­pil­ing the perl code takes time too, so tak­ing those two actions out of the star­tup of a cgi script can have a dra­matic effect on the time taken to serve requests. I’ve tri­alled this, and it makes a huge dif­fer­ence: com­bined with mem­cached to cache the data­base con­nec­tion, it makes the admin pages run about as quickly as the static pages. That’s impress­ive, but it comes with a cost.

Because Fast­CGI keeps CGI scripts in memory between runs, any memory that they alloc­ate stays alloc­ated too. That’s not a prob­lem in the nor­mal case, but it means that if your CGI script has a memory leak, that the leaked memory is lost for the dur­a­tion of the Fast­CGI ses­sion (which is usu­ally a couple of hours, at least,) and worse, is lost again every time the script is executed.

Pre­dict­ably enough, MT4 has a memory leak. It seems to lose about a mega­byte of memory every time it’s called under Fast­CGI, which isn’t a massive pro­por­tion of my server’s total memory, but it’s a lot to just lose while gen­er­at­ing a web page to dis­play, and it does add up. Unless it’s peri­od­ic­ally freed, I’m going to run out of memory even­tu­ally — after about 1,000 admin­is­trat­ive page views.

So, what can I do? There are three options, none of them ideal:

Live with the delay

It’s a real pos­sib­il­ity. The user-​​facing side of the site runs fine, and I’m not going to actu­ally die for want of a few seconds lost load­ing a web page. It doesn’t sit well with my geeky nature though, espe­cially since play­ing around with Fast­CGI has proved that there’s no need for the pages to be so slow.

Fix MT

I’m sure I could — even­tu­ally — track down the memory leak and remove it, and pos­sibly even get the fix put back into the main­line of MT. The ques­tion is how long it’s going to take and how much effort it will be. Also, if the fix doesn’t find it’s way back into SixApart’s code-​​base them I’m stuck hav­ing to hack every upgrade release in the same way, which sounds like a night­mare to me.

Dump MT

A bit extreme per­haps, but it would avoid the prob­lem. Everything I’ve read sug­gests that Word­press (the obvi­ous other can­did­ate) doesn’t have per­form­ance issues. I’m reluct­ant to take this step now (although if I was set­ting up from scratch, know­ing what I know now, I’d use it over MT,) simply because I have a lot inves­ted in MT; I know how to use it, I’ve got it con­figured, and it lets me edit my posts in Mark­Down, which my googling has sug­ges­ted doesn’t work so well in Word­press. So I don’t want to change, but if I can’t fix MT, and I can’t live with the annoy­ance, it might yet come to it.

Yes, I’m still alive, and yes I’m still blogging.

It’s been a bit quiet for the past few days because I’ve been sort­ing out some server issues. Basic­ally, my host ran out of memory on Fri­day morn­ing, and I’ve been get­ting it upgraded and try­ing to sort out some of the memory use and per­form­ance issues since then. It’s noth­ing par­tic­u­larly huge, but it’s taken all of my non-​​work/​non-​​gaming time. All the soft­ware work is now done, but there’s a server migra­tion still to hap­pen, that’ll come up when my host­ing com­pany (the excel­lent RimuHost­ing can sort out some trouble they’re hav­ing with broken Intel BIOSs. But since that’s almost entirely man­aged by them, it shouldn’t take any more time out of my blogging.

While I was at it, I installed a couple of plu­gins for Mov­able Type 4, which should give quite a bit more flex­ib­il­ity in how you sign in while com­ment­ing. Not that any­one ever does.

Next Page »