We came under attack

26 09 2007

Weird anonymous vandals came and vandalised random articles, even a template or two, wth strings of silly characters.

I could quite cheerfully  vandalise them back.

We’ll solve it with a bot soon.  But, until then, we’ve locked the articles against unregistered users trying to edit



We need a week’s more data

14 03 2007

We have been tuning and tuning the site and software, and we’re pretty much tuned to the hilt as far as our current server goes. We need another week’s worth of data points to be sure of the class of server we migrate to when we migrate, but we know we’ll outstay our welcome on the server we share at present.

That’s the thing, you see. We share a server, and the mediawiki software is a huge eater of resources. Now, while the share of resources we have is limited by the environment we live in, shared servers work by selling the same resource several times over, on the basis that no individual site will use its share to the full.

We’re using our share to the full. It’s hardly surprising, because, between the two main wikis that are live currently we have over fifteen thousand pages in the database, and we’re serving and storing some large pictures.

So we’re gathering data about performance, we’re benchmarking on an offline server to see how performance enhancements relate to a dedicated server instead of a shared one, and we’re looking at the balance sheet to make sure we take a server that is within the advertising revenue that funds the sites.

We’re set to move in a few weeks, and we think performance, since it is on a par with Wikipedia at present, is acceptable for that timeframe. But it isn’t wonderful, and we’re aiming higher.



Of servers and speed and stuff

9 03 2007

We’re getting there.  That is to say we are understanding the environment we’re using better.  We don’t normally go for virtual private servers, we prefer dedicated machines, but, at the start of a project, we cut our coat to suit our cloth, and we happened to have a shedload of space on a VPS and so used it.

What appears to be happening is that our VPS is often very idle, but the VPS itself gets swapped out of RAM onto disk fairly often.  And we’re told that the Virtuozzo environment we’re inside is not very good at optimising disk I/O, so we are “disk bound”, which is very much like constipation

We currently have “half a VPS” with our ISP and performance is back to the standard it was earlier this week.  We’re a but “chunky” to mount on a server.  Wikimedia software is not gentle, but we have enough grunt for now.

We’re looking at tuning our environment, probably over the weekend, since most spotters are out spotting at weekends.  I say “we”.  I sit and watch while Bernd does that stuff.  He knows what he’s doing and I just marvel.



Cautiously optimistic about server problems

7 03 2007

We’ve been granted a less troubled server by our ISP. Initial reaction is that we are back to a reasonable speed again. However some time must elapse before we are sure.

Meanwhile the initial upload to stock the Plane Spotting World site continues



Trials and tribulations

7 03 2007

Over the past 48 hours, Bernd and I have been tearing our hair out.  To give you an idea what goes on when we launch a new area like Plane Spotting World, we:

  • Deploy a brand new wiki
  • Populate it with a set of templates and policies and other central items
  • Choose the initial articles we load from other sources
  • Announce it

This time all hell has broken loose, but slowly!  Our ISP is having serious and coincidental issues in providing the service.  They seem to be having disk I/O problems and those are causing very slow page load times.

So far all I can do is apologise.  We’re giving them time to fix the problems and are looking for alternative servers so we can move fast if we need to. and they cannot do it.  As you can imagine we are seeking to hold them to their service level agreements.