Archive for November, 2006

Technical Stuff for AF

As those watching the SVN repository are aware, there have been a few changes going on outside the actual AF code. I’m going to run through these quickly.

For those not familiar with the repository layout, the distributable Astrum Futura source code is located (from the svn root) at /trunk/astrumfutura. Back to the topic at hand…

First of all, I’ve added a /documentation subdirectory in trunk. Documentation has always been a problem in QS and earlier in SE. For AF we’re considering a policy of making each developer who makes a change responsible for updating the documentation. How we enforce that is another matter I’ll discuss with my fellow developers.

Documentation is being written in the Docbook XML format and will be versioned in the mentioned documentation directory. To allow future scope for translation efforts, the actual files relevant for the default documentation are stored in /manual/en. The en directory contains a manual.xml file which is basically what determines the layout and contents. Individual pages are stored as separate XML documents in manual/en/module_specs. Common page components and miscellaneous appendixes are stored in manual/en/ref. The remaining directories and files allow the Docbook XML to be processed using xsltproc under linux (or Cygwin on Windows) to generate HTML. Options are open for using Apache fop to generate PDF (not really a concern right now). Directions for generating HTML are included in a README file in the /en subdirectory.

Secondly I have added a /standards subdirectory in trunk. The idea is to determine a final coding standard (see PEAR’s PHP_CodeSniffer) and ensure its adhered to. Might seem like a pretty worthless thing to be doing right now but once the code grows to a point where global file formatting changes are time consuming it will prove its worth. The standard being adopted is adapted largely from the PEAR standard. The main difference is that we’ve adopted a different bracing style (opening brace on new line) and modified a few rules to be either more PHP5 specific, or simply to match the preferred styles of the current developers.

Also added, but not yet utilised for AF specific code is /tests. Since most of the classes we use are already sourced from unit tested libraries like the Zend Framework, Swiftmailer and Quantum Star (that independent game library being segregated to a separate project) this will mainly hold web tests. AF will operate strictly on a REST basis, so all requests are in some way reproducible.

Next to be added (later today) is the /build directory. The core idea here is to automate building a distributable as much as possible. Distributing is often seen as a matter of export/copy/zip. In AF it’s a bit more complicated - we need to run all available tests (including all tests for libraries we are sourcing from non-stable sources like SVN trunk) including web tests, build and copy the documentation to its correct location, check the coding standard is clear of errors (ignore warnings), copy all files to a build directory in the correct locations, and finally create distributable archives for zip, gz and bz2. The distributable code must also be tagged in subversion.

I haven’t decided on a final build process and am currently trying out a few tools. The one I’ll be testing later is Phing (since it’s relatively famliar to an Apache ant user).

Did I miss anything? ;-)

Astrum Futura: Performance and Optimisation

I thought, as reference, I’d do up a post concerning performance and optimisation in Astrum Futura. Mainly to get my thought processes in text, and take a look at where performance is lacking.

The main driver of performance at the moment, in the absence of reems of game specific code is the Zend Framework. The ZF is currently reaching a v0.60 preview release in subversion (should be release next month) and an interesting discussion took place last week on the ZF mailing lists concerning this blog post by Paul M. Jones comparing four framework. In a simple minimalistic "Hello World!" application using each framework’s most minimum setup possible, and measuring requests per second (on a local PC), the ZF came last.

The main causes of this was the pure OOP approach. Each component has a few Exception classes, each in a separate files, which were loaded (as all ZF files are) using require_once(). Add to that the possible use of a static loading method which did weird and wonderful I/O filesystem checks and all that work created a major drag. That may be addressed properly in the future - until a 1.0 release the idea of optimisation is still largely considered premature optimisation. At least one small improvement was made - the use of Reflection has been largely removed from the many Controller classes. Reflection in PHP5 is nice, neat, and very expensive.

The Astrum Futura approach is to wait and see. Until then we’ve added an __autoload function, and are prepared to strip all instances of require_once() calls from files we distribute in a release. That in combination with autoloading would ease the burden a fair bit. A release is months away of course, so wait and see is the only reasonable stance right now.

Another future performance driver is the database. This gets interesting however, in that we can’t consider the database purely in isolation. By itself we can rely on a mix of query caching (on the few shared hosts who actually bother to check their MySQL configuration), the use of InnoDB and MEMORY (HEAP) storage solutions for tables (again MySQL), and the usual pretension that 4th level normalisation doesn’t exist ;-).

In AF, we also have to deal with how database results are handled. In general terms, an AJAX frontend does not typically rely on HTML input. Rather we receive responses in a strict data-only format such as XML or JSON. JSON in particular is the most useful since it’s Javascript’s native object notation. XML is more complex since it requires using Javascript’s DOM to manipulate. One of the focuses for near static data will be utilising caching extensively - not just server side, but also in the client. One of our main concerns, and one of the reasons we’re coding to PHP5.2, using MySQL more productively (no MyISAM crap here), and actively seeking ways of caching data, is the fact that the interface is AJAX enabled.

AJAX gives a nice warm fuzzy feeling when you see it in action. But if used extensively in the wrong way it can create a ton of problems. The simplest explanation is that AJAX should nearly always increase a user’s productivity - it’s not just eye candy ;-). The more productive they are, the fewer server requests they should need for a given task. The disadvantage is that you can easily wind up with a task which rather than taking one or two big page reloads to complete, takes a dozen or more small AJAX updates. If those small updates are slow, and add up to a larger request time and larger bandwidth takeup than the single big request you started with - then something went a bit wrong. Caching both on the server side, and especially on the client side reduces the number of small requests for static data. The fewer the better…

Now, if only these good intentions converted into reality in the near future…;-)