Obviously, the technology matters. This isn’t the place for details, but apparently the winning mix includes dynamic languages and Web frameworks and TDD and REST and Open Source and NoSQL at varying levels of relative importance.

More important is the culture: iterative development, continuous refactoring, ubiquitous unit testing, starting small, gathering user experience before it seems reasonable. All of which, to be fair, I suppose had its roots in last decade’s Extreme and Agile movements. I don’t hear a lot of talk these days from anyone claiming to “do Extreme” or “be Agile”. But then, in Web-land for damn sure I never hear any talk about large fixed-in-advance specifications, or doing the UML first, or development cycles longer than a single-digit number of weeks.

But what Tim explains in the rest of his post is the controlled environment versus the wild forest. Many big software projects have been conceived in a controlled environment where everything is stable, where the odds are unlikely to happen. That said when you deploy software and are being confronted with the real traffic, with the awkward decisions of users with regards to your product, you are stepping in a wild directory, very wild. You have to be alert. You have to be able to be reactive. Things will not be perfect. It will be an iterative process. Tim Bray continues

The point is that that kind of thing simply cannot be built if you start with large formal specifications and fixed-price contracts and change-control procedures and so on. So if your enterprise wants the sort of outcomes we’re seeing on the Web (and a lot more should), you’re going to have to adopt some of the cultures and technologies that got them built.

The emphasis are mine. In the world of a Web agency, these are harder to put in place than a startup. It’s a triangle story. There are the product developed by the agency, the requirements of the client, and the contract with a limited budget.

If you are developing a traditional Web site with a CMS and a very limited user interaction, no social features, then you are in a safe zone. But if you are mandated to develop a very interactive Web site such as a social network, then you enter in a turbulent field. Either, the budget doesn’t scale or the philosophy around the project is awkward.

There is a very difficult balance to achieve. Doing it right and simple often conflicts with the desire of many features, because the budget seems too important for only one feature.

In twitter, for a very long time, there was one feature, only one feature. They have a team of more than 50 persons, They refactor their code all the time. They have have made big changes in the architecture a few times. Optimization and refactoring are part of the project, you have to plan and discuss it with the clients forefront to not have them surprised during the project.

Developing a social network is hard. It is a territory of unknowns. It is a jungle, where you might have to change the strategy a few times before getting it right. But the more, you pack your shoulders with features, with options, the more you set yourself in a lot of difficulties and budget explosion.

En plus du projet Groupes plusieurs projets d’améliorations sont constamment en cours sur le Grand Club et nous permettent de l’améliorer à chaque semaine. Voici en gros le travail qui a été fait dans les dernières semaines afin d’améliorer la stabilité et la performance du Grand Club face à la demande toujours grandissante des usagers.

Le language: Ruby Enterprise Edition 1.8.6
La version ‘Enterprise’ de Ruby permet d’améliorer les performances générale du language et de corriger certaines défaillance de celui-ci. Oui, nous pensons déjà à le changer pour Ruby Enterprise 1.8.7….

La Fondation: Ruby On Rails
Nous avons passé à la version de Rails de 2.1.0 à 2.2.2 et nous comptons encore la changer pour la version 2.3.4 afin d’améliorer encore la performance de Rails.

Database Performance:
Plusieurs requêtes ont été optimisés. Notre façon de faire les requêtes avec Rails (ActiveRecords) a également été revue afin d’être plus optimal.

Caching: Squid
Squid est un proxy permettant de cacher les images, les css et les javascripts. Ceci nous permet de servir les pages plus rapidement. Il est également prévu de se servir de memcache pour cacher les pages du Grand Club afin de les servir plus rapidement encore.

Moteur de recherche: Caching, Ferret Vs Sphinx
Nous avons changer la façon de faire les recherches lors de certaines recherches en modifiant et optimisant les requêtes. De plus, les résultats de recherches sont maintenant caché pendant un certains temps. Par le passé, nous avons expérimentés plusieurs problèmes avec l’instabilité du moteur de recherche Ferret. C’est pour cette raison qu’un projet nous permettant de tester et d’implanter Sphinx (un autre moteur de recherche) a été mis sur pied. La dernière étape dans les tests sur Sphinx sera mise en place dans les prochaines semaines. Si les tests vont bien nous serons en mesure d’implanter ce nouveau moteur de recherche.

Dark Release:
Le principe de Dark release nous vient de Facebook. Il consiste à mettre en ligne graduellement des nouveaux features. Cette technique nous permet de suivre plus facilement les réactions de l’application et des serveurs. Une subite montée en charge dû à un nouveaux features est ainsi mieux contrôlé. Ce mécanisme nous permet également de couper temporairement un feature afin de supporter une charge plus grande. On pourrait par exemple couper le lifestream, lors de la journée des transactions afin d’avoir un gain en performance.

Ceux qui ont contribué à rendre tout cela possible Benoît, Martin, Amirouche, Louis, Marc-Antoine, Ana, Yves, Sébastien, Daniel et moi-même Jean-François.

Le site Web a un gros trafic et de nombreuses interactions. Sur les billets, il y a des compteurs de vue. À chaque fois qu’un billet est accédé le nombre de vues est incrémenté dans la base de données de la façon suivante.

1. Lecture du nombre de vues dans la base de données
2. Incrémentation dans l’application Rails
3. Écriture dans la base de données

Le problème est lorsque le trafic devient important plusieurs processus concurrents lisent la valeur de la base de données actuelles, exemple: 42. Tous ces processus incrémentent la valeur à 43 et donc tentent d’écrire la même valeur dans la base de données. Le nombre de vues est donc inexact. La correction a été faite en changeant simplement le processus.

1. À chaque lecture de la page, demander à la base de données d’incrémenter la valeur par un.

C’est une erreur simpliste, mais corrigée. Il reste cependant un problème qui est cette fois ci de performances. L’incrémentation de la valeur dans la base de données représente une écriture.

Louis Asselin et Olivier Théreaux sont en recherche de solutions pour trouver un meilleur système utilisant possiblement un daemon de compteur, peut-être avec memcache. À suivre.