First, let’s discuss what’s suboptimal with the previously described approach. The basic idea was to provide a custom Chef recipe which is executed on our instances whenever our Symfony2 application gets deployed. This recipe took care of

• executing the tasks which need to be done whenever the application is deployed, like installing the Symfony2 vendors or cleaning the application cache
• configuring Apache to correctly serve the application

Well, the problem is that these are really two very different tasks which shouldn’t be mixed together.
Updating the web server configuration every time you release a new version of your application simply doesn’t make sense.

Thanks to Chef deployment hooks, we can separate these tasks. Whatever needs to be done upon application deployment can be provided within the application itself, making it much more self-contained. This way, application business logic and application deployment logic live in the same source tree.

On the other hand, system configuration steps which aren’t specific to deploying a new version of your application, but are specific to hosting your application in a given system context, shouldn’t be bundled with your application, but with your system context.

Thus, we are going to separate the deployment recipes and the system setup recipes. We will provide the deploy recipes from our application, and the system setup recipes through a custom Chef cookbook, just as we did in the first version of this tutorial.

Let’s look at the old version of our deploy.rb recipe, and decide which parts are related to the deployment of our application, and which parts are related to hosting our application.

Well, it’s actually quite simple – everything from the beginning of the file through line 44 is stuff that needs to be done upon every single deployment, or else we wouldn’t end up with a working application.

Let’s move this part of the deployment recipe into our application. Where does it belong? When Scalarium’s Chef deploys our application, it looks for certain scripts in the /deploy directory of our application:

• /deploy/before_migrate.rb
• /deploy/before_symlink.rb
• /deploy/before_restart.rb
• /deploy/after_restart.rb

As their names imply, these scripts are triggered at certain points of the deployment lifecycle. They are closely related to the steps that are necessary when deploying Ruby on Rails applications, and thus not all of them are useful for us when deploying a Symfony2 application.

For the steps we want to execute with our recipe (installing the vendors, clearing the app cache, executing db migrations, installing the assets, and chowning app cache and log dirs), the before_symlink.rb is just fine – it hooks into the deployment process the moment before Chef, after downloading the application source code from Github, changes the symbolic link at /srv/www/symfonyexample/current to the newly downloaded release. At this moment, we have all the source code available, but it is not yet put into production, thus it’s the most sensible moment for additional setup steps.

Moving the deployment-specific parts of our recipe into this hook gives us a before_symlink.rb script as it’s available in our ScalariumExampleSymfony2Application repository on GitHub.

The rest of the original recipe is all about configuring Apache in a way that gives us a working vhost for serving our application – this configuration may change, but it isn’t related to any specific deployment. Thus, these steps should be done only when our Scalarium/AWS instance is set up, and not on every deployment.

And as with the deployment steps, there is a better way to set up Apache for our application, too. Turns out, we don’t need a recipe at all. The reason is that Scalarium implements a very convenient substitution logic – if our own cookbook provides a file with the same name at the same location as one from the Scalarium-provided cookbooks, the file from our own cookbook “wins” and is used instead.

The Scalarium file we are going to substitute is located at /mod_php5_apache2/templates/default/web_app.conf.erb. By providing this file in our own cookbook repository, it’s used as the template for our Symfony2 application vhost – we don’t even need to define “symfony2::deploy” as a Custom Recipe anymore.

And that’s it. As described in my previous post on this topic, we need to configure our Scalarium cloud with the information on our custom cookbook and our application, but instead of manually hooking our custom recipe into the configure and deploy events in Scalarium, our newly created deploy hook now lives in the application itself, and is automatically triggered on every deployment, and our newly created web_app.conf.erb Apache vhost template is automatically used by Scalarium’s Chef when setting up new PHP application server instances.

- (id)outlineView:(NSOutlineView *)outlineView
objectValueForTableColumn:(NSTableColumn *)tableColumn
byItem:(id)item

never get’s called. The reason might very simple: in Interface Builder, in the attributes inspector for your OutlineView, you can define the Content Mode as View Based or Cell Based.

If you simply want to display the content of NSStrings, choose Cell Based, and objectValueForTableColumn will be called.

Only took me 3 hours to find out.

This guy with the psychopathic look standing in a room full of rubbish in front of something that vaguely looks like computers is me standing in front of the first MyHammer server cluster, only days before the whole system went into production.

It was 2005, and I had set up the whole system in a way I’m still quite proud of. Being the only systems administrator at the company at that time, I knew that I wouldn’t face happy times if I would set up the cluster in a traditional way, that is, machine by machine. Although it started small, the system was supposed to grow, especially regarding the web servers, and even I knew that while managing 13 servers individually was doable, it wasn’t fun, and managing several dozen machines just sounded like total nightmare.

Which is why I thought about better ways to setup and manage the whole cluster. I ended up with a central installation server running FAI – Fully Automatic Installation, and hosting a cfengine server. This way, new machines could be automatically provisioned with the operating system (Debian GNU/Linux) they needed by simply booting from their network adaptor, and new as well as existing systems could easily be maintained, configured, and updated via cfengine. No need to ever log in on a specific machine to change configuration or install software. A centralized syslog server completed the picture.

cfengine was a major pain in the ass at times, and with Chef and Puppet there a way more sophisticated tools available today, but the overall system ran extremely well and could easily scale over time.

Years later, the term Devops was coined, and I couldn’t help congratulating myself for getting it right so long ago.

The methodology explained here is outdated, please read Deploying Symfony2 Apps via Scalarium: Improved Methodology for an updated version.

About

This article describes how to use the cloud-based cluster-management platform Scalarium in order to automatically mass-deploy Symfony2 applications with a MySQL database backend onto clusters of Amazon EC2 virtual machines by creating a special Symfony2 environment, using a custom Chef recipe, and making use of Doctrine migrations.

Target audience

Current or soon-to-be Scalarium customers, devops interested in deploying Symfony2 applications using centralized configuration management tools like Chef or Puppet, PHP developers.

Prerequisites

In order to get your Symfony2 application running on Amazon AWS, you need an AWS account, a Scalarium account (correctly set up with your AWS credentials), and a Github account to host your Symfony2 application and your custom Chef recipes. This tutorial assumes that you are already familiar with managing EC2 clusters with Scalarium. It’s tested to work with Symfony 2.0.4 on Ubuntu 11.04 instances.

Overview

The above diagram is here to illustrate how the different parts are working together in order to deploy a running application. The virtual machines hosting our Symfony2 application and the database are EC2 instances running in the Amazon AWS cloud. We will use Scalarium to define the layout of our cluster (called a “cloud” in Scalarium), to configure the application which will be deployed onto the application servers within this cluster, and to configure the custom Chef recipes which need to be applied to our application server instances in order to finalize the deployment and setup of our application.

Looking at the diagram, we could say that Scalarium manages, Amazon runs, and Github provides – Scalarium uses what Github provides in order to run the application on Amazon.

Because Scalarium already provides the setup logic and recipes that allow us to set up basic Apache/PHP application servers and MySQL database servers on AWS, we will only need to provide what is needed in order to finalize the deployment and setup of our specific Symfony2 application – setting up a basic Ubuntu server, installing software packages like PHP, Apache, MySQL, and checking out our Symfony2 application code from Github is all done by Scalarium without the need to provide additional means.

The example application

It makes sense to follow this tutorial using your own Symfony2 application. However, an example application hosted at Github.com → MyHammer → ScalariumExampleSymfony2Application is used to illustrate the process – you are free to use this repository to deploy the application to your Scalarium cloud. The commit history of this repository also shows step by step which changes need to be applied to a Symfony2 application to prepare it for running on a Scalarium cloud.

Setting up a Scalarium cloud for our application

Our very first step is to set up a new cloud in Scalarium which manages the EC2 instances, server roles, application configuration and custom Chef cookbooks needed to deploy and run our Symfony2 application.

In order to do so, click on Add Cloud in the upper right corner of the main Scalarium administration interface. Choose whatever name you like (I will stick with “Symfony”), define a region that makes sense for you (Europe in my case), and choose “Ubuntu 11.04″ as the default operating system. Please choose “Role Dependent” as the Hostname Theme, because this will make it much easier to follow my explanations whenever I’m talking about specific machine instances.

Assuming that you have already set up Amazon AWS in your Scalarium account, please choose the AWS credentials and SSH keys accordingly.

You now have an empty cloud. Let’s define these three things in order to host our application:

• An application
• Custom Cookbooks
• An application server and a database server role

Let’s start with our application. Later, we are going to make some modifications to our application that are necessary for hosting it with Scalarium, but we can already configure it into our cloud. Clicking on Add Application gives us a dialogue in which we can configure where EC2 instances will be able to pull our application from upon bootup or application deployment.

I’m going to choose “SymfonyExample” as the name. Please choose “PHP” as the Application Type. If you are going to use the sample application that resides on Github, please choose a Repository Type of “Git”, and enter the following Repository URL: “git://github.com/MyHammer/ScalariumExampleSymfony2Application.git”. All other parameters are not important for now – however, if you are configuring your own private repository, you will need to provide a deploy SSH key.

Although this is sufficient to deploy the code from Github onto our instances, it’s not enough to actually get a running application. Additional steps are necessary after the code has been pulled from Github, and those steps need to be performed using a custom Chef recipe. We are going to write this recipe later, but we can already configure the cookbook that contains the recipe into our cloud. On the cloud overview page, select Manage Cookbooks from the Actions dropdown.

In the new dialogue, check Enable custom cookbooks, and configure as follows:

• Repository Type: “Git”
• Repository URL: “git://github.com/MyHammer/ScalariumExampleSymfony2ChefRecipes.git”

Deploy SSH Key and Branch / Revision don’t need to be filled out.

As a last step, our cloud needs two machine roles: one for our application servers, and one for our database server. We will start with the application server role. On the cloud overview page, select Add role, and choose the PHP Application Server role.

Once you have added it, an additional configuration is necessary: In Custom Recipes, please add the recipe “symfony2::deploy” for the Scalarium actions configure and deploy. This makes sure that our recipe is run everytime our application is deployed to an instance, or whenever the cloud changes.

Last but not least, create an additional role MySQL Master. Additional configuration is not needed here. If you like, you can already add and boot an instance for this role.

Modifying the Symfony2 application

Our Symfony2 application doesn’t need to be re-programmed in any way in order to run via Scalarium – however, its configuration needs to be specifically modified. You can either modify your existing “prod” environment configuration, or you may want to create a new environment called “scalarium”, which is what I did for the example application.

The nice thing about Scalarium and Symfony2 is that the former provides a very nice PHP interface to the layout of the current cluster, and the latter provides an easy way to make use of this interface.

This allows us to dynamically configure our application’s database setup, avoiding the need to hard code e.g. the IP address of our MySQL master into the application. Here is a step by step description on how to achieve this:

First, create a new and empty file /app/config/config_scalarium.yml. This is going to be the main configuration file for the new “scalarium” environment. Fill the file with the following content:

imports:
- { resource: parameters_scalarium.php }
- { resource: config.yml }


This makes our new environment use 99% of it’s settings based on those from the “prod” environment – however, an additional file is imported, /app/config/parameters_scalarium.php – this is where we are going to dynamically define our database settings using the power of Scalarium.

Let’s fill /app/config/parameters_scalarium.php with life:

<?php

unset($scalarium);


What happens here is that the database parameter placeholders like %database_host%, which are used in /app/config/config.yml to configure the database for our application, are programmatically defined based on the current state of the Scalarium cloud. Leveraging the power of the scalarium.php script, which is available in the root directory of our application per default (a symlink is created whenever our application is deployed on an instance), this makes our database config dynamic and therefore always up to date.

The creators of Scalarium point out that using scalarium.php is just a convenience. The full-stack alternative would be to write a Chef recipe that generates the configuration file and register this recipe on the configure and deploy events. Inside the Chef recipe Scalarium provides you with all necessary information like which hosts exist in the cloud and what their configuration is (e.g. IP addresses, roles, etc.). See http://support.scalarium.com/kb/custom-instance-setup for further information on how to use the Scalarium cloud structure information in your own recipes.

One important thing to consider here is that the settings in /app/config/parameters.ini overwrite settings with the same name in /app/config/parameters_scalarium.php – we therefore need to remove all lines containing “%database” from parameters.ini!

The last step is to create a Frontend Controller for our new “scalarium” environment at /web/app_scalarium.php:

<?php

$kernel = new AppKernel('scalarium', false);
$kernel->loadClassCache();
//$kernel = new AppCache($kernel);
$kernel->handle(Request::createFromGlobals())->send();


You can look at a visual before-and-after comparison of all these changes on Github:

Putting the parts together

Our cloud now has everything in place it needs. Its roles are defined, our application servers know where to pull our application from, instances of role “PHP Application Server” are configured to use our custom Symfony2 deploy recipe, and our application has been modified to make use of the dynamic cloud configuration in a new environment called “scalarium”.

Let’s take a moment to look at our custom Chef recipe.

What this recipe does is it checks for each application that is going to be deployed if it’s actually a Symfony2 application, and if yes, it starts by updating the vendors (or installing them from scratch if none exist yet), clears the application’s cache, applies database migrations (if any), makes sure that cache and log files and directories are read and writable for those users that need it, installs and configures an Apache vhost file for the app, and disables the default vhost.

Ok, let’s deploy our application! All you need to do is to add an instance of role PHP Application Server and boot it up. Everything else happens automatically:

• Scalarium requests an EC2 instance from Amazon AWS which is booted with a fresh Ubuntu 11.04 image
• Scalarium sets this machine up with some basic packages like PHP, Apache etc., and executes its basic setup routines (which are Chef recipes, too)
• Our Symfony2 application is pulled from Github and deployed to /srv/www/symfonyexample/current
• The instance executes our custom Chef recipe symfony2::deploy which installs the vendors, clears the app cache, applies the database migrations, installs the web assets, sets users and permissions on cache and log files, and configures an Apache vhost for our application

Once this is done, you can browse to the public IP of the booted application server instance, which will display the Symfony2 welcome page.

Being the BDD fanatic that I am, I wanted to start off behaviour-driven right from the beginning, and Vows looked like a good choice.

However, I quickly came to the point where I needed to stub out a dependency in one of my modules, and as far as I can see, Vows doesn’t provide mocking/stubbing. But https://github.com/felixge/node-gently does, and here is my approach at combining these two:

This is the Vows spec:
var gently = global.GENTLY = new (require("gently"));

vows.describe("My Module").addBatch({
"when calling its foo() method": {
topic: myModule,
"it triggers a console message": function (topic) {
gently.expect(gently.hijacked.sys, "puts", function(str) {
assert.equal(str, "Hello World");
});
topic.foo("Hello World");
}
}
}).export(module);


And this is the implementation of MyModule:
if (global.GENTLY) require = GENTLY.hijack(require);

exports.foo = foo;


No idea if this makes any sense in the long run – I will tell you when I’m about 14 hours or so into BDD node.js development…

The following roots in something I heard from Jon Jagger at QCon London 2011 after his fantastic talk about Deliberate Practice. It was related to Test Driven Development. He asked “Why do cars have brakes?”. It made us think “To stop!”, but he said “No – to go faster”.

(Jon points out he didn’t invent it, he heard it from Kevlin Henney).

I have been thinking about this ever since, and here is what I came up with.

Imagine I would give you the keys to my car. I would tell you “here are the keys, you can drive wherever you want, including the highway, have fun!”

How fast would go? My car is not exactly a sports car, but it can do around 200 km/h. I guess we both agree that you would drive around 50 km/h within cities (the maximum allowed in Germany), and probably up to 200 km/h on the highway, as long as there is no limit.

Fine. Now image this: I would give you the keys to my car. I would tell you “here are the keys, you can drive wherever you want, including the highway, have fun! Oh, just one thing, the brakes don’t work.”

Now let’s forget for a moment that in reality, you probably wouldn’t start at all, if you had to drive, then how fast would you go? 10 km/h, maybe 20? Driving extremely cautious, always trying to look as far ahead as possible if you are going to need to halt? Yeah, I thought so.

But why is that? The brakes don’t have anything to do with the speed of my car – it’s still capable of doing 200 km/h just fine!

It’s because the ability to stop is what enables you to go real fast. With only a bit of exaggaration you could say that having a brake allows for a very “iterative” way of driving – no cars within the next 300 meters, let’s accelerate a bit – oh, there’s a car coming over from the right, let’s brake a bit – ok, now I can accelerate again – ah, there is a signal that suddenly turned red, no problem, I will stop here.

For me, this metaphor is the best I could find by now to explain to myself (and in the future, to others), why I really want to develop test-driven, and why it actually makes me faster, not slower, although I’m doing more.

Just as the brake doesn’t directly influence your driving speed, but does so indirectly, your tests won’t influence your coding speed directly, but indirectly. It’s because once they are in place, they allow you to iterate over your code and refactor it at what I, from my own experience, can only describe as the speed of light compared to conventional programming.

With tests in place, it’s like: Mh, what if I would split this rather long method into two? – ok, works; What if I put a bit more of dependency injection into this class? – ah, now this test here fails, no problem, I will have it back to green within minutes, I know exactly where to go to fix this; Hey, I could give this method here a better name – ok, still green; There’s this performance bottleneck deep inside this one class that is heavily used by a lot of other classes, let’s see if I can fix this – my tests will tell me if I accidently changed behaviour.

Compare this to conventional programming: You will never know for sure what breaks somewhere else if you change something. If you want to find out, you need huge amounts of manpower to have your webpage or UI tested for regression. What really happens is that you slow down to a near halt: because you don’t know what’s around the next corner when developing, and you know there is nothing that will immediately stop you and save you from harm if you take that next corner, you will drive, err, code so cautious, you won’t make any real progress.

On which Jon commented: “Yes. As the pragmatic programmers say, paraphrasing – you don’t know why it’s broken because you didn’t know why it worked in the first place.”

So, I had this (rather obvious) gut feeling that working iterative in software projects makes a lot of sense, I’ve heard all the arguments and explanations and examples and stuff like that, and I probably already “got it”, but I thought it could make sense to clearly work out why exactly it makes sense, by visualizing it. Surely it’s no rocket surgery what happens here, but I kind of like it and would like to share it.

So here’s my approach:

The customer tells a product manager what he wants him to build. Let’s see how a waterfall approach leads to the product team failing at this:

The reason why what is finally delivered isn’t what the customer expected is that the project goes through the hands of different people and different stages, and every time the project is given to another person or team, the amount of misunderstanding grows. That’s only natural because we cannot copy ideas from one brain to another in a 1:1 manner.

Here is why an iterative approach makes sense:





The project really starts the same: There is a certain amount of misunderstanding, and the team does things wrong. But due to the regular feedback from the customer, this wrong direction can be corrected. It might then move into another direction which is still a bit wrong, but then comes the next correction, and finally everything is on track.

Sobald es einen stabilen Zustand erreicht, wird dieses Tool das Sammeln und Visualisieren verschiedener statistischer Daten, wie sie typischerweise von Internetplattformen erzeugt werden, schnell und leichtgewichtig ermöglichen. Beispiele für diese Daten sind Dinge wie die CPU Last einzelner Systeme, Benutzerlogins, Anzahl der Seitenaufrufe usw.

Die Applikation basiert in erster Linie auf Rails, der HTTP Server für die Datenanlieferung ist in node.js geschrieben, die Weboberfläche nutzt sehr ausgiebig jQuery und für die Erzeugung von SVG Graphen die Raphaël Bibliothek. Massendaten werden in SQL gespeichert, weitere Daten liegen in einer CouchDB.

Der Projektcode ist auf Github abrufbar unter https://github.com/ManuelKiessling/PlatformHealthViewer.

Das folgende Video ist eine kurze Einführung zur aktuellen Alphaversion des Projekts. Es enthält außerdem eine lustige Sprecherstimme und eine sehr kreative Interpretation der englischen Grammatik.

Im Folgenden das ins Deutsche übersetzte Transskript des Videos:

Hi. Platform Health Viewer – oder PHV – ist mein aktuellen Hobbyprojekt.

Ich brauche eine einfache und leichtgewichtige Möglichkeit, die verschiedenen Kennzahlen der Webseite, für die ich verantwortlich bin, zu sammeln und zu visualisieren. Sachen wie die CPU Perfomance wichtiger Systeme, Userlogins, HTTP Anfragen.

Deshalb habe ich angefangen mit Ruby on Rails, jQuery, CouchDB und node.js zu experimentieren, und hier ist eine frühe Alphaversion, die ich demonstrieren möchte.

Mein Hauptziel ist es, den Prozess von der Einspeisung der Daten in das System bis hin zu ihrer grafischen Visualisierung so einfach wie möglich zu gestalten.

Um Daten in das System zu bekommen, benötigt man lediglich einen HTTP Aufruf, was es sehr einfach macht, die Daten der unterschiedlichsten Quellen zu sammeln.

Probieren wir ein Beispiel aus. I möchte die CPU Performance meiner lokalen Maschine visualisieren.

Ich werde diese Daten bekommen, indem ich einen Standard Unix Befehl verwende: sar.

Dies ist ein wichtiger Aspekt meines Ansatzes: Für den Platform Health Viewer spielt es überhaupt keine Rolle, woher die Daten stammen – man ist bei den Mitteln der Datenbeschafung völlig frei. Dadurch kann man wirklich alles in das System übermitteln, angefangen bei allgemeinen Daten wie der CPU Last bis hin zu äußerst individuellen Sachen wir den Logins auf der eigenen Webseite.

Ok, so bekomme ich den CPU “usr” Wert auf meiner OS X Kommandozeile:

sar 1 1| grep Average| cut -b 14-15

Fein, das wird’s tun.

Wie liefern wir diese Werte in das System? Es reicht ein simpler HTTP Post Aufruf mithilfe von curl:

curl –data “event[value]=`sar 1 1| grep Average| cut -b 14-15`&event[source]=macbook&event[name]=cpu_usr_percentage” http://localhost:3000/queue_event

Wie man sieht, die Nutzdaten des Aufrufs bestehen aus lediglich drei Parametern: Der Quelle des Events, dem Namen des Events, und seinem Wert.

Noch mal: Man ist an dieser Stelle komplett flexibel, man ist nicht gezwungen Eventnamen und -quellen zuvor im PHV zu konfigurieren – man definiert diese einfach im Moment der Dateneinlieferung, das das System akzeptiert diese. Wir werden gleich sehen, wie man mit den verschiedenen Events, die in das System geschrieben werden, sinnvoll umgeht.

Ok, ich verwende jetzt ein kleines Hilfsskript das ich geschrieben habe, um die CPU sys, idle, usr und nice Werte in das System zu liefern:

cat script/agents/macosx/cpu_overview_percent.sh

Wie man sieht, geschieht alles unter der Verwendung normaler Unixbefehle.

Starten wir also das Skript:

bash ./script/agents/macosx/cpu_overview_percent.sh http://localhost:3000/ macbook

Ich übergebe hier nur zwei Parameter, die URL zum Platform Health Viewer (der für diese Demonstration auf demselben Host läuft), und den Namen meiner Eventquelle, die ich “macbook” nenne. Eventnamen und -werten kommen direkt aus dem Hilfsskript.

Man sieht, wie das Skript alle vier CPU Kennzahlen in das System liefert. Schauen wir uns diese Daten innerhalb des Platform Health Viewer an.

Nun, das Dashboard ist nach wie vor leer, da wir noch keinerlei Visualisierungen definiert haben. Aber der “Tageditor” zeigt ebenfalls noch keinerlei Events an. Das liegt daran, dass die in das System eingelieferten Events noch nicht zu sogenannten Eventtypen normalisiert wurden.

Dies ist bewusst ein zusätzlicher Schrit, denn es erlaubt dem System, eingehende Events so schnell wie möglich in die Datenbank speichern zu können, ohne sie in Hinblick auf Name und Quelle normalisieren zu müssen. Diese Normalisierung erledigt ein Rake Task:

rake queue:convert

Dieser Task liest die Events aus der Anlieferungs-Queue, erzeugt bei Bedarf neue Eventtypen, oder verbindet die Events mit bereits existierenden Eventtypen, falls diese bereits existieren. Abschliessend wird die Anlieferungsqueue geleert.

Zurück im Tageditor, können wir die vier Eventtypen nun sehen.

Ein Eventtyp ist die Kombination einer Eventquelle und eines Eventnamen, also ist “macbook – cpu_idle_percentage” ein Eventtyp.

Schauen wir nun, wie wir den Tageditor verwenden können um etwas sinnvolles zu basteln. Das Gruppieren von einem oder mehreren Eventtypen unter einem Tag macht unsere eingelieferten Daten visualisierbar. Ich bin übrigens nicht ganz glücklich mit dem Begriff “Tag”, vielleicht fällt mir da noch etwas besseres ein.

Wie auch immer, erzeugen wir nun einen einfachen Tag den wir benutzen können, um genau einen Wert zu visualisieren.

Ich werde diesen Tag “macbook_cpu_usr” nennen. In diesen laufen dann alle Events, deren Quelle “macbook” und deren Name “cpu_usr_percentage” lautet. Ich könnte diese Parameter auch in die Textbox eintippen, aber es ist einfacher sie schlicht per Drag&Drop in das Formular zu ziehen.

Ok, fügen wir diesen Tag also hinzu.

Wir haben nun also einen ersten Tag, und um zu sehen, ob er wie erwartet funktioniert, kann ich die Werte der zugeordneten Events in einer Vorschau kontrollieren.

Liefern wir jetzt ein paar weitere Werte in das System und schauen, ob sie dann hier angezeigt werden.

Ok, ich starte also mein Hilfsskript erneut um neue Werte in den Server zu liefern, und starte dann wiederum den Rake Task um die Werte zu normalisieren.

Ein erneuter Klick auf “Show latest events” zeigt diese neuen Werte nun an.

Ich starte die Datenanlieferung jetzt in einer Schleife, um viele Werte zu erhalten.

Ok, wir haben nach wie vor keine Datenvisualisierung, also gehen wir das jetzt an. Ich wechsle in’s Dashboard und füge einen Frame hinzu, dies ist ein Container der unsere Graphen enthalten wird.

Ein Frame ist die Visualisierung aller Werte die mit einem Tag verbunden sind, also muss ich den Namen des Tags angeben, das ich mit diesem Frame visualisieren möchte.

“Add frame”, und los geht’s. Ein einfacher Liniengraph, der einen meiner CPU Werte repräsentiert. Der Graph ist im Übrigen ein SVG, erzeugt mit Raphael, einer fantastischen JavaScript Bibliothek.

Und dank jQuery kann ich diesen Graphen frei bewegen und skalieren.

Erzeugen wir nun einen Graphen für alle meine CPU Werte. Zurück im Tageditor ziehe ich nun alle meine Eventtypen zusammen.

Ich kann übrigens Tags erzeugen, indem ich Eventquellen und -namen mit bereits existierenden Tags kombiniere, wie man hier sieht.

Ich überprüfe alle Werte die meinem neuen Tag zugeordnet sind, und dort sieht man alle CPU Werte, die mein Skript gesammelt hat.

Wieder zurück im Dashboard gehe ich her und erzeuge einen weiteren Frame, für meinen neuen Tag. Wie man sieht, enthält dieser Frame vier Liniengraphen und zeigt mir so eine hübsche Übersicht meiner kompletten CPU Performance. Natürlich wird hier eine Legende benötigt, etwas das bisher noch nicht implementiert ist.

Nun, das ist es, das ist der aktuelle Stand des Projekts. Ich würde mich sehr über Feedback freuen, der Code kann auf Github geforkt werden oder schreibt mir eine Mail.

Danke für’s Interesse.

Once stable, it will allow users to easily collect and visualize different types of statistical data which is typically produced by internet platforms, like CPU performance, user logins, HTTP requests etc.

The main application is build on Rails, the server used for data collection is written in node.js, the web interface makes heavy use of jQuery and uses Raphaël to create SVG graphs. Mass data is saved in a SQL db, other data is stored using CouchDB.

The project’s code is hosted on Github at https://github.com/ManuelKiessling/PlatformHealthViewer.

This video is a short introduction to the current alpha version of the project. A funny voice and lots of grammatical shortcomings are included for free:

Transcription of the video:

Hi. Platform Health Viewer – or PHV – is my current pet project.

I need an easy and lightweight way to collect and visualize the different key performance indicators of the web platform I’m responsible for – stuff like CPU performance of important systems, user logins, http requests.

So I started to play around with Ruby on Rails, jQuery, CouchDB and node.js, and here is an early alpha I would like to demonstrate.

My primary goal was to make the process from feeding data into the system to visualizing that data as simple as possible.

In order to get data into the system, all you need to make is an HTTP call, which makes it very easy to collect data from very different sources.

Let’s try an example. I would like to visualize the cpu usage of my local machine.

I’m going to collect this data using a standard unix command, sar.

That’s an important aspect of my approach: It doesn’t play any role for the Platform Health Viewer where the data comes from, you’re completely free to choose how to collect it.
This way you can feed really anything into the system, from generic data like CPU load to highly individual stuff like the user logins of your specific web site.

Ok, here is how I can get my cpu “usr” value on my OS X command line:

sar 1 1| grep Average| cut -b 14-15

Great, that will do.

How do we push these values into the system? It’s a simple http post request using curl:

curl –data “event[value]=`sar 1 1| grep Average| cut -b 14-15`&event[source]=macbook&event[name]=cpu_usr_percentage” http://localhost:3000/queue_event

As you can see, the payload of the post requests is just 3 parameters: the source of the event, the name of the event, and its value.

Again, you’re completely free here, you don’t need to configure event names and sources inside PHV – just define them when pushing data into the system, it will happily accept it. We will see in a moment how to make sense of different events that were pushed into the system.

Ok, let’s use a small helper script I wrote in order to feed the CPU sys, idle, usr and nice values into my system:

cat script/agents/macosx/cpu_overview_percent.sh

As you can see, this is all done using only standard unix commands.

Let’s start the script:

bash ./script/agents/macosx/cpu_overview_percent.sh http://localhost:3000/ macbook

I’m just providing two parameters here, the URL to my platform health viewer installation, which resides on the same host for this demo, and the source name, which I call “macbook”.

As you can see, my script pushes all four CPU usage values into the system. Now let’s have a look at this data within platform health viewer.

Well, the Dashboard is still empty, because we did not yet define any visualizations. But the “Tageditor” doesn’t show any events, too. This is because the events I pushed into the system have not yet been normalized to event-types.

This is an additional step, because it will allow the system to push incoming events into the database as quickly as possible without the need to normalize those events regarding their name and source. This normalization is done using a rake task:

rake queue:convert

This task reads the events from the incoming queue, creates new event-types as needed, or connects the event values with existing event types if they already exists. It then deletes the incoming queue.

Getting back to our tageditor, we can now see our 4 event types.

An event type is the combination of an event source and an event name, so “macbook – cpu_idle_percentage” is one event type.

Let’s see how we can use the tag editor to create something useful. Grouping one or more event types into a tag is what makes our data suitable for visualization. I’m not quite happy with the term “tag” by the way, maybe I will come up with something better.

Anyway, let’s create a very simple tag which we can use to visualize exactly one value.

I’m going to name my tag “macbook_cpu_usr”. It will hold all events whose source matches “macbook”, and whose name matches “cpu_usr_percentage”. I could type those parameters into the text box, but it’s easier to just drag’n'drop them there.

Ok, let’s add this tag.

Now we have this first tag, and to check if it works as expected, I can preview the values of the matching events.

Let’s push some new values into our system and check if they are visible here.

Ok, I’m starting my helper skript again in order to post new values to the server, and I start my rake task in order to normalize these values.

Clicking again on “Show latest events” now shows these values.

I will now start data push and normalization in a loop in order to get a lot of values.

Ok, we still have no data visualization, so let’s do this now. Let’s switch to the Dashboard and add a frame, which is a container that will hold our graph.

A frame is the visualization of all values connected to a tag, so I need to provide the name of the tag I want to visualize with this frame.

“Add frame”, and here we go. A simple line graph representing one of my CPU values. The graph is actually an SVG, created using Raphael, an awesome JavaScript library.

And thanks to jQuery, I can freely move and resize the graph.

Let’s create a graph with all my CPU values in it. Back to the Tageditor, I’m going to drag all my values together.

I can also create tags by combining event-sources and -names with already existing tags, as you can see here.

Let’s check the values of my new tag, and there are all the different CPU values my script collects.

Back to the Dashboard, I’m going to create another frame for my new tag. As you can see, this one contains 4 linegraphs and gives me a nice overview of my system’s CPU performance. Of course, a graph legend is needed, something that’s not yet implemented.

Well, that’s it, that’s the current state of this project, I would love to hear your feedback, you can fork the code on github and drop me an e-mail.

Thanks for your interest.

Wieso eigentlich sollte man die Prinzipien und Methodiken von testgetriebener Softwareentwicklung nicht auch auf den Bereich der IT-Systemadministration übertragen? Also in aller Kürze: Ich definiere Tests, die das vom noch zu implementierenden System erwartete Verhalten prüfen, sehe zu wie diese Tests fehlschlagen, und erfülle dann schrittweise diese Tests, indem ich das System aufbaue. Test driven administration – TDA.

Da war ich ganz alleine drauf gekommen, und ich war sehr stolz.

Dann habe ich gegoogelt. Die Idee existiert seit mindestens 2006.

Aber hey, gut ist die Idee trotzdem, also beschreibe ich sie hier.

Warum möchte man testgetrieben administrieren? Die Gründe sind dieselben wie bei testgetriebener Entwicklung: Habe ich Tests, bin ich gegen Regression geschützt, d.h. ändert ein Stück Code / ein System sein Verhalten aufgrund von Änderungen, weisen mich die Tests darauf hin.

Gehe ich testgetrieben vor, sind die Tests nicht irgendwas, das ich ganz unbedingt machen sollte, das aber doch am Ende runterfällt, sondern sie sind garantiert vorhanden. Mit den bekannten angenehmen Begleiterscheinungen, dass die Tests einen zwingen, sich Gedanken darüber zu machen, wie das Ziel eigentlich beschaffen sein soll, und automatisch dazu führen, die Lösung schlank und elegant umzusetzen.

Code und IT-Systeme sind aber nicht dasselbe, wie würde man also in der Praxis konkret vorgehen? Hier mein Vorschlag.

Zuerst benötigt man ein Testwerkzeug. Um in der Softwareentwicklung Unittests zu bauen, benutzt man Tools aus der xUnit Familie wie JUnit oder phpUnit. Das Äquivalent zu diesen Tools in der Systemadministration sind Monitoringsysteme wie Nagios oder Zabbix.

In der Softwareentwicklung formuliert man Unittest so, dass man eine kleine Einheit des Gesamtsystems, also in der Regel die einzelnen Methoden einer Klasse, mit einer gewissen Erwartungshaltung (“wenn ich diese Parameter reingebe, erwarte ich jenen Rückgabewert”) aufruft, und dann die erwartete Rückgabe mit der tatsächlichen vergleicht.

Was wäre dementsprechend “erwartetes Verhalten” bei einem IT-System? Nehmen wir an, die Anforderungen lauten wie folgt:

Benötigt wird ein Linux-System, welches unter der IP 123.456.789.000 einen Webserver bereitstellt, und die Festplattengröße des Systems soll 100 GB betragen.

In der Realität wären die Anforderungen natürlich umfangreicher, aber ich halte das Beispiel einfach.

Aus den Anforderungen lässt sich das gewünschte Verhalten ableiten:

• Bei einem Ping auf 123.456.789.000 muss eine Antwort erfolgen
• Die Abfrage des Betriebssystems unter dieser IP muss “Linux” ergeben
• Ein HTTP Request gegen diese IP unter Port 80 muss eine HTTP Antwort zur Folge haben
• Bei der Abfrage der Festplattengröße muss ein Wert von 100 GB zurückgeliefert werden

Daraus wiederum kann man im Monitoringsystem Tests formulieren. Diese lässt man einmalig laufen, um zu verifizieren, dass sie tatsächlich fehlschlagen. Und dann beginnt man damit, ein System aufzusetzen, das die Testbedingungen erfüllt, bis schliesslich alle Tests “grün” sind.

Das ist der Kern der Idee. Im weiteren Verlauf überwacht man die Tests regelmäßig (was man mit einem Monitoringsystem ja eh tut), und hat damit das Thema Continuous Integration gleich mit erschlagen. Ansonsten geht man genauso wie auch beim TDD vor: Möchte man Änderungen an einem System vornehmen, passt man zuerst die Tests an, verifiziert dass sie fehlschlagen, und ändert dann das System, um die Tests wieder zu erfüllen.

Umso mehr hat <angular/> mein Interesse geweckt. Die Autoren versprechen:

Write less code. A lot less. Forget about writing all that extra JavaScript to handle event listeners, DOM updates, formatters, and input validators. comes with autobinding and built-in validators and formatters which take care of these. And you can extend or replace these services at will. With these and other services, you’ll write about 10x less code than writing your app without .

In einem Video versucht Miško Hevery zu erklären, was <angular/> eigentlich ist, und stellt fest dass diese Erklärung schwierig ist:

Mein Verständnis ist in erster Linie: <angular/> bringt JavaScript-Logik und das dazugehörige HTML Dokument deutlich näher zueinander als bestehende Frameworks wie beispielsweise jQuery. Es entfernt gleich mehrere Ebenen an Abstraktion, die ein Stück JavaScript-Code und das DOM-Element, auf welchem der Code operieren möchte, voneinander trennen.

Während man bei traditioneller JavaScript-Programmierung stets gezwungen ist, explizit das HTML Dokument mit JavaScript-Code zu manipulieren, macht <angular/> die Verbindung zwischen Logik und HTML-Repräsentation implizit – etwas, das mich übrigens stark an die Mechanik erinnert, die Max Winde für siqqel einsetzt.

Spielen wir ein einfaches Beispiel durch, welches ich dank der rein clientseitigen Arbeitsweise von <angular/> problemlos direkt hier im Post zum laufen bringen kann.

Zuerst binde ich die <angular/> JavaScript Bibliothek ein:

<script type="text/javascript" src="http://angularjs.org/ng/js/angular-debug.js" ng:autobind>
</script>


Nun definiere ich ein Input Feld sowie einen <angular/>-Platzhalter, welche beide in einer Beziehung zueinander stehen:

Dein Name: <input type="text" name="deinname" value="Manuel"/>
<br />
Hallo {{deinname}}!


Wodurch entsteht diese Beziehung? Sie ist dank Autobinding implizit, und mappt alleine aufgrund des Formularfeldnamens und des Platzhalternamens beide zusammen.

Das Ergebnis sieht man hier – einfach den Inhalt des Textfeldes ändern:

Eingabe:
– Hallo {{yourname}}!

Dieses Beispiel geht natürlich maximal als Spielerei durch. Es zeigt aber schon, wieviel weniger Code nötig ist, als dies mit einem klassischen Framework der Fall wäre.

Ein etwas praxisnäheres Beispiel findet man unter http://angularjs.org/Cookbook:BasicForm. In diesem Beispiel geht es um den klassischen Fall, Eingaben in ein Textfeld per JavaScript clientseitig zu validieren – dies ist einfach möglich durch folgende schlanke und ausdrucksstarke Syntax:

<input type="text" name="user.address.state" size="2" ng:required ng:validate="regexp:/^\w\w$/"/>


Für weitere Informationen verweise ich auf http://angularjs.org/Overview.

Testgetriebene Entwicklung (test driven development) ist eine Arbeitsmethodik, die Softwareentwickler dabei unterstützt, wichtige Qualitätsprinzipien bei der Erstellung von Code zu befolgen:

• Lose Kopplung (loose couping) – weil man beim Schreiben von Unittests, dem zentralen Werkzeug der Methodik, ganz automatisch dazu verführt wird, innerhalb der Tests von Codeunits (Klassen, Methoden usw.) auszugehen, die möglichst wenige Abhängigkeiten zu anderen Modulen haben – einfach deshalb, weil das Schreiben der Tests dann zu nervig wird.
• Saubere Trennung von Verantwortlichkeiten (separation of concerns) – aus ganz ähnlichen Gründen wie der erste Punkt: Jeder Test testet genau ein gewünschtes Verhalten, und dies führt ganz automatisch dazu, dass man später den Code, der die Tests erfüllen muss, in sauber voneinander getrennte und logisch strukturierte Einheiten teilt.
• Schlanke Lösungen – testgetrieben bedeutet eben auch, dass man von den Tests getrieben ist, im besten Sinne: Man tut alles, um einen noch fehlschlagenden Test zu erfüllen; aber eben auch nur genau das und nicht mehr. Salopp gesagt: Man programmiert nicht mehr “einfach rum”, sondern arbeitet äußerst zielgerichtet und erzeugt Code, der nur genau das tut was er tun muss, was ganz automatisch zu einer schlanken und damit eleganten Lösung führt, in der sich zum Beispiel Bugs sehr viel schlechter verstecken können.

Darüber hinaus hat der testgetriebene Ansatz weitere nützliche Nebeneffekte:

• Die im Laufe der Zeit aufgebaute Sammlung von Unittests kann man benutzen, um die mit Tests versehenen Units automatisiert immer wieder testen zu können, zum Beispiel um beim Mergen eines Entwicklungszweigs mit einem anderen Zweig (oder auch nach jedem einzelnen Commit in ein Versionskontrollsystem) sicherzustellen, dass sich alle Units auch nach der Zusammenführung zweier Entwicklungslinien noch so verhalten wie erwartet. Das Stichwort für weiterführende Lektüre ist hier die Kontinuierliche Integration (continuous integration).
• Ein Unittest ist in der Praxis nicht nur ein Stück Code, sondern immer auch Dokumentation des erwarteten Verhaltens eines Systems – zumindest in einer für Programmierer lesbaren Form. Um als Unbeteiligter ein Stück Code oder ganze Teile eines Systems kennen zu lernen, ist es häufig effizienter, die dazugehörigen Tests zu lesen, als den Code selbst.
• Hat man erst einmal die Tests komplett geschrieben, welche die noch zu erzeugenden Units testen sollen, ist es sehr einfach, die Arbeit am eigentlichen Code einfach mittendrin auch für längere Zeit zu unterbrechen – die Tests geben einem sofort einen Anhaltspunkt, wo man “weiterprogrammieren” muss, selbst wenn man gedanklich längst aus dem Thema war.
• Testgetrieben zu entwickeln, erzeugt ein gutes Gefühl. Das mag banal klingen, aber es ist ein realer und wichtiger Faktor. Irgendwo habe ich mal eine sehr gute Definition des Begriffs “legacy code” gelesen: “legacy code” ist Code, vor dem man sich fürchtet – weil man nicht genau weiss was er tut, und deshalb Angst hat, ihn zu verändern. Testgetriebene Entwicklung ist die beste Vorsorge gegen legacy code – man weiss, es gibt eine Instanz die überwacht und aussagt, was der Code tun soll. Es wächst das Vertrauen in den eigenen Code und damit auch in die eigenen Fähigkeiten.

Die Unterteilung in zentrale Effekte und Nebeneffekte ist subjektiv. Ich habe die Erhöhung der Codequalität an sich für mich als wichtiger erlebt als zum Beispiel die Tatsache, dank der sich entwickelnden Testsammlung Regressionstests durchführen zu können. Geschadet hat mir jedenfalls noch kein einziger durch testgetriebene Entwicklung entstandener Effekt.

Voraussetzungen

Was benötigt man nun, um in PHP testgetrieben zu entwickeln? Im Wesentlichen vier Dinge:

• Eine Arbeitsmethodik, um effizient zu testgetrieben entwickeltem Code zu kommen
• Ein Organisationsprinzip, um Tests und zu testenden Code sinnvoll strukturieren zu können
• Ein PHP Framework, um Testfälle schreiben zu können
• Ein Tool, um Testfälle ausführen und auswerten zu können

Beginnen wir mit den letzten beiden Punkten, denn dank der Maßstäbe setzenden Arbeit von Sebastian Bergmann (http://sebastian-bergmann.de/) existiert ein Softwareprojekt, welches beide Anforderungen hervorragend erfüllt und längst der de-facto Standard für Unittesting unter PHP ist: PHPUnit.

Unter http://www.phpunit.de/manual/current/en/installation.html befindet sich eine ausführliche Anleitung für die in der Regel sehr einfache Installation.

PHPUnit ist sowohl ein Framework aus PHP Klassen, die es erlauben, Unittests für den eigenen PHP Code zu schreiben, als auch Kommandzeilen-Werkzeug, um die eigenen Tests auszuführen und in verschiedenen Formaten die Testergebnisse darzustellen.

Im weiteren Verlauf des Tutorials gehe ich davon aus, dass PHPUnit installiert und funktionsfähig ist.

Im Mittelpunkt von testgetriebener Entwicklung stehen aber nicht die Werkzeuge, sondern der Arbeitsprozess. Dieser folgt stets diesem Muster:

• Schreiben des Tests für eine neu zu implementierende Funktionalität
• Erfüllen des Tests mit so wenig Aufwand wie möglich, so dass dieser fehlerfrei durchläuft
• Überarbeiten des Codes, der den Test erfüllt, so dass dieser keine Duplizierungen enthält, sauber abstrahiert ist, und dem eigenen Code-Style entspricht – und dabei immer noch den Test erfüllt

Diese Schritte werden immer wieder wiederholt, bis man keine neuen sinnvollen Tests mehr findet für die neue Funktionalität.

Möchte man bereits vorhandene Funktionalität ändern, die bereits mit Tests versehen ist, bedeutet testgetriebene Entwicklung, dass man zuerst die Tests ändert, um das neue erwartete Verhalten widerzuspiegeln, sicherstellt, dass die veränderten Tests fehlschlagen, und dann erst den Code anpasst, um die veränderten Tests wieder zu erfüllen.

Wäre noch die Frage der Testorganisation zu klären – einfacher ausgedrückt: Wohin mit den Tests? Meiner Meinung nach ist der einzig wirklich sinnvolle Ansatz, Code und Tests identisch zu strukturieren. Das bedeutet, der Test für die Klasse DefaultUser in

lib/core/user/default_user.php

sollte in der Datei

tests/core/user/default_user_test.php

in der Testklasse DefaultUserTest liegen.

Aber solange wir noch kein Beispiel für einen Unittest durchgespielt haben, bleibt vieles sehr abstrakt, also beginnen wir den praktischen Teil des Tutorials.

Ein erstes Beispiel

Angenommen, wir möchten mithilfe von PHP ein Forum programmieren. Auf die ein oder andere Art und Weise wird diese Software eine Unit enthalten müssen, die eine E-Mail Adresse auf Gültigkeit prüft. Wir haben also eine Erwartungshaltung, was der Code später einmal tun soll. Der Einfachheit halber definieren wir diese Erwartungshaltung in diesem Beispiel so:

Wenn eine E-Mail Adresse ohne @-Zeichen übergeben wird, dann liefere mir FALSE zurück, sonst TRUE

Diese Erwartungshaltung gießen wir nun in Form von PHP Code in einen Unittest. Da wir testgetrieben arbeiten, existiert noch keinerlei Code der diese Erwartungen erfüllen könnte.

Wir geben der Unit, die später einmal unsere formulierte Erwartung erfüllen soll, den Namen Verify. Daraus leitet sich als Klassenname für den Unittest die Bezeichnung VerifyTest ab.

Wir erzeugen daher folgende Datei:

tests/verify_test.php

Und füllen sie mit folgendem Grundgerüst:

<?php
require_once('/usr/lib/php/PHPUnit/Framework.php');

class VerifyTest extends PHPUnit_Framework_TestCase {}


Dieser Code repräsentiert einen Testcase, der noch keine Tests enthält. Wir inkludieren das PHP-Klassen Framework von PHPUnit, da wir unsere Testcase-Klassen von einer Klasse dieses Frameworks ableiten müssen. Je nach Plattform liegt die zu inkludierende Framework.php auch schon mal unter /usr/share/php/PHPUnit/Framework.php.

Den Testcase selbst formulieren wir, indem wir eine Klasse definieren, deren Name auf Test endet, und die von PHPUnit_Framework_TestCase erbt.

Dieser Testcase kann nun mithilfe des PHPUnit Kommandozeilentools ausgeführt werden. Dazu starten wir folgenden Befehl an der Kommandozeile:

phpunit tests/verify_test.php

Dadurch erhalten wir die folgende Ausgabe:

PHPUnit 3.4.13 by Sebastian Bergmann.

1) Warning
No tests found in class "VerifyTest".


PHPUnit wertet den Testlauf als nicht erfolgreich (“Failure”), da keinerlei Tests innerhalb des Testcases gefunden wurden. Als nächstes fügen wir daher einen Test hinzu:

<?php

}


Einen Test innerhalb eines Testcase formuliert man, indem man der Testcase-Klasse eine Methode hinzufügt, deren Name mit test beginnt.

Innerhalb der Methode schreibt man nun den Code, der notwendig ist, um den oder die Werte von der zu testenden Unit zu bekommen, mithilfe derer man das erwartete Verhalten verifizieren kann.

Die von der Unit erhaltenen Werte testet man nun gegen eine Behauptung, einen assert: Wir drücken hier also aus, dass der Test erwartet, dass der zu testende Wert FALSE ist.

Letztendlich muss man sich aber immer bewusst machen: Man möchte Verhalten testen, nicht Daten. Daten drücken nur das Ergebnis eines Verhaltens aus. Entsprechen die tatsächlichen (actual) Daten den erwarteten (expected) Daten, dann entspricht das tatsächliche Verhalten dem im Test erwarteten.

Nun lassen wir den neu formulierten Testcase erneut durchlaufen, mit folgendem Ergebnis:

bash$ phpunit tests/verify_test.php
PHPUnit 3.4.13 by Sebastian Bergmann.

PHP Fatal error: Class 'Verify' not found in tests/verify_test.php on line 8


Wenig überraschend beschwert sich PHP (nicht PHPUnit!), dass wir eine Klasse verwenden, die nirgends definiert wurde. Tun wir dies also, indem wir eine Datei lib/verify.php erzeugen und mit folgendem Inhalt füllen:

< ?php

Dann muss im Testcase noch sichergestellt werden, dass die Datei mit dieser Klasse auch inkludiert wird:

<?php

}


Lassen wir den Testcase nun laufen, ändert sich das Bild:

bash$ phpunit tests/verify_test.php
PHPUnit 3.4.13 by Sebastian Bergmann.

PHP Fatal error: Call to undefined method Verify::checkEmail() in tests/verify_test.php on line 9


Wir rufen eine Methode auf, die noch nicht existiert, also muss diese implementiert werden:

<?php

}


Nun steht zumindest die Codestruktur komplett, so dass PHPUnit ohne Fatals durchlaufen kann:

bash$ phpunit tests/verify_test.php
PHPUnit 3.4.13 by Sebastian Bergmann.

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.


Eine Zwischenbemerkung: Das Vorgehen ist hier natürlich sehr kleinschrittig – ob man die offensichtlichen Dinge wie das Anlegen der benötigten Klassen und Methoden nicht gleich in einem Rutsch macht, bleibt Geschmackssache. Ich persönlich habe Gefallen gefunden an dem Vorgehen, meine ganze Energie in die Tests zu stecken, und dann in einen anderen Modus zu schalten und ganz stupide Schritt für Schritt immer wieder die Implementierung anzupassen und den Testlauf neu zu starten, bis keinerlei Fehler mehr auftreten.

Wie auch immer, PHPUnit läuft nun wieder ohne PHP Fehler durch, bestätigt aber wenig überraschend, dass die nunmehr vorhandene Code-Unit nicht das Verhalten zeigt, welches wir laut Test von ihr erwarten. Wechseln wir nun also auf die inhaltliche Ebene der Implementierung und sorgen dafür, dass unser Code sich wie gewünscht verhält:

<?php

}


Nun besteht unser Testcase alle Tests:

bash$ phpunit tests/verify_test.php
PHPUnit 3.4.13 by Sebastian Bergmann.

OK (1 test, 1 assertion)


Damit wäre der erste Testzyklus komplett. Stellt sich die Frage, ob uns noch weitere Verhaltensweisen für unsere Unit einfallen, die wir von ihr erwarten. Es liegt auf der Hand, dass wir den Positivfall ebenfalls testen wollen, nämlich dass eine E-Mail Adresse mit @-Zeichen als valide erkannt wird. Natürlich würde man in der Realität noch viel mehr Ansprüche an die Validierung einer E-Mail Adresse stellen, aber in diesem Beispiel bleibe ich der Einfachheit halber unrealistisch.

Eine Faustregel der testgetriebenen Entwicklung lautet, immer nur ein Verhalten pro Test zu überprüfen, anders ausgedrückt “ein assert pro Test”. Dies hilft, die einzelnen Tests übersichtlich und nachvollziehbar zu halten, und hat auch ganz praktischen Nutzen, da PHPUnit bei der Ausgabe eines Failures innerhalb eines Tests nicht darauf hinweist, welcher assert genau nicht erfüllt wurde, sondern immer den gesamten Test als fehlgeschlagen zu melden – hat man einen Test mit 20 asserts geschrieben, wird die Fehlersuche aufwendig.

Formulieren wir also einen weiteren Test:

<?php

}


Danach sollte man allerdings, obwohl kleinschrittig, auf jeden Fall den Testcase einmal durchlaufen lassen und ihm beim Fehlschlagen zusehen: Auch beim Schreiben von Tests können Fehler passieren, und es kommt vor, dass man einen neuen Test formuliert, der wegen eines Fehlers in der Implementation oder im Test sofort erfüllt wird – geht man nach dem Schreiben des Tests sofort an die Implementation, ohne zuvor den Test einmal fehlschlagen gesehen zu haben, übersieht man möglicherweise einen Bug in der Implementation oder im Test, wenn man erst dann den Test laufen lässt und dieser dann ohne Fehler durchläuft.

Dann sorgt gar nicht die eigene Änderung an der Implementation für das funktionieren des Tests, sondern ein Bug, den man aber eben nicht bemerkt.

Also stellen wir sicher, dass unser neuer Test fehlschlägt:

bash$ phpunit tests/verify_test.php
PHPUnit 3.4.13 by Sebastian Bergmann.

FAILURES!
Tests: 2, Assertions: 2, Failures: 1.


Und nun ändern wir die Implementation, um ihn zu erfüllen:

<?php

}


Nun laufen beide Tests im Testcase erfolgreich durch:

bash$ phpunit tests/verify_test.php
PHPUnit 3.4.13 by Sebastian Bergmann.

OK (2 tests, 2 assertions)


Das hier beschriebene Beispiel ist natürlich banal, aber im Grunde ist alles Wichtige zur Methodik der testgetriebenen Entwicklung gesagt.

Aber auch in der eigenen Praxis, auch bei spannenden Projekten, wird man aber immer wieder dem Gefühl begegnen, dass der einzelne Test im Grunde trivial ist. Aber das ist auch völlig in Ordnung: Selbst komplexeste Softwareprojekte sind letztendlich die Verknüpfung kleiner und für sich betrachtet trivialer Funktionsinheiten – aber aus dem Zusammenspiel dieser vielen einfachen Module ergibt sich die Lösung komplexer Probleme für den Anwender.

Welchen Zweck erfüllt siqqel?

Die verschiedensten Leute in einem Unternehmen müssen aus den verschiedensten Gründen auf relationale Datenbanken zugreifen. Klassischerweise gibt es zwei Szenarien:

• Ich brauche eine einfache und kurze Information
• Beispiel: “Wie war noch gleich der ‘name’ des ‘product’ mit der Id 12345?” oder “Wieviele Einträge waren doch gleich in der ‘city’ Tabelle?”

Üblicherweise schmeisst man dafür direkt die SQL Kommandozeile an, oder man benutzt ein Tool wie Toad, phpMyAdmin, oder irgend einen anderen Query-Browser.

• Ich benötige eine komplexe Auswertung wichtiger Kennzahlen, inklusive historischer Betrachtung und Querverweisen, und diese brauche ich langfristig und regelmäßig
• Beispiel: “Wir müssen die Conversions unserer User auswerten” oder “Ich brauche eine täglich aktualisierte Auswertung unserer Produktverkäufe”

Üblicherweise werden hierfür komplexe und spezialisierte Enterprise-Tools wie Data Warehouses benutzt und manchmal auch selbst implementiert.

Das ist auch alles fein, und die Tools für beide Szenarien sind vielfältig und ausgereift. In der Praxis gibt es aber ein weiteres Szenario, welches sozusagen “dazwischen” liegt: Hier ein paar Beispiele:

• Die QA Abteilung soll einem Bug nachspüren und muss dafür über einen Zeitraum von einigen Tagen einige mittelkomplexe Datenanalysen fahren und diese regelmäßig aktualisieren (“zu welcher Tageszeit kommt es vor dass User aus Gruppe X auf Seite Y Aktion Z durchführen, und dann die Kombination der Daten aus Tabelle A, B, und C gleich D ergibt?”)
• Ein Produktmanager soll ein neues Feature konzeptionieren und benötigt dafür über einen sehr begrenzten Zeitraum eine Auswertung über verschiedene Business-Kennzahlen. Da die Analyse auf ganz neuen Annahmen beruht, helfen die im Data Warehouse vorhandenen Reports nicht weiter.
• Ein Softwareentwickler arbeitet an der Anbindung eines externen Webservice, und möchte während der Implementations- und Testphase alle Tabellen und die zusammengehörenden Daten, die aus Webservice-Calls resultieren, im Blick haben, ohne jedes Mal 30 einzelne Queries abfeuern und miteinander in Verbindung bringen zu müssen.
• Ein Business Analyst soll einen größeren Report vorbereiten, möchte aber erst mal ein Gefühl dafür bekommen welche Daten er benötigt und wie er diese sinnvoll miteinander verknüpfen kann.

Alle diese Beispiele haben eines gemeinsam: Die “kleine” Lösung, direkt einzelne Queries nacheinander an die DB zu schicken und die Ergebnisse dann händisch zusammenzutragen und miteinander in Verbindung zu bringen, ist zu klein, damit zu anstrengend und ineffektiv. Man kennt das, man fängt dann an sich die Queries in irgendein Textfile zu pasten damit sie nicht verloren gehen, oder man hat in Tools wie phpmyadmin plötzlich 15 Browsertabs auf und wird langsam wahnsinnig.

Die “große” Lösung ist aber wiederum zu groß:  Es lohnt in der Regel nicht, einen Business-Analysten mehrere Stunden oder Wochen mit dem Bau eines Reports aus dem Data Warehouse zu beauftragen, nur weil man wenige Tage lang etwas beobachten oder nur vorübergehend Daten debuggen muss.

Der Kompromiss sieht dann häufig so aus, dass man anfängt eine Zwischen-Notlösung auf irgend einer Insel zu bauen: Man fängt an, mit irgendwelchen ODBC Kontrukten und Excel. Schick mir so eine Excel Datei, und ich sehe nichts, denn ich habe ODBC gerade nicht richtig eingerichtet. Oder der Produktmanager, der seine temporäre, aber komplexe Auswertung braucht, bekommt eine virtuelle Maschine mit einer Basisinstallation von PHP, ein Developer gibt ihm einen Crash-Kurs in PHP-Entwicklung, und los geht das Gefrickel. Irgendwo fliegen dann diese Skripte rum, nach ein paar Monaten, wo sie vielleicht für eine neue, ähnliche Analyse noch mal nützlich gewesen wären, findet sie dann auch keiner mehr. Der PM schlägt sich mit Programmierung rum, Sysops meckert zu Recht, dass sie jetzt auch noch diese Spielkiste managen müssen, alle sind unglücklich, und irgendwo in der Ferne fängt ein kleines Kind an zu weinen.

Das muss nicht sein!

Denn genau diese Nische zwischen “einfach mal ein Query” und “das große böse komplette Data Warehouse” besetzt siqqel exzellent, ohne die Probleme der frickeligen Insellösungen einzuführen.

Wie funktioniert siqqel?

Die Mächtigkeit von siqqel liegt darin, dass es den Applikationsstack, der benötigt wird, um Anfragen an die Datenbank zu übermitteln, die Antwort entgegenzunehmen und die empfangenen Daten darzustellen, auf etwas recht bekanntes und verbreitetes beschränkt: den Browser.

SQL Queries werden direkt in einer statischen HTML Datei notiert. Per Ajax werden diese an ein zentral abgelegtes Backend-Skript übermittelt. Das Result Set wird an den Browser zurückgeliefert und direkt dort per DHTML dargestellt. Mit (D)HTML Bordmitteln, JavaScript und CSS kann man direkt innerhalb des HTML Dokuments dann beliebig flexibel mit den Result Sets arbeiten.

Richtig, ganz ohne PHP geht es nicht. Es braucht einen Punkt im Backend, welcher den SQL Query vom Browser entgegennimmt, an die DB übermittelt, und das Result Set als JSON an den Browser zurückliefert. Aber man beachte die Vorteile zur vorhin beschriebenen Insellösung:

• Das Skript wird einmalig an zentraler Stelle in der Serverlandschaft hinterlegt – zum Beispiel an dieselbe Location, an der bereits der phpMyAdmin läuft; dann hat man vielleicht sogar gleich die Frage der Zugriffsrechte erschlagen, denn (üblicherweise) haben nur die richtigen Personen im Unternehmen Zugriff auf diese Ressource, und Sicherheitsmechanismen, die für die Zugriffsicherung des phpMyAdmin bereits implementiert wurden (wie .htaccess, SSL Public Keys etc.), greifen ohne zusätzlich notwendige Handgriffe auch für das PHP Backend von siqqel.
• Nun kann jeder sofort anfangen, Reports auf Basis von siqqel zu bauen – alles was er braucht: Zugriffsrecht auf die HTTP Location des PHP Backend Skripts – und einen Browser!

Wie funktioniert das nun im Detail?

Angenommen, es gibt im Intranet eine MySQL Datenbank mit einer Tabelle, in der stehen alle Produkte des Unternehmens. Nennen wir sie ‘product’, und nehmen an sie befindet sich im Schema ‘data’. Nehmen wir weiterhin an, es gibt einen Server, auf dem wurde phpmyadmin installiert, damit man über diese Datenbank browsen kann. Dieses ist erreichbar unter unter http://intranet/secure/phpmyadmin. /secure ist der mit Zugriffsrechten versehene Teil des Servers.

Nun muss ein Systemadministrator die PHP Backendskripte unter http://intranet/secure/siqqel/ hinterlegen, und die Konfiguration anpassen um dem siqqel PHP Code Zugriff auf die genannte Datenbank zu ermöglichen.

Ein siqqel User muss dann nur eine HTML Datei erzeugen (auf seinem Desktop oder wo auch immer, ein LAMP Kontext wird ja nicht benötigt), die folgendes enthält:

<!DOCTYPE html>
<html>
<head>

</body>


Öffnet er diese Datei lokal in seinem Browser, wird das SQL Statement im Attribut der Table an das Backend Skript übermittelt, das Result Set als JSON zurückgegeben, und der Inhalt der Datenbanktabelle automatisch in das table Element gerendert.

Von hier aus hat man alle Möglichkeiten: Man möchte mehrere Tabellen auf einmal anzeigen? Man erzeugt einfach mehrere table Elemente mit den entsprechenden Queries. Man möchte alle Zeilen im Result Set, bei denen die Spalte name mit “a” beginnt in der HTML Tabelle hervorheben? Kein Problem, jede Tabelle, Zeile und Spalte liefert ein “loaded” Event, also hat man mit einem JavaScript-Konstrukt wie


$('td.name').live('loaded', function(name) {
// do something useful.
});


alle Möglichkeiten. Der Client Teil von siqqel basiert auf jQuery, also kann man schnell und einfach Reports bauen mit allen sinnvollen und sinnlosen Möglichkeiten, die jQuery bietet.

Was sind die weiteren Vorteile? Nun, die HTML Datei ist nicht nur der View des Reports, die HTML Datei IST der Report. Man kann ihn in die vielleicht vorhandenen Coderepositories im Unternehmen packen, man kann ihn per Mail verschicken, man, wenn die Wikisoftware es zulässt, seine Reports sogar direkt nativ in eine Wikiseite packen und so besonders effizient mit den Kollegen im Unternehmen teilen.

Die Projektseite von siqqel ist http://github.com/MyHammerOpenSource/siqqel. Nicht wundern, bis vor kurzem hieß das Projekt noch “sqlHammer”, der Begriff mag noch an verschiedenen Stellen auftauchen.

Bei Fragen zu siqqel empfehle ich, ein Issue Ticket bei github zu öffnen, oder wendet euch an opensource@myhammer.com.

Vorüberlegungen

Dieses Dokument beschreibt Werkzeuge und Prozesse, um Datenbankänderungen innerhalb von großen Softwareprojekten einfach, fehlerfrei und nachvollziehbar durchzuführen und zu managen.

Zentraler Ansatz dieser Lösung ist: Datenbankänderungen und Codeänderungen sind prinzipiell genau dasselbe. Denn Datenbankänderungen haben genau wie Codeänderung die folgenden Eigenschaften:

• Sie ändern das Verhalten des Softwaresystems
• Sie entwickeln sich verteilt in verschiedenen Projekten bzw. Branches, und müssen für Abnahme und Rollout/Release zusammengeführt werden
• Beim Zusammenführen kann es Überschneidungen und Konflikte geben, die man mitbekommen und lösen können möchte
• Man möchte sie auch später noch nachvollziehen können, also sehen wer wann was gemacht hat
• Man möchte diese Änderungen ggf. einem Reviewprozess unterziehen

Wenn wir Datenbankänderungen in diesem Sinne genau wie Codeänderungen verstehen, macht es auch Sinn, Datenbankänderungen genau wie Codeänderungen zu behandeln. Und das bedeutet, diese innerhalb des bereits vorhandenen Entwicklungsprozesses zu managen und im selben VCS Repository zu verwalten.

Abbildung der Datenbankänderungen im VCS

Unter Datenbankänderungen müssen wir verstehen: Alle SQL Statements, welche die Strukturen oder Inhalte einer Datenbank verändern.

Eine Datenbankänderung im Zuge eines Projekts, Bugfixes oder sonstigen Tickets ist daher folgerichtig eine Sammlung von SQL Statements, welche zusammen mit den Codeänderungen des zugehörigen Tickets im selben Branch vom Entwickler hinterlegt wird. Hinzu kommt, dass es eine klar definierte Lokalität für diese Änderung geben muss, damit ein Raum geschaffen ist, in dem Konflikte entstehen (und gelöst werden) können. So wie die gleichzeitige Änderung an der Datei myFile.txt in zwei verschiedenen, zu mergenden Branches zu einem Konflikt führt – da in beiden Branches die Datei den selben Speicherort, also dieselbe Lokalität besitzt – müssen auch Änderungen an derselben Tabelle in zwei Branches innerhalb derselben Lokalität des jeweiligen Branches stattfinden. Der vorgeschlagene Ansatz ist daher, die Struktur der Datenbank, also die Databases mit den darunterliegenden Tables, in einer analog aufgebauten Ordner-Datei-Struktur abzubilden.

Die Lokalität für die Tabelle users.hobbies wäre beispielsweise die Datei /dbchanges/users/hobbies.sql innerhalb des VCS. Abgebildet wird die gesamte DB Struktur, also alle Databases mit allen ihren Tables:


/dbchanges/users/hobbies.sql
/dbchanges/users/contact.sql
...
/dbchanges/products/colors.sql
/dbchanges/products/forms.sql
...


und so weiter. Gerade bei komplexen Datenbanken macht es natürlich Sinn, diese Struktur mit einem Skript zu erzeugen, für MySQL kann man dazu in einem beliebigen Verzeichnis auf dem DB Server folgenden Code ausführen (geht davon aus, dass die MySQL Daten unterhalb /var/lib/mysql liegen):


find /var/lib/mysql -type f -name *.frm -exec dirname {} \;| cut -d "/" -f 5| xargs mkdir -pfind /var/lib/mysql -type f -name *.frm | cut -d "/" -f 5,6 | sed "s/.frm/.sql/g" | xargs touch


Diese Dateien nenne ich im folgenden DB Change Container.

Prozessbeschreibung

Während der Produktion eines neuen Release

Wichtig ist, dass sämtliche DB Change Container nach einem Release, nachdem diese Änderungen also auf dem Produktivsystem angewendet wurden, wieder leer sind – denn zum Start der Produktion eines neuen Releases liegen noch keine neuen Änderungen für die DB vor.

Nun beginnen die Entwickler, Tickets (Feature Requests, Bugs etc.) umzusetzen, einige gemeinsam in einem Branch, einige in eigenen Branches. Sind im Zuge einer Implementation Datenbankänderungen notwendig, hinterlegt der Entwickler innerhalb des zugehörigen Branches diese Änderungen nach folgendem Muster:

• Case 1: Die Tabelle user.hobbies soll verändert werden (neues Feld, Feld löschen, Index anlegen oder löschen, einfügen, löschen oder ändern von Einträgen etc.)

  Der Entwickler legt alle benötigten Statements in der Datei /dbchanges/users/hobbies.sql ab:

  
USE users;
ALTER TABLE hobbies ADD newfield1 INT NOT NULL AFTER userId;
ALTER TABLE hobbies DROP oldfield;
ALTER TABLE hobbies ADD newfield2 TINYINT NOT NULL;
ALTER TABLE hobbies ADD INDEX (newfield2);
INSERT INTO hobbies ( id, name, value ) VALUES (1234, 'hobbyname', 'hobbyvalue');


• Case 2: Der Entwickler legt eine komplett neue Tabelle pets im vorhandenen Schema users an

  Er erzeugt dazu eine neue Datei /dbchanges/users/pets.sql und füllt sie mit dem CREATE Statement (sowie ggf. INSERT Statements):

  
USE users;
CREATE TABLE pets(
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
petname VARCHAR( 64 ) NOT NULL,
FULLTEXT ( petname )
);


• Case 3: Der Entwickler legt eine neue Database products und darin eine neue Tabelle colors an

  Er erzeugt einen neuen Ordner /dbchanges/products und darin eine Datei colors.sql mit folgendem Inhalt:
  
CREATE DATABASE products;
USE products;
CREATE TABLE colors (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
colorname VARCHAR( 24 ) NOT NULL);


• Case 4: Der Entwickler löscht die Tabelle colors in der Database products

  Er füllt die Datei /dbchanges/products/colors.sql mit folgendem Inhalt:

  
USE products;
DROP TABLE colors;


Ansonsten läuft der Entwicklungsprozess wie gewohnt.

Merge aller Tickets für den Release

Werden nun verschiedene Tickets für den Release gebündelt, werden die einzelnen Branches wie gehabt gemerged. In Hinblick auf die DB Änderungen passiert nun folgendes:

Sämtliche Änderungen in den einzelnen Branches unterhalb von /dbchanges werden naturgemäß unterhalb /dbchanges im Merge zusammengeführt. Hierbei greifen die bekannten VCS Mechanismen: Wurden Änderungen in einer Datei nur in einem einzigen Branch oder Commit vorgenommen, werden diese Änderungen einfach angewendet. Wurden Änderungen an einer Datei (also innerhalb derselben Lokalität) in mehreren Branches vorgenommen, kommt es zu einem Konflikt.

Dies ist der erste wichtige Mechanismus der hilft, die drei Anforderungen – einfach, fehlerfrei und nachvollziehbar – zu gewährleisten: Da der Konflikt garantiert eintritt, ist auch garantiert, dass der Vorgang völlig automatisch die notwendige Aufmerksamkeit erzeugt und nicht übersehen werden kann.

Nun muss, wie auch bei Codekonflikten, gelöst werden: Machen beide Änderungen Sinn, oder widersprechen sie sich? Wie genau kann man sie am sinnvollsten zusammenführen? Relevant ist hier nur, dass am Ende ein Set an Änderungsanweisungen in den Approval committet wird, welches in sich rund ist. Falls es eine eigene Test oder QA Datenbank gibt auf die diese Änderungen angewendet werden müssen, wird dies gemacht nachdem alle Tickets fertig gemerged wurden.

Durchführung des Release

Wurde im Vorfeld alles richtig gemacht, muss im Zuge des Rollout oder Release nur noch das zusammengefasste Set an Änderungen ermittelt werden, und diese müssen dann, entsprechend ihrer jeweiligen Eigenschaft, ausgeführt werden. Die Summe der Änderungen ergibt sich aus der Summe aller Anweisungen in den DB Change Containern unterhalb /dbchanges – hier macht es natürlich Sinn, dass man diese mithilfe eines Skripts “zusammensammelt”, aber ich gehe hier nicht näher darauf ein.

Nach dem Rollout/Release, und vor dem Erzeugen neuer Branches, müssen dann im Trunk sämtliche Datenbank-Änderungsanweisungen aus den DB Change Containern entfernt werden (auch hier macht ein Skript wie z.B.


for f in `find . -type f -name *.sql`; do echo -n "" > $f; done


Sinn, um diesen Schritt zu vereinfachen), und dies muss in den Trunk (oder von wo aus auch immer neue Branches gebildet werden) committet werden – denn sonst würden dieselben Änderungen beim nächsten Rollout erneut angewendet werden.

Die Verwendung von INSERT INTO … SELECT ist hier naheliegend, zum Beispiel so:

INSERT INTO Suchtabelle
 SELECT a, b, c FROM Auktionstabelle WHERE x = y

Es ergab sich folgendes Problem: Der Query wird wie jeder andere auch auf die Datenbankslaves repliziert. Dort wurde er auch korrekt ausgeführt. Jedoch nicht immer auf dem Master: hier kam es regelmäßig zu Deadlocks auf der Auktionstabelle, da dies eine InnoDB Tabelle ist (bei MyISAM Tabellen können Deadlocks nicht auftreten).

Wenn ein MySQL Slave jedoch feststellt, dass beim gleichen Query auf dem Master und auf dem Slave unterschiedliche Fehler auftreten (Slave: no error; Master: deadlock), unterbricht dieser die Replikation. Es hilft dann nur ein SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;.

Ich habe mich daraufhin nach Lösungen umgeschaut. Erste Anlaufstelle ist das Kapitel Vom Umgang mit Deadlocks im MySQL Handbuch.

Mein erster Versuch war, den 4. Tipp dieses Kapitels zu befolgen: Das Einstellen eines niedrigeren Isolationslevels. Da perfekte Datenkonsistenz für die benötigte Suchtabelle nicht nötig ist (dirty reads also akzeptabel sind), verwendete ich gleich den niedrigsten Level READ UNCOMMITED. Das Ergebnis war gelinde gesagt verheerend, es traten noch mehr Deadlocks auf als zuvor.

Deshalb bin ich dazu übergegangen, die beteiligten Tabellen explizit mit einem READ LOCK zu sperren – viele Artikel zu diesem Thema haken diese Vorgehensweise sofort als nicht gangbar ab, da die Performance darunter leide. Da es sich beim Auftragsradar jedoch um einen Cronjob handelt, der nur alle paar Minuten einmal läuft, und der INSERT INTO … SELECT Query sehr schnell durchläuft, erschien mir das Risiko, eine unserer wichtigsten Tabellen für diesen Query zu sperren, als gering.

Wie sich zeigte, brachte dies den gewünschten Erfolg: Seitdem sind an dieser Stelle keinerlei Deadlocks mehr aufgetreten, und der Rest der Plattform zeigt sich von den seltenen und kurzen Locks völlig unbeeindruckt.

Hier der Artikel:

Vergangenen Donnerstag zeigte das ProSieben Magazin Galileo einen ca. 10-minütigen Beitrag über My-Hammer (kurze Infos zur Sendung hier). Vom Ansatz her ging es um “Branchenbuch vs. My-Hammer”, aber für die Betrachtung hier ist das gar nicht so sehr von Interesse – es ist noch nichtmal von Interesse, ob so ein Beitrag positiv oder negativ für uns ist (in dem Fall war’s wie fast immer positiv) – sobald das Magazin, in dem über uns berichtet wird, genug Reichweite hat, schießen die Zugriffe in die Höhe. Die wichtigste Erkenntnis, die wir immer wieder machen: zumindest bei den Privaten scheinen die Zuschauer sprichwörtlich mit dem Laptop auf den Knien vorm Fernseher zu sitzen. Die Zugriffe kommen extrem schnell und gebündelt (beim Galileo-Beitrag war aber interessant, dass die Zugriffe wieder auf einen Schlag kamen, aber erst in dem Moment, in dem der Beitrag vorbei war).

Genau dieses plötzliche Auftreten so vieler Zugriffe ist natürlich die Herausforderung – dieselbe Anzahl User auf nur 15 Minuten verteilt wären kein Problem, aber TV sorgt dafür, dass das meiste innerhalb der ersten 5 Minuten passiert. Und es ist wirtschaftlich natürlich ziemlich unvernünftig, die für diese 5 Minuten benötigte Rechenpower anzuschaffen, nur damit sie die anderen 525.595 Minuten im Jahr vor sich hindümpelt.

Trotzdem kann man eine Webseite auch auf solche Extremsituationen vorbereiten – My-Hammer hat am Donnerstag perfekt standgehalten, lediglich eine leichte Verzögerung in den Ladezeiten war während der kritischen Phase spürbar.

Um kurz die Dimensionen klarzumachen, erstmal eine Grafik, welche den ein- und ausgehenden IP Traffic für unser Netzwerk anzeigt. Man sieht sehr deutlich den Sprung auf das gut 2,5-fache des normalen Werts. Der Faktor selbst klingt vielleicht erstmal nicht so dramatisch, aber wie erwähnt geht es nicht um die Masse an sich, sondern das extrem gebündelte Auftreten dieser Masse an Zugriffen:

(Die Grafik ist leider nicht mehr auffindbar)

Ich behaupte mal, man erkennt recht gut, wann die Sendung lief…

Also, wie kann man die Serversysteme auf so etwas vorbereiten? Klar: mehr Server kaufen. Das ist durchaus ein Aspekt, aber nicht das Allheilmittel. Vor allen Dingen kann das sehr ineffektiv und unwirtschaftlich sein. Angenommen, man hat Server A mit einer gewissen Leistungsfähigkeit. Nun kann man sich Server B mit doppelt so schnellem Prozessor, doppeltem Arbeitsspeicher und doppelt so schnellen Festplatten kaufen. Dann hat man schon Unmengen von Geld ausgegeben, und hat gerade mal eine Steigerung der Leistungsfähigkeit von 100% (mal davon abgesehen, dass die Rechnung “doppelt so schnelle Hardware, doppelt so viel Leistung” in der Praxis auch nicht wirklich hinhaut). Dagegen kann ein einziger geschickt gesetzter Index in der Datenbank manchmal 1000% bessere Performance bringen, ohne dass man etwas an der Hardware tut.

Wenn man den Anschaffungspreis neuer Hardware mal auf den Stundenlohn eines Entwicklers umrechnet, wird man schnell zu dem Schluss kommen, dass es sich auch finanziell durchaus rechnen kann, diesen einige Tage lang auf die Datenbank anzusetzen um zu schauen, ob nicht doch irgendwo ein wichtiger Index vergessen wurde oder einige Tabellenstrukturen besser ganz anders aufgebaut sein sollten.

Das sind nur ein paar grundsätzliche Überlegungen. Spürbaren Erfolg wird man nur haben, wenn man ein ganzes Bündel an Massnahmen ergreift und vor allem immer das Gesamtsystem vom Code über die Datenbank bis hin zu den Servern und dem Netzwerk im Überblick hat. Die vielleicht wichtigste Faustregel, wenn man über Performanceoptimierung von Webseiten spricht, scheint mir daher zu sein: Coder und Admins an einen Tisch! Es hilft nichts, wenn die Entwickler meinen, die Geschwindigkeit des Systems sei doch schliesslich Sache des Admins. Umgekehrt ist es extrem hilfreich, wenn die Programmierer auch einen gewissen Sysadmin-Background haben, und die Admins umgekehrt auch Programmiererfahrung haben; was bei uns glücklicherweise sogar sehr ausgeprägt der Fall ist.

Die weiteren Teile befassen sich mit den konkreten Massnahmen, die man ergreifen kann um sich auf einen TV Beitrag vorzubereiten.
Hinweis: Thematisch durchaus verwandt berichtet Tom Bachem über die Systemarchitektur von sevenload.

Welche Massnahmen kann man nun konkret ergreifen, um sich auf einen TV Beitrag über die eigene Webseite vorzubereiten? Ich versuche so allgemein wie möglich zu bleiben, aber da es um konkrete Ratschläge gehen soll und ich holprige Umschreibungen vermeiden möchte, wird das Vokabular ab jetzt etwas LAMP-lastig; bitte entsprechend auf die eigene Technik ummünzen.

Massnahme 1: Datenbankoptimierung

Wurde ja schon erwähnt: die Indizes. Ich verrate wahrscheinlich nicht einmal DB Anfängern etwas neues, wenn ich betone, dass dies essentiell ist. Wenn man die Indizes nicht im Griff hat, braucht man sich die anderen Punkte noch gar nicht anschauen. Deshalb: Ins Slow-Log gucken. Vor allem: Immer wieder. Einen Status Quo gibt es nicht! Immer wieder EXPLAIN bemühen, vom stumpf auf die Strukturen in phpMyAdmin gucken findet man die Performancefresser nicht.

Es gibt diese missverständliche Formel “Braucht man Geschwindigkeit, nimmt man MyISAM, braucht man Sicherheit, InnoDB”. InnoDB ist nicht nur einen Blick wert, wenn man Transaktionssicherheit braucht. Im Gegensatz zu MyISAM lockt InnoDB bei schreibenden Queries immer nur die betreffenden Zeilen, MyISAM dagegen grundsätzlich die gesamte Tabelle. InnoDB hat zwar aufgrund der größeren Komplexität etwas mehr “Grundoverhead”, aber das intelligentere Locking kann immens wertvoll sein in bestimmten Szenarien und das mehr als wettmachen. Wenn man eine Tabelle hat die man hinsichtlich Struktur und Indices schon perfekt durchoptimiert hat (genau das aber wiederum erstmal sicherstellen!), und trotzdem tauchen Queries auf diese Tabelle immer noch im Slow Log auf, dann sollte man prüfen, ob diese Queries vielleicht immer auf einen Lock warten. In diesem Fall InnoDB auf jeden Fall eine Chance geben. Das hat bei uns konkret bei den Session und Cachetabellen (dazu später mehr) enorm viel gebracht, weil dort die Lese- und Schreibzugriffe ein ausgewogenes Verhältnis haben.

Ein Aspekt, der wenig berücksichtigt wird, ist die Größe der Felder, auf die man Indices setzt. Es kann sich lohnen, hier sparsam zu sein, denn ein kleinerer Spaltentyp bedeutet auch weniger Speicherplatzverbrauch für den Index auf diese Spalte, und das kann im Zweifel nur gut (= schneller) sein. Man ist halt geneigt, seine Primary IDs immer als INT anzulegen. Aber nehmen wir mal den Klassiker Benutzertabelle: Wird man wirklich in nächster Zeit 4 Milliarden User haben? Das dürfte selbst bei eBay noch ein bisschen dauern. Erstmal tut es also auch ein MEDIUMINT, setzt man diesen UNSIGNED, ist das Limit bei 16 Millionen. Hat man soviele User, bewegt man sich wohl eh in völlig anderen Dimensionen.

Zumal das Umwandeln einer Spalte in einen Typ mit größerem Wertbereich (also z.B. von MEDIUMINT nach INT) unproblematisch ist. Wichtig ist allerdings auch, dass man sämtliche Felder, die einen Fremdschlüssel auf ein MEDIUMINT Feld darstellen, ebenfalls als MEDIUMINT anlegt, sonst hat man bei Joins nichts gewonnen.

Was bei der Skalierung von MySQL immer enorm hilft ist Replikation. Dazu wurde schon so viel geschrieben, dass ich mir die Wiederholung spare, nur dies: Wir fahren bisher sehr gut damit, das Balancing der Nur-Lese Zugriffe direkt in unserer Applikation zu regeln, und nicht über einen eigenen Software- oder Hardware-Loadbalancer. Da bei fast jedem Seitenaufruf der Master sowieso früher oder später konnektiert werden muss, kann man diese Verbindung auch nutzen, um MASTER STATUS und SLAVE STATUS zu vergleichen, um so ein Fallback auf den Master zu realisieren, falls alle Slaves einmal mehr als 0 Sekunden hinter dem Master zurückhängen. Was sich übrigens ziemlich gut vermeiden lässt, wenn man Master und Slaves per Gigabit statt Fast Ethernet anbindet.

Ein oft nicht wahrgenommener Vorteil von Replikation: Man kann einen Slave für’s Backup bereitstellen, auf dem man die Datenbank stoppen und auf Dateisystemebene wegkopieren kann (oder man hält nur den Slave Thread an und macht einen Dump), so dass man einen sauberen Snapshot der Datenbank hat, ohne das Gesamtsystem anhalten zu müssen.

Ein weiterer wichtiger Hebel für die Skalierung ist es, für spezielle Aufgaben jeweils eigene DB Server bereitzustellen, z.B. ein oder mehrere Maschinen nur für die Sessiontabellen, nur für Tabellen mit Cache-Inhalten, nur für Logtabellen; prinzipiell kann jede Tabelle, die nicht in Form von Joins oder Subselects zusammen mit anderen Tabellen gleichzeitig abgefragt werden muss, auch getrennt von den anderen Tabellen auf einem eigenen Server liegen. Darüber hinaus macht die Trennung von sehr verschiedenen Tabellen wie Session- und Logtabellen alleine deshalb schon Sinn, weil man dann die Datenbanksoftware für diese speziellen Aufgaben optimieren kann.

Eine praxisnahe Zusammenstellung der Massnahmen, die sich bei My-Hammer.de bewährt haben:

InnoDB vs MyISAM

Ich schrieb bereits, dass man InnoDB nicht nur dann in Erwägung ziehen sollte, wenn man Transaktionssicherheit benötigt. Eine Tabelle von MyISAM auf InnoDB umzustellen kann unter Umständen Geschwindigkeitsvorteile bringen, nämlich dann, wenn das zweite wichtige Feature von InnoDB neben der Transaktionssicherheit, das Row Level Locking, effektiv zum Zug kommen kann. Um herauszufinden, ob dies der Fall ist, kann man wie folgt vorgehen:

Mitloggen aller Queries

Wenn man für einen bestimmten Zeitraum (bei einer gut besuchten Seite reichen wenige Minuten) einmal alle Abfragen, die an die Datenbank gestellt werden, mitschreibt, kann man aus diesem Log eine Menge interessanter Informationen ziehen. Um festzustellen, ob eine Tabelle vom Row Level Locking profitieren könnte, muss man die lesenden (SELECT) und schreibenden (INSERT, UPDATE, DELETE etc.) Abfragen gegenüberstellen.

Wird aus einer Tabelle sehr häufig gelesen, die Daten in der Tabelle aber nur sehr selten verändert, dann macht das Table Level Locking von MyISAM in der Regel keine Probleme: Zwar wird bei einem UPDATE, INSERT oder DELETE die gesamte Tabelle für nachfolgende Lesezugriffe gesperrt (d.h. diese müssen warten), bis der Schreibprozess abgeschlossen ist. Aber da dies nur selten geschieht, kommt es auch selten vor, dass ein Leseprozess warten muss, so dass daraus keine spürbare Verzögerung im Gesamtsystem resultiert.

Gleiches gilt im umgekehrten Fall: Wird in eine Tabelle praktisch nur geschrieben, aber selten daraus gelesen (wie es z.B. bei Logtabellen häufig der Fall ist), dann kollidieren auch hier die “Interessen” nur so selten, dass nicht mit Performanceeinbußen zu rechnen ist.

Slow Log

Interessant sind also jene Tabellen, bei denen Schreib- und Lesezugriffe in einem ausgeglicheneren Verhältnis stehen. In welcher Relation die beiden Zugriffsarten dabei mindestens stehen müssen, damit es sich “lohnt” InnoDB einzusetzen, ist schwer zu sagen. Ein Blick ins Slow-Log von MySQL hilft hier weiter: Wenn man immer wieder bei denselben Tabellen auf langsame Queries stösst, die nicht wegen des Queries selbst langsam waren, sondern weil sie auf ein Lock warten mussten, hat man auf jeden Fall aussichtsreiche Kandidaten.

SHOW PROCESSLIST

Eine weitere Methode ist, sich einmal für einige Minuten immer wieder die Liste der laufenden Prozesse in MySQL auflisten zu lassen (SHOW PROCESSLIST). Wenn man dort immer wieder dieselben Queries sieht, deren Status Locked ist, dann weiss man wo das Problem liegt. Diese Methode mag zwar auf den ersten Blick wie ein Glücksspiel wirken, aber gerade weil man immer nur die Prozesse sieht, die zufällig gerade laufen wenn man den Befehl absetzt, fallen die problematischen Prozesse erst recht auf, die immer wiederkehren und oft vielleicht sogar während zwei oder mehr SHOW Aufrufen immer noch laufen. Meiner Meinung nach die schnellste Methode, Flaschenhälse zu finden.

Mehr zum Thema Locking gibt es im Kapitel ‘Internal Locking Methods’ des MySQL Handbuchs.

Nehmen wir also an, man hat einige Tabellen identifiziert, bei denen Queries öfter als gesund ist auf einen Lock warten müssen. Dies könnte beispielsweise eine Sessiontabelle sein (falls man z.B. PHP nutzt und die Sessionfunktionen so angepasst hat, dass diese eine MySQL Datenbank als Storage nutzen, ein ziemlich klassisches Szenario). Diese Tabelle wird bei jedem Seitenaufruf zu Beginn einmal gelesen, um die Session des aufrufenden Benutzers zu laden, und am Ende des Skripts wird der Sessioninhalt dieses Benutzers wieder geschrieben. Also ein sehr ausgewogenes Verhältnis zwischen lesenden und schreibenden Zugriffen – jeder Seitenaufruf, der gerade an dem Punkt angelangt ist, an dem die Session geschrieben wird, würde also die Tabelle sperren für sämtliche anderen Seitenaufrufe, die in diesem Moment aus der Sessiontabelle lesen möchten – das Performanceproblem ist ab einer bestimmten Anzahl von gleichzeitigen Benutzern vorprogrammiert.

Klassischerweise geht man nun so vor, dass man die Tabelle in InnoDB umwandelt und wieder einige Zeit das Slow Log oder die Prozessliste beobachtet – sinkt die Lock_Time der Abfragen deutlich, hat man einen Flaschenhals erfolgreich eliminiert.

Nun, es wäre freilich zu schön, wenn es nicht doch den ein oder anderen Haken bei der Sache gibt; zum Glück lassen sich die meisten aber zumindest einigermassen elegant umschiffen.

Eine Einschränkung von InnoDB ist beispielsweise, dass der FULLTEXT Index nicht unterstützt wird. Dies war bei My-Hammer ein Problem, weil wir eine Tabelle, die ziemlich eindeutiger Kandidat für eine Umstellung von MyISAM auf InnoDB war, in einem Teil unserer Applikation auch durchsuchen mussten, und zwar eben gerade einige TEXT-Felder, was ohne FULLTEXT Index nicht wirklich Spass macht.

Die Lösung war, die Tabelle umzuwandeln und damit in der Tabelle selbst auf die FULLTEXT Indizes zu verzichten, per cronjob aber eine weitere Tabelle regelmässig mit den Daten der Ursprungstabelle zu füllen. Geschrieben wurde in diese Tabelle nur durch besagten Crobjobs, ansonsten fanden ausschliesslich Lesezugriffe statt, womit MyISAM wieder die perfekte Wahl war – und wir hatten unsere FULLTEXTs wieder. Schöner Nebeneffekt: durchsucht werden müssen eh nur eine Untermenge aller Zeilen der Ursprungstabelle, und es müssen auch nicht alle der (recht zahlreichen) Spalten in die Suchtabelle übertragen werden.

Dadurch konnten wir nicht nur das Lockingproblem der ursprünglichen Tabelle lösen, sondern aufgrund der schlankeren Datenbasis in der Suchtabelle die Suche deutlich beschleunigen.

Wichtig ist jedoch: diese Lösung ist nur möglich, weil wir in diesem Fall darauf verzichten können, auf absoluten Livedaten zu suchen.

Meiner Erfahrung nach kann man zusammenfassend sagen: Es gibt nur eine einzige Massnahme, die mehr Performance bringt als Caching, und das ist noch mehr Caching. Das gilt, um mal zum Haupthema zurückzukehren, vor allem in Bezug auf Performance bei plötzlichen Besucheranstürmen.

Statische Inhalte

Wenn man einen TV Beitrag über die eigene Plattform überleben will, dann gibt es nichts, aber auch wirklich gar nichts Wichtigeres als dies hier: Die Startseite der Plattform ist eine statische HTML Seite. Und zwar in aller Konsequenz, was heissen soll, dass der Aufruf der Seite nicht nur keine Datenbankverbindung zur Folge hat, sondern dass noch nicht einmal der PHP Interpreter auch nur gestartet wird. Die Startseite von My-Hammer ist eine .html Seite, die im Gegensatz zu den .php Seiten per Apache-Konfiguration mod_php noch nicht mal von Weitem zu sehen bekommt. Selbiges sollte konsequenterweise auch für alle JavaScript und CSS Dateien, die von der Startseite eingebunden werden, gelten. Ob man hierfür nun mit Proxylösungen arbeitet oder Seiten regelmäßig vorgeneriert, ist Geschmackssache.

Man darf nie den Performancevorteil reinen HTMLs unterschätzen – selbst wenn sich die Datenbanken schon alle verabschiedet haben und die Webserver bereits richtig unter Dampf sind: Eine HTML Seite auszuliefern schafft sogar ein Webserver, der schon ziemlich am Ende ist. Und man wahrt vor allem noch am ehesten sein Gesicht, wenn die ganzen neuen Benutzer, die aufgrund des TV Beitrages neugierig geworden sind, zumindest die Startseite zu sehen bekommen. Was immer man neben der Startseite noch an Seiten statisch vorgenerieren kann, ohne dass der angebotene Dienst selber “statisch” wird, sollte man natürlich machen (denn wie oft ändern sich schon Seiten wie Über uns?). Hierbei macht es Sinn, sich mithilfe der Zugriffsstatistiken einmal anzuschauen, welchen Weg neue Benutzer in der Regel auf der Plattform nehmen, um so auch wirklich jene Seiten zu cachen, die bei einem Ansturm am ehesten angesurft werden.

Eine dynamische Seite als statische Seite vorzugenerieren ist dabei natürlich die konsequenteste Version von Caching, aber nicht immer praktikabel. My-Hammer nutzt eine zweite Stufe des Cachings, bei dem zwar weiterhin dynamische Seiten ausgeliefert werden, diese aber ganz oder teilweise in dedizierten Cache-Backends (wir nutzen dazu memcached) abgelegt sind, um Ergebnisse teurer Datenbankabfragen, die nicht immer absolut live zur Verfügung stehen müssen, zwischenzuspeichern. Diese zwischengespeicherten Einträge können zum einen nach einer gewissen Zeit ablaufen und werden dann neu aus der Datenbank erzeugt, oder können gezielt als “dirty” markiert werden, wenn die Datenbestände die sie widerspiegeln sich ändern.

Wie oben erwähnt kann es sich außerordentlich lohnen, diese Cacheinhalte auf dedizierten Maschinen bereitzustellen – was wiederum deutlich zeigt, dass manche Massnahmen zur Performancesteigerung bestenfalls halbgar sind, wenn Admins und Programmierer nicht zusammenarbeiten.

Everybody needs a 304

(oder: Wie ich dem Browser des Users helfe, optimal zu cachen)

Bisher bin ich lediglich auf ein Ziel von Performanceoptimierung eingegangen – zu verhindern, dass die eigenen Server zusammenbrechen, wenn’s mal brenzlig wird. Man muss sich aber unbedingt bewusst machen, dass Optimierungen auf dem Server erstmal keinen Wert an sich darstellen, sondern nur dem eigentlichen Ziel dienen: dem User die Benutzung der eigenen Seite so schnell und angenehm wie möglich zu machen – indem die Seite grundsätzlich erreichbar bleibt, und indem die Seite sich so schnell wie möglich aufbaut.

Wenn man sich das erstmal bewusst gemacht hat, ist auch klar dass es sich sogar lohnen kann, etwas Rechenzeit auf dem Server zu investieren, um sie dem Client (also Browser) abzunehmen.

Aber der Reihe nach. Es gibt ein wichtiges Hilfsmittel, um den Aufbau einer Webseite im Browser deutlich zu beschleunigen (abgesehen von den üblichen Massnahmen wie geringer Dateigröße, möglichst wenig eingebetteten Objekten etc.), und das ist die Verwendung des HTTP Status 304 Not Modified. Diesen kann der Server senden, wenn er anhand der Anfrage des Clients erkennt, dass exakt der Inhalt, den der Browser bereits in seinem Cache hat, nochmal über die Leitung wandern würde – in diesem Fall sendet der Server diesen Inhalt dann eben nicht nochmal, sondern teil dem Browser nur mit, er möge auf den Inhalt seines Caches zurückgreifen.

Dies kann zu erheblichen Performancesteigerungen auf Seiten des Clients führen, denn die Zeit die zum Download des Inhalts einer Seite benötigt wird, entfällt.

Es gibt nun zwei Faktoren, die das Status 304 Handling beeinflussen und spezielle Anpassungen erfordern, um optimales Clientcaching zu ermöglichen: Die Auslieferung von Seiten über PHP Skripte (gilt prinzipiell auch für andere Skriptsprachen) und der Betrieb einer Plattform in einem Webserver-Cluster.

Zuerst zu letzterem: Um in der gegenseitigen Kommunikation festzustellen, ob ein Inhalt vom Server neu ausgeliefert werden muss oder der Browser den Inhalt aus dem eigenen Cache lädt, gibt es den sogenannten Etag. Ein ganz kurzer Abriss, wie die Verwendung abläuft. Der Client fragt eine Ressource beim Server an. Es ist der erste Zugriff innerhalb dieser Browsersitzung, deshalb schickt der Client kein Etag mit. Der Server sendet daraufhin die Inhalte aus, und schickt in den Headern den Etag des aktuellen Inhalts dieser Ressource mit, sagen wir “12345″ (der Server schickt dazu den Header Etag: “12345″).

Fragt der Client nun erneut dieselbe Ressource beim Server an, schickt er in seinen Headern wiederum die Information mit, dass er in seinem Cache bereits die Inhalte mit dem ETag “12345″ gespeichert hat, und der Server ihn informieren möge falls sich die Inhalte nicht geändert haben (der Client schickt dazu den Header If-None-Match: “12345″). Der Server kann dann schauen, ob die Inhalte die er ausliefern würde immer noch das ETag “12345″ haben, und in diesem Fall den erwähnten HTTP Status 304 senden, oder, falls Inhalt und ETag nicht mehr zueinander passen, den neuen Inhalt schicken.

Die Frage ist nun: Wie genau ist denn definiert, was im Etag steht? Nun, im Prinzip gar nicht. Es gibt kein vorgeschriebenes Format, wichtig ist nur die Definition des Etag an sich: dass nämlich ein eindeutiges Etag zu einem eindeutigen Inhalt einer bestimmten Ressource gehört, und deshalb festgestellt werden kann ob sich der Inhalt einer Ressource zwischen zwei Requests geändert hat oder nicht. Man kann sich den Etag deshalb der Einfachheit halber als Checksumme des Inhalts vorstellen (und in der Tat besteht eine Möglichkeit den Etag zu generieren darin, z.B. die MD5 Summe des Inhalts zu berechnen).

Woher kommt der Etag? Beim Apache ist es Teil der Kernfunktionalität, für eine angeforderte Ressource den Etag zu berechnen und mitzusenden, sowie entsprechend zu reagieren wenn ein Client den If-None-Match Header sendet. Alles out-of-the-box also, aber genau hier liegen für uns die Probleme:

Problem 1: Defaultmässig berechnet Apache den Etag für eine Ressource, indem eine Art Quersumme aus diesen Informationen generiert wird: I-Node-Nummer der angefragten Datei, letzter Änderungszeitpunkt (mtime) der angefragten Datei, und Größe der angefragten Datei. Betreibt man eine Webseite auf nur einem Server, hat man kein Problem, denn wenn z.B. die Datei /index.html zwischen zwei Aufrufen nicht verändert wird, hat sie bei beiden Zugriffen denselben Etag, da keiner der drei Faktoren inode, mtime, size zwischenzeitlich verändert wurde.

Betreibt man aber einen Cluster aus mehreren Webservern, und besteht die Möglichkeit, dass ein Client bei zwei aufeinanderfolgenden Aufrufen derselben Ressource zuerst auf einem Webserver, beim zweiten Aufruf aber auf einem anderen landet, dann ist, auch wenn auf beiden Servern die exakt gleiche Datei liegt, der Etag beide Male ein anderer, denn selbst wenn letzter Änderungszeitpunkt und Größe der Datei auf beiden Servern identisch sind: dass die I-Node-Nummer die gleiche ist, ist praktisch ausgeschlossen. Der Server wird also keine 304 Status senden, obwohl er es könnte.

Abhilfe ist zum Glück sehr einfach möglich, und lohnt sich schon beim Wechseln von einem auf zwei Server: Man muss dem Apache mitteilen, dass er die I-Node-Nummer nicht mehr zur Berechnung des Etag heranziehen soll. Dies erledigt an zentraler Stelle die Anweisung FileETag MTime Size. Mehr dazu im Apache Handbuch.

Problem 2: mod_php hebelt die Verwendung von Etag für PHP Skripte aus. Das macht ja prinzipiell auch Sinn: selbst wenn die Skriptdatei /index.php sich zwischen zwei Aufrufen inhaltlich überhaupt nicht geändert hat, kann sie dennoch völlig unterschiedliche Inhalte an den Client ausliefern – genau das ist ja Sinn und Zweck des Einsatzes von dynamischen Seiten.

Trotzdem kann es Sinn machen, dass der Server den Status 304 an einen Client sendet, wenn dieser dieselbe Ressource erneut anfragt. Zum Beispiel bei CSS Skripten, die von jeder Seite der Plattform eingebunden werden, und aus programmiertechnischen Erwägungen als PHP Skripte realisiert sind, aber deren Inhalt sich trotzdem sehr selten ändert. Jeder Seitenaufruf würde den Browser veranlassen, dies referenzierte CSS Datei anzufragen, und der Server würde jedes Mal den Inhalt senden, obwohl sich dieser seit dem letzten Aufruf nicht geändert hat. Das macht den Seitenaufbau im Client langsam, und ist zudem eine Ressourcenverschwendung.

Wie kann man nun sicherstellen, dass ein Client den 304 Status auch beim Abruf von PHP Skripten erhält, falls sich der Inhalt nicht verändert hat, aber auch auf keinen Fall einen 304 Status bekommt, falls der Inhalt sich geändert hat? Die Lösung ist leider nicht ganz so trivial wie beim ersten Problem, aber doch vergleichsweise einfach zu realisieren.

Da wie erwähnt der Zustand der Skriptdatei selbst praktisch keine Rolle spielt, darf man nur mit dem von diesem Skript auszuliefernden Inhalt arbeiten. Eine Lösung wäre, bei den Skripten, für die man den Etag Mechanismus einsetzen möchte, folgenden Code ans Ende anzuhängen (lässt sich natürlich einfach in eine zentrale Funktion kapseln):

<?php
$output = ob_get_clean(); // Gesamte Ausgabe, die an den Client gesendet werden soll, abfangen und zwischenspeichern

if ($_SERVER['HTTP_IF_NONE_MATCH'] == $etag) // Wenn ja, dann sende nur den Status 304
{
header(‘HTTP/1.x 304 Not Modified’);
header(‘Etag: ‘.$etag);
die();
}
else // Wenn nicht, dann sende den Inhalt inkl. des neuen Etags
{
header(‘Etag: ‘.$etag);
echo $output;
die();
}
?>


Voraussetzung ist dafür die Verwendung von output buffering.

Eines muss man ganz klar festhalten – für den Server fällt exakt dieselbe Arbeit an, egal ob der User den Inhalt schlussendlich zugesendet bekommt oder nur die lapidare Meldung, er möge doch auf seinen Cache zurückgreifen. Es mag nach deutlich zuviel Overhead aussehen, PHP soviel Arbeit erledigen zu lassen, nur um das Ergebnis dieser Arbeit dann wegzuschmeissen; aber der Effekt auf die Lade- und damit Seitenaufbauzeiten beim Client ist wirklich beeindruckend, wenn man diesen Mechanismus geschickt einsetzt.