L’organisation du serveur

Pour la suite de l’article, nous vous situons l’organisation de notre serveur.

• Nos dépôts SVN : /var/svn-repos/
• Nos répertoires web : /var/www/
• Nos dépôts Trac : /var/trac/
• Les éléments statiques : /var/trac/deploy (géré par trac-admin)
• Nos binaires spécifiques /var/trac/bin/

La timeline

Situation

La timeline est sûrement la page qui consomme le plus de ressources. Sur cette page se trouve l’ensemble de l’activité du trac, commits svn compris.

Par défaut elle est sur 30 jours ce qui est un peu trop sur un projet comme la zone qui génère plusieurs dizaines de commits par jours. De plus il est possible d’effectuer une recherche sur une période de 90 jours d’activité.

Résultat, nous avions 1 fois sur 2 la page qui bloquait lors des accès à la base de données.

Solution

Pour limiter les incidents sur cette page, comme le préconise la page performance de Trac, nous avons limité l’affichage par défaut au 5 derniers jours et autorisé une recherche maximale sur un mois.

sudoer~: nano /var/trac/spip-zone/conf/trac.ini

[timeline]
changeset_show_files = 0
default_daysback = 5
max_daysback = 30

Mapper les ressources statiques

Situation

Par défaut l’ensemble des données est géré par Trac. Les éléments statiques tels que les images, javascript, feuilles de style, ... passent par python.
On configure apache pour que celui-ci se charge directement de ces données comme l’explique la documentation Trac

Solution

Pour obtenir les fichiers statiques nous utilisons la commande trac-admin deploy.
sudoer~: trac-admin /var/trac/spip-zone/ deploy /var/trac/deploy

Nous mettons à jour notre Virtualhost en mappant les éléments statiques.

sudoer~: nano /etc/apache2/sites-enabled/zone.spip.org

        #Gerer les fichiers statiques en direct
        Alias /trac/spip-zone/chrome/ /var/trac/deploy/htdocs/
        <Directory "/var/trac/deploy/htdocs">
          Order allow,deny
          Allow from all
        </Directory>

Optimiser Apache

Les points qui vont suivre concernent principalement l’optimisation côté serveur.

Dans notre cas nous suivons les conseils Yslow. On peut trouver des informations complémentaires sur différents sites tel que le blog Frédéric de Villamil ou bien du côté de devside.

Optimiser la bande passante

Situation

On constate que l’ensemble de nos données n’est pas optimisé pour la transmission sur le réseau. Les éléments sont envoyés tels quels, ils ne sont pas compressés lors de leur passage sur le réseau.

On peut trouver plus d’information sur cette page dédiée

Solution

On configure le mode de compression selon la nature des fichiers transmis. On exclut de la compression les éléments normalement compressés comme les archives et les images.

sudoer~: nano /etc/apache2/mods-enabled/deflate.conf

# Compresser tout le contenu, sauf certains types spécifiques
<IfModule mod_deflate.c>
  # Placer le filtre 'DEFLATE' sur tout le contenu sortant
  SetOutputFilter DEFLATE
  # Exclure les élément non compressibles en fonction de leur type
  SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip)$ no-gzip
  <IfModule mod_headers.c>
    # Gérer proprement les requettes qui transitent pas des proxies
    Header append Vary User-Agent
  </IfModule>
</IfModule>

# Gérer proprement les anciens navigateurs qui ne supportent pas la compression
<IfModule mod_deflate.c>
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

Optimiser la durée de vie des fichiers

Situation

Une certaine partie des éléments d’une page sont statiques. C’est à dire qu’ils vont très peu évoluer dans un temps relativement long. Ainsi les navigateurs mettent à jour un certain nombre de fichiers alors que cela est inutile.

Solution

Pour peaufiner les informations de durée de vie nous employons le mode expires tel que peut nous l’expliquer encore Yslow

On installe ainsi les modules Apache requis.

sudoer~: a2enmod expires

sudoer~: nano /etc/apache2/mods-enabled/expires.conf

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 30 days"
ExpiresByType text/javascript "access plus 7 days"
ExpiresByType application/x-javascript "access plus 7 days"
ExpiresByType application/javascript "access plus 7 days"
ExpiresByType image/x-icon "access plus 7 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/jpg "access plus 30 days"
ExpiresByType application/x-shockwave-flash "access plus 60 days"
</IfModule>

Les Etag

Situation

Les Etag sont des identifiants uniques pour associer une ressource (fichier, ...) à une version donnée.
Si on se réfère aux tests Yslow, on constate que notre serveur serait mal configuré.
Pour autant avant de courir et de mettre un gros FileETag none dans votre configuration. Il est utile de se référer à certains articles de référence tel que celui d’Eric dapset.

Solution

Dans notre cas, nous avons un seul serveur, des ressources principalement gérées dynamiquement et un mappage des ressources statiques.
La solution est alors simple : « Ne rien faire ».

Fournir Trac, mod_wsgi

Trac utilise python, on ne répètera jamais assez ce détail.
Du coup nous avons plusieurs solutions pour le faire fonctionner avec Apache.

On trouve d’un côté les solutions CGI et de l’autre les modules. le site de codepoint fournit un certain nombre d’explications sur ces différentes approches.
Les solution CGI sont normalement faciles à mettre en place mais leurs performances sont inférieures aux modules apache.

Parmi les solutions modules nous avons mod_python et mod_wsgi. Le mod_wsgi est le module recommandé à l’heure actuelle. Mod_python n’est plus maintenu et fournit comparativement des performances moindres.

Préalablement nous avons deployé les fichiers statiques (pour rappel sudoer~: trac-admin /var/trac/spip-zone/ deploy /var/trac/deploy).

Un fichier de configuration spécifique pour wsgi est alors fourni, nous le retrouvons dans /var/trac/deploy/cgi-bin/trac.wsgi

Nous configurons alors notre serveur en conséquence. Nous gardons /var/trac/deploy hors du DocumentRoot ce qui devrait limiter les incidents de sûreté.

<VirtualHost *:80>
        DocumentRoot /var/www/zone.spip.org/

        #Fournir Trac
        WSGIScriptAlias /trac/spip-zone /var/trac/deploy/cgi-bin/trac.wsgi

        <Directory /var/www/zone.spip.org>
                PythonOption TracLocale "fr_FR.utf-8"
                WSGIApplicationGroup %{GLOBAL}
                Order deny,allow
                Allow from all
        </Directory>
</VirtualHost>

To be continued

Pour aller plus loin dans la configuration du mod_wsgi nous pouvons consulter le site officiel de Trac et celui du projet wsgi.