It’s been quite a long time I’ve been playing with varnish, but only a couple of weeks using it with real traffic (> 1000 req/s) on wat.tv.
On a small site (like ipersec), varnish works fine “out of the box”, and there is little need to tune, but one a large one, tuning is really needed.

I have been using lighty for a long time, as a non-caching proxy in front of my apache servers, in order to handle persistant HTTP connexions (because apache sucks at it). I now have (nearly) completly switched to varnish, in order to get caching and ESI.
The first thing I noticed is that, without caching or with a small cache ratio, varnish is less efficient than lighty. Server load gets higher, for the similar traffic. You really need to cache if you want to get the most out of varnish.

Needing to tune the cache, I dwelved a little in the source code. Let me explain what it teached me.
Read the rest of this entry »

Building a simple HA MySQL setup is pretty straightforward. In my setup, I used master-master replication, with only one server being active at a given time (the primary node), the other one being a backup.

• When in nominal mode, the application writes to the primary server, and data is replicated to the backup server.
• When a failure occurs on the primary server, the application should switch to the backup server, and changes will be replicated by the primary server when it will be coming back alive.

Read the rest of this entry »

I just switched ipersec to a new server platform (two quad core servers, each with 4GB RAM).
My plan is to build a HA platform (mainly active/passive). The two servers aren’t on the same network, preventing me from using heartbeat (there might be a trick, but my knowledge of heartbeat is quite low, so I won’t even try).
This platform is based on :

• DNS (active/active)
• varnish : a hi-speed HTTP accelerator (active/active),
• apache/PHP (and Ruby On Rails later) (active/passive),
• memcached (active/active),
• MySQL (active/passive setup using master-master replication) with MySQL proxy (yes, I know it is still alpha).

I still have some work on the servers (replicating the code, installing mysql proxy, …). I’ll give you more information in the coming weeks…

Why I don’t like PHP

After having spent quite a few years programming PHP (from functional to OO programming), I just realized I don’t really like this language. The main problems I think are with PHP being :

• The lack of consistency : functions not always follow the same naming conventions (underscore, no undescore), and, more important, parameters are not always in the same order ($haystack, $needle or $needle, $haystack ?)
• The lack of universality : PHP only really works in web-only environments (ie : using mod_php or FastCGI). But sometimes you would like to write daemons, servers (ie to asynchronously process data), and this is nearly impossible to do in PHP. The main reason : the memory footprint of any typical PHP program is too high (due to the lack of garbage collection or to memory leaks). I’m still amazed that PHP 5.2.6 just fixed a “huge memory usage” bug in string concatenations (!!!).

You can also add many less generic problems (ie : the fact that certain errors cannot be catched), but the list would be too long for this post.

Looking for an alternative

I spent a few days looking for an alternative that would :

• be as productive as PHP (or better) - forget Java, or any other compiled languages like D
• have a nice classical OO syntax - forget erlang & other
• have a large user base and a nice framework
• and of course cool

The two main languages that looked interesting were Ruby and Python (no tcl, sorry, anyone remember struggling with Vignette ?).

• productivity: Python and Ruby look both good. Ruby might have a slight edge if you’re in the pure OO camp
• OO syntax : Ruby IMHO is a clear winner : a nice, elegant pure OO syntax. Python is lacking real OO functions (it reminds me of PHP4), and I really don’t like the indentation-based syntax (I always have problems finding when a function finishes)
• user base and framework : both languages have a large user base, and nice frameworks (ie Django for Python or Rails for Ruby)
• coolness : Ruby wins easily this one (I really love the OO model, and really dislike the indentation-based syntax of Python)

The decision would have been pretty easy without Ruby’s little problem : performance. Where Python is pretty fast for a scripting language, Ruby 1.8 (aka MRI) really sucks (Ruby 1.8 is 2 to 3 times slower than PHP). Any twitter user has noticed that scaling a ruby website is not an easy task.
Yet there is a huge amount of work done by the community to address this problem : the recently-released Ruby 1.9 is nearly as fast as PHP, and a handful of alternative VM (JRuby, Rubinius, …) are getting better and faster every day. I bet that, in 2009, Ruby will be on par with Python.

You can expect to see some Ruby or Rails articles in the coming month…

Me voici de retour après une longue absence loin d’ipersec (mais bien active par ailleurs).
En attendant de reprendre la publication de nouveaux articles techniques, voici quelques conseils de lecture hors-sujet :

• Le blog de Maître Eolas, où officie un avocat qui ne manque pas de verve
• Si la sécurité (au sens large) est votre dada, n’oubliez pas le blog de Bruce Schneier (en anglais) - ne le lisez pas si vous voulez conserver une totale confiance dans la sécurité des aéroports

Les deux derniers parlent de web, sans se tenir à des considérations techniques (d’où le hors-sujet) :

• Le blog de Fred Cavazza parle de web 2.0, d’ergonomie, et de tout plein de choses intéressantes du même genre
• L’incontournable TechCrunch, l’actualité du web 2.0

Bonne lecture !