La Communauté Drupal

1000 cerveaux sont bien plus puissants qu‟un seul

Les fonctionnalités que nous cherchons existent déjà!

Ne réinventons pas la roue!

Il ya des développeurs Drupal qui sont des génies!

Profitons de leur expérience!

Le problème

Drupal est gourmand. L‟affichage d‟une simple page

peut parfois engendrer l‟exécution de 50 voir 150

requêtes à la DB

Imaginez vous cette même page appelée par plusieurs

internautes en même temps. On obtient alors des

centaines de requêtes et informations recalculées

inutilement qui vont solliciter les serveurs et vont ainsi

consommer du CPU et de la RAM

Performance, rendement Vs Evolutivité

Evolutivité (Scalability)

Capacité à faire face à une augmentation des utilisateurs et des données

Rendement (Performance)

Temps de réponse du serveur + temps de chargement de la page

Notre approche aujourd‟hui

Améliorer le temps de réponse de notre application Drupal pour des utilisateurs non identifiés

Ce que nous ne verrons pas

Front end performance

Back end performance

Reverse proxy avec Varnish

Apache mod_deflate

APC

Memcache

Cache router

Authcache

Query cache

Alors? Qu’allons nous voir?

Principes de caching

Evaluer le rendement avec AB et Devel

Le cache du cœur de Drupal

Gestion du cache: Cache browser

Gestion du cache: Content Refresh

Principes du Caching

Eviter de répéter une même opération en gardant le

résultat

Ex.: Calculer 2+3,

Écrire le résultat sur un papier (cacher dans la BD)

Mémoriser le résultat (cacher en mémoire)

Qu’allons nous mettre dans le cache

pour des utilisateurs non identifiés?

Des pages, des pages et rien que des pages…

Nous oublions les views, les bloques…

Comment évaluer la preformance?

Nous ne pouvons pas mettre en place des politiques

de performances sans une évaluation des ces dernières

Evaluer avec Apache Bench (AB)

Facil, simple et nous l‟avons tous installé par défaut

Evaluer avec Devel

Plus complexe, non compatible avec le cache agressif de

Drupal, utile si nous n‟avons pas accès a la shell du serveur

Apache Bench (AB)

AB test pour un utilisateur non identifié

ab -c 1 -n 100 http://example.dev/

Où

-c = concurrence des requêtes

-n = total des requêtes vers la page

Dans notre cas nous allons faire 100 requêtes vers la home page http://example.dev/

Un seul indicateur: „Requests per second‟

Le nombre de requêtes (vers notre home page) que notre serveur peut “servir” en une seconde.

C‟est avec cet indicateur que nous allons évaluer nos différentes politiques de performance. Plus il sera élevé, plus notre application sera performante.

Evaluer avec Devel

Télécharger le module devel:

http://drupal.org/project/devel

Habiliter la composante: Performance Logging

Configurer dans admin/settings/performance_logging

Detailed logging: Enabled

Faisons une première évaluation

Con AB

Con Devel

El caché del Core de Drupal

Le système de cache de Drupal enregistre les données

dans las tables suivantes:

Par défaut

1. cache – enregistre une copie de la

configuration de nos modules, de la

structure de toutes nos autres tables

et toutes les informations concernant

le thème utilisé sur le site

2. cache_menu – enregistre une copie

du menu de navigation et des URLs

qui lui sont associées

3. cache_filter – une copie de tous les

contenus une fois qu‟ils ont été filtrés

par le système de filtre

4. cache_form – enregistre tous les

formulaires soumis à la FormApi

Configurable

1. cache_page – enregistre une

copie des pages mais

seulement pour les utilisateurs

non identifiés

2. cache_block – enregistre une

copie des bloques

Activer le cache du coeur de Drupal

Nous allons sur admin/settings/performance

Cache des pages

Mode de cache: Normal ou agressif

Durée de vie minimale de la mémoire cache: 3 heures

Compression des pages: Activé

Pour savoir si notre serveur réalize déjà la compression: http://www.whatsmyip.org/http_compression/

Cache des bloques

Pas besion pour le moment car nous travaillons qu‟avec les utilisateurs non identifiés

Activer le cache du coeur de Drupal

Optimisation de la bande-passante

Optimise les fichiers CSS: Activé(en production)

Optimise les fichiers Javascript: Activé(en production)

Sauver la configuration

Maintenant nous pouvons voir comment la table

cache_page commence à se remplir

Tester à nouveau avec AB ou Devel

Gestion du cache: Cache Browser

Cache Browser

http://drupal.org/project/cache_browser

Nous avons aussi besion du module

http://drupal.org/project/format_number

Nous permet de vider le cache de chaque table ou plus

finement d‟un registre d‟une table. De cette manière nous

ne devons pas vider le cache dans son entier.

Nous permet de voir le contenu de chaque registre et ainsi

voir comment une page est cachée.

Gestion du cache: Content Refresh

Content Refresh http://drupal.org/project/content_refresh

Hypothèse: Les utilisateurs non identifiés peuvent laisser des commentaires et le cache du coeur est activé.

Sans Content Refresh, ils ne voient pas leur nouveau commentaire !

Avec Content Refresh oui! Quand il y a un nouveau commentaire, le cache de cette page est

éliminé y donc l‟utilisateur anonyme voir son nouveau commentaire.

Quand on enregistre un nouveau node, le cache de la home page est éliminé

Voir la configuration sur admin/content/content-refresh

En résumé

La statégie de performance pour les utilisateurs non

identifíes se base sur:

Activé le cache u cœur de Drupal seulement pour les

pages

Administrer le cache avec

Cache Browser (administration)

Content refresh (expiration)

Reste à voir dans ce cadre

Les modules Cache Actions et Boost