• *Très* rapide présentation de ma personne, d'OW et de PostgreSQL chez OW
• Présentation de Cityvox et panorama de la galaxie des sites Cityvox

• Il s'agit d'une migration complète de Apache/Vignette/Oracle vers PHP/PostgreSQL
• Pourquoi cette migration ? Quels enjeux ?
• Pourquoi PostgreSQL ?

• Migration de la base pénible car peu d'outils
• Migration du schéma
• Migration des données, extraction des photos de la base
• Problèmes rencontrés
• Quels composants aujourd'hui pour faciliter ces migrations ?

• Réécriture des requêtes
• Prise en main par le client
• Ce qui a marqué le client lors de sa prise en main

• Avant / Après
• Ensemble des composants Open Source mis en oeuvre

• Janvier 2005
• Un succès total

• Problème de scalabilité de la version 7.4 sur les architectures quadri Xeon : très difficile à quantifier jusqu'à la mise en orbite du site pour la St Valentin 2006.
• Explosion du site suite à la lenteur de certaines requêtes : manque de visibilité sur ce qu'il se passe sur la base : quelles requêtes posent problèmes ? Comment diagnostiquer ?
• Le cache du site était sous forme de fichiers / serveur : problème de scalabilité. On éteignait des serveurs pour mieux tenir la charge…
• SPOF sur la base de données - on se repose sur les sauvegardes

• Migration vers la version 8.1 : une seconde jeunesse
• Quelques rapports PQA, Thomas Favier d'Accelance MSP contribue à permettre l'usage de PQA sur des sites à forte charge. Réécriture complète de PQA sous la forme de pgFouine afin d'en régler les problèmes structurelles : industrialisation de la génération des statistiques
• Mise en place de Memcached pour avoir du cache distribué (avec quelques ratés)
• Mise en place d'un serveur PostgreSQL en standby

• On commence à voir apparaître de grosses lenteurs sur le site sans croissance du nombre de visiteurs (mesure estat)
• Aucun problème de lenteur spécifique
• Difficulté à analyser les logs de par leur taille et la diversité des URLs (AWStats et Webalizer ont du mal) → peu de visibilité
• Après quelques temps, on se rend compte que c'est Google qui génère un trafic énorme
• Décision de mettre en place un serveur web et un réplicat quotidien de la base de données dédiés à Google
• Dommage qu'on ne puisse accéder en lecture au serveur en standby…

• Requêtes géographiques : on met en place cube et earthdistance : mieux mais pas totalement satisfaisant car répartition très inégale et statistiques constantes
• Recherche plein texte dans le backoffice : quelques essais sont faits avec tsearch2 mais complexe à maintenir (les joies des migrations de contrib/) et toujours en dessous de Lucene

• de garantie…
• de performances principalement au niveau de la base de données
• de flexibilité et de capacité à maintenir une plate-forme qui a beaucoup évolué en 3 ans (principalement au niveau des applications périphériques)
• bon timing pour le passage en 8.3 qui promet beaucoup

• on a beaucoup appris en 3 ans, on en profite pour régler tous les problèmes structurels :

1. utilisation des delay_pools de Squid 2.6 pour canaliser les robots d'indexation : plus de serveur dédié et de base dédiée (manque de test lors des mises en production de nouveaux sites, *..)
2. recentralisation de tous les sites sur les serveurs frontaux principaux : plus de fiabilité mais aussi plus de connexions parallèles
3. utilisation de vservers pour contenir toutes les applications périphériques
4. mise en place de toutes les bonnes pratiques PostgreSQL du moment

• en 3 ans, PostgreSQL s'est très industrialisée
• mise en place de l'autovacuum
• mise en place de phpPgAdmin
• mise en place de pgBouncer (merci Skype) pour limiter le nombre de

connexions à la base

• mise en place de walmgr (Skytools, merci Skype) pour gérer le warm standby
• mise en place de PostGIS pour les requêtes géographiques

1. l'ensemble en packaging RPM

• étalée sur plusieurs mois en amont de décembre (date de sortie prévue)
• détection de régressions au cours du cycle de test, régressions très

vite corrigées (je donnerai le détail)

• le retard de la sortie de la 8.3 ne nous arrange pas…
• mise en production le jour de la sortie de la 8.3, sécurisée par toute

la phase de test amont

1. importance de cette démarche de test au cours de la phase de

développement

• mise en place de Solr (serveur de recherche basé sur Lucene interrogeable en HTTP) pour adresser le besoin fonctionnel de recherche full text et proposer des moyens de navigation différents différents
• forcément moins intégré à la BDD que tsearch2 mais état de l'art en ce qui concerne les fonctionnalités de recherche (faceting, recherche approximative…)

• grande réussite en terme de performances, fiabilité, administrabilité de la plate-forme
• PostgreSQL 8.3 est une grande release !

• PostgreSQL a été le bon choix : tout au long de ces années, les nouvelles versions ont permis d'absorber la croissance du trafic
• La confiance du client a été un des facteurs clés de réussite (choix initiaux, confiance dans la mise en production de la 8.3…)
• La communauté PostgreSQL est une richesse : implication, disponibilité, qualité des échanges…
• Elle a produit en 3 ans énormément d'outils de qualité permettant de régler des problèmes concrets.