Yann "Bug" Dubois

J’ai eu l’occasion d’expliquer dans différents articles précédents l’utilité d’un système de cache d’opcode pour contribuer à améliorer de façon très substantielle les performances d’un serveur d’application web en php5. Vous pouvez notamment lire ce que j’en dis dans l’article sur l’optimisation (accélération) de WordPress, et apprendre ici comment monter une configuration LAMP sous Debian à partir de zéro, incluant eAccelerator. Enfin, cet article explique comment re-compiler eAccelerator pour l’installer ou le mettre à jour. Je vais maintenant aborder le sujet de l’optimisation de l’utilisation de la mémoire RAM pour tirer pleinement partie du gain de performance procuré par le cache d’opcode.

Le serveur web Apache reste le serveur d’application http de premier choix pour le PHP5, du fait de sa grande fiabilité, de son ancienneté, et de ses performances éprouvées y compris pour des fortes charges sur des serveurs de production en environnement distribué. Sa grande sophistication et la complexité de certaines configurations utilisant de nombreux modules optionnels en font en revanche un grand consommateur de mémoire RAM, ce qui est moins problématique qu’auparavant sur des serveurs modernes. Il reste qu’Apache en solo n’est désormais plus la meilleure solution pour des sites web pour lesquels les performances ultimes sont recherchées. Je vous propose ici une architecture combinant Apache, eAccelerator et NginX sur un même serveur dédié qui apporte un excellent rapport performances/simplicité de maintenance et d’installation.

En septembre 2009, j’avais écrit un tutoriel détaillé sur la configuration d’un serveur dédié OVH qui a remporté un grand succès. Aujourd’hui, il est temps de remettre à jour ce guide alors que la version 6 de Debian (intitulée “Squeeze“) est disponible en version stable depuis quelques mois. En gardant la procédure initiale comme référence, je présente ci-dessous une version adaptée à une configuration sous Debian 6/64 bits.

Les serveurs dédiés OVH (Kimsufi et autres NS / SP / EG / MG / HG) sont livrés pré-installés avec le système d’exploitation de votre choix. Je ne saurais que recommander la distribution Debian 6 64 bits pour une utilisation professionnelle, et notamment pour un hébergement sans prise de tête d’outils web standards tels qu’un CMS. Etant spécialiste WordPress, c’est la configuration de choix que je recommande pour l’hébergement de cet environnement de publication dans un usage professionnel. Pour des raisons étranges, le partitionnement proposé par défaut par OVH pour ses serveurs dédiés ne correspond pas à la meilleure solution pour un serveur web. Cela ressemble plutôt à un partitionnement adapté pour une station de travail personnelle. Voici comment y remédier.

Le système du “clearfix” est une astuce bien connue des intégrateurs web pour résoudre le problème des éléments dans une page HTML qui ont tendance à se chevaucher parce que certains contenus flottants “débordent” du bloc censé les contenir. Sans entrer dans les détails, certains blocs de contenus ne “prennent” pas automatiquement la taille des éléments qu’ils contiennent, ce qui cause (en apparence) le non-respect des marges entre éléments adjacents.

Voici une “bonne” façon de limiter la hauteur d’un bloc de texte, y compris pour le réduire à une simple ligne. Elle passe par l’utilisation de plusieurs propriétés des feuilles de styles intéressantes, mais sinon méconnues, en tout cas largement sous-employées. Le tout en CSS “pur”, sans faire appel au javascript ni au PHP. Exemples.

Lire la suite »

La plupart des sites web nécessitent qu’une ou plusieurs personnes puissent intervenir pour modifier le contenu des fichiers et répertoires qui constituent le code du site web. Cela est vrai aussi bien pour les sites les plus simples constitués de pages statiques, que pour les sites les plus sophistiqués construits à partir de CMS comme WordPress et autres frameworks.