Vous avez été très nombreux à participer au concours pour gagner le Valve Complete Pack avec plus de 480 participants!

Merci à vous tous pour votre participation, du coup le tirage ne va pas être facile!

Pour être transparent, et si vous voulez faire la même chose sur votre blog , voici comment j’ai effectué le tirage au sort avec WordPress et une base MySQL.

Tout d’abord, il faut repérer l’identifiant de l’article concerné. Pour cela, deux solutions : soit rechercher l’article dans la table wp_posts (attention, il faut l’identifiant de l’article et pas d’une révision), soit regarder l’url de l’article par exemple dans l’administration dans la partie “Articles->Modifier“.

Dans mon cas, le lien vers l’article du concours affiche “http://www.papygeek.com/wp-admin/post.php?action=edit&post=3126“. On voit donc ici que l’identifiant de mon article est 3126.

Deuxième étape, vous pouvez vérifier que vous avez bien tous vos commentaires via une requête sur la table wp_comments :

SELECT `comment_author_email` , `comment_content`
FROM `wp_comments`
WHERE `comment_post_ID` =3126

Vous devriez alors obtenir le nombre d’enregistrements qui doit correspondre au nombre de vos commentaires.

Le concours étant limité à une participation par personne, il est important de pouvoir éliminer les “faux commentaires”. Voici comment voir ceux qui ont écrit plus d’un commentaire :

SELECT `comment_author` , `comment_author_email` , `comment_content` , count( * )
FROM `wp_comments`
WHERE `comment_post_ID` =3126
GROUP BY `comment_author_email`
HAVING count( * ) >1

Et la même chose pour obtenir les commentaires venant de la même adresse IP :

SELECT `comment_author` , `comment_author_IP` , `comment_content` , count( * )
FROM `wp_comments`
WHERE `comment_post_ID` =3126
GROUP BY `comment_author_IP`
HAVING count( * ) >1

Au dessus, le résultat n’affiche qu’un commentaire pour chaque IP ou email en double.
Pour afficher tous les commentaires concernés, il faut faire une requête du type “NOT DISTINCT“, je n’ai rien trouvé de très simple ni de très performant, mais voici un exemple pour les adresses mails multiples :

SELECT `comment_author` , `comment_author_email` , `comment_content`
FROM `wp_comments`
WHERE `comment_post_ID` =3126
AND `comment_author_email`
IN (
    SELECT `comment_author_email`
    FROM `wp_comments`
    WHERE `comment_post_ID` =3126
    GROUP BY `comment_author_email`
    HAVING count( `comment_author_email` ) >1
)
ORDER BY `comment_author_email`

Et pour afficher tous les commentaires ayant plus d’une fois la même IP :

 SELECT `comment_author` , `comment_author_email` , `comment_author_IP` , `comment_content`
FROM `wp_comments`
WHERE `comment_post_ID` =3126
AND `comment_author_IP`
IN (
    SELECT `comment_author_IP`
    FROM `wp_comments`
    WHERE `comment_post_ID` =3126
    GROUP BY `comment_author_IP`
    HAVING count( `comment_author_IP` ) >1
)
ORDER BY `comment_author_IP`

Les mails multiples sont bien à éliminer (conversation), par contre dans mon cas, les commentaires provenant de la même IP semblent plutôt normaux (Proxys d’écoles, d’administrations, etc.).

Pour faire le tirage, je vais donc utiliser la requête suivante :

SELECT `comment_author` , `comment_author_email` , `comment_content`
FROM `wp_comments`
WHERE `comment_post_ID` =3126
AND `comment_type` = ""
GROUP BY `comment_author_email`
ORDER BY RAND( )
LIMIT 1

Voici donc le moment d’effectuer le tirage et d’annoncer le gagnant….

Et le gagnant est… TA DA :

Tukse !!

Félicitations pour l’heureux gagnant!

Pour les autres, rassurez-vous! Le prochain article va me permettre de faire un peu plus le Papy Noël… Il va sûrement y avoir quelques Left 4 Dead à gagner

La migration vers WordPress 2.7 risque d’être moins simple que d’habitude si l’on veut profiter de toutes les nouveautés.
Aujourd’hui, WordPress 2.7 beta 1 vient de sortir, c’est donc le bon moment pour se préparer à la sortie de la version finale, qui devrait finalement arriver vers la fin du mois de Novembre suite à un retard de 2 semaines environ. Le 10 Novembre qui devait être la date de sortie de la version finale verra désormais arriver la version RC1.

Pour éviter de trop perturber votre blog en ligne, une bonne pratique consiste à récupérer toutes vos données et à les installer en local sur votre PC. Vous pourrez ensuite installer la nouvelle version et observer les dégâts pour éventuellement corriger le tir.

Etape 1 : le serveur Web

La première chose à faire est d’installer un serveur Web en local sur votre machine. Comme la plupart d’entre vous doivent utiliser le trio Apache/PHP/MySQL, je vais donc prendre cet exemple. Il existe plusieurs packages connus permettant d’installer directement ces 3 produits comme EasyPHP, WampServer ou encore XAMPP (pour Apache, MySQL, , PHP et Perl). C’est ce dernier que je vais utiliser, le package étant à jour et disponible pour Linux, Windows, MacOS X et Solaris.

Comme vous êtes nombreux sous Windows, je vais donc utiliser ce package de XAMPP Lite pour Windows comprenant Apache 2.2.9, PHP 5.2.6, MySQL 5.0.67 et phpMyAdmin 2.11.9.2. Si vous utilisez encore PHP4, commencez par migrer vers PHP5, ça ne vous fera pas de mal

Lancer l’exécutable et le décompresser par exemple à la racine de C: :

Aller ensuite dans C:\xampplite et lancer setup_xampp.bat :

Pour activer le mod_rewrite et permettre une structure personnalisée des permaliens dans WordPress, il faut modifier le fichier C:\xampplite\apache\conf\apache2.conf. Recherchez la ligne :

#LoadModule rewrite_module modules/mod_rewrite.so

Et décommentez là :

LoadModule rewrite_module modules/mod_rewrite.so

Lancer ensuite xampp-control.exe et démarrer Apache et MySQL (en validant les éventuels avertissements sous XP SP2 ou Vista) :

Ouvrez ensuite votre navigateur sur http://localhost/ :

Choisissez ensuite la langue pour vous retrouver sur la page d’accueil de Xampp :

Lancer ensuite PHPMyAdmin avec le lien dans la catégorie outils :

Etape 2 : récupérer sa base de données WordPress

Le plus simple pour récupérer la base de données est d’utiliser la fonction intégrée dans WordPress ou de récupérer simplement le dernier backup que vous devez avoir dans vos mails si vous utilisez comme il se doit WordPress Database Backup.
Vous pouvez également suivre ce guide sur le codex de WordPress : Backing Up Your Database.

Dans WordPress, allez dans Gérer->Backup, cochez tout et cliquez sur Backup Now en sélectionnant Download to your Computer :

Vous devriez alors obtenir un fichier à l’extension .sql.gz.

Sur PHPMyAdmin, créer une nouvelle base wordpress en utf8_general_ci :

Cliquer ensuite sur l’onglet “Importer” et utiliser le fichier en .sql.gz précédent en cliquant sur Parcourir puis Exécuter :

Etape 3 : récupération des fichiers de votre blog

Téléchargez avec votre client FTP habituel tous les fichiers de WordPress présents sur votre hébergement et copiez-les dans C:\xampplite\htdocs\wordpress :

Vous pouvez au passage vous contenter des dossiers languages, plugins et themes dans wp-content pour ne pas rapatrier toutes vos images contenues dans uploads et ainsi gagner du temps. Les liens de vos billets afficheront de toutes façons les images présentes en ligne.

Etape 4 : paramétrage de WordPress

Vos fichiers de WordPress contiennent des valeurs pour votre blog en ligne, il faut les adapter pour relier votre blog à votre base locale. Editer donc le fichier wp-config.php avec les valeurs suivantes :

define('DB_NAME', 'wordpress');    // The name of the database
define('DB_USER', 'root');     // Your MySQL username
define('DB_PASSWORD', ''); // ...and password
define('DB_HOST', 'localhost');    // 99% chance you won't need to change this value
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('WP_SITEURL', 'http://localhost/wordpress');
define('WP_HOME', 'http://localhost/wordpress');

Supprimez également l’éventuelle ligne suivante pour que votre mot de passe reste accessible :

define('SECRET_KEY', 'SECRET');

Les premières lignes concernent le paramétrage de la base locale wordpress sur localhost. Les deux dernières lignes sont très pratiques et permettent d’ignorer les paramètres présents dans les options de WordPress et contenant l’URL du blog. Ici, on indique la nouvelle URL en local : http://localhost/wordpress.

Il faudra également éventuellement en fonction de votre environnement faire le ménage dans votre .htaccess qui devrait maintenant ressembler à ça :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wordpress/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L]
</IfModule>
# END WordPress

Vous pouvez régénérer ces règles en allant dans l’administration de WordPress dans Réglages->Permaliens et en sauvegardant.

Etape 5 : test du blog en local dans la version actuelle

Il suffit de se connecter à l’url http://localhost/wordpress pour voir apparaitre votre blog local, qui doit normalement être identique à votre blog en ligne.

Etape 6 : Mise à jour de WordPress vers la version 2.7

Les étapes sont détaillées sur la page “Upgrading WordPress“.
Commencez par désactiver tous vos plugins. Téléchargez la dernière version disponible de WordPress. Dans notre cas il s’agit de WordPress 2.7 Beta 1.

Décompressez le fichier téléchargé dans C:\xampplite\htdocs en écrasant les fichiers existants.

Aller ensuite à l’adresse http://localhost/wordpress/wp-admin/upgrade.php et cliquez sur “Mettre à jour WordPress” :

Cliquez ensuite sur “Continuer” :

Et voilà le travail!

Tableau de Bord WordPress 2.7 Beta 1

Et franchement, c’est déjà bien sympa. Maintenant, il ne reste plus qu’a réactiver tous les plugins un par un pour observer les éventuelles incompatibilités, et d’intégrer les nouvelles fonctions de WordPress 2.7 en suivant mon article.

Et bien sûr je vous tiendrai au courant des problèmes classiques pour la version 2.7 dans un prochain article

WordPress est souvent au coeur du débat en ce qui concerne ses performances.
En tant que lecteur, vous avez sûrement rencontré quelques pages affichant des erreurs 500 ou MySQL sur un blog WordPress.

En tant que blogueur, vous étiez enfin parvenu à obtenir un lien depuis Digg ou Presse Citron, et manque de chance, votre blog s’effondre à ce moment là.

Pire encore, vous êtes devenu un hardcore-blogueur et trustez depuis peu les classements Wikio et Google Trends, mais votre site affiche une page blanche une fois sur deux.

Alors que faire ? Vous pouvez toujours pester sur “le-code-dégueulasse-de-WordPress, DotClear-c’est-vachement-plus-propre-et-écolo” ou chercher une solution.
Ca tombe bien, il en existe un certain nombre.

Premièrement, et avant d’aller plus loin, pas la peine d’espérer absorber un trafic “monstre” sur un hébergement mutualisé. Un moment ou à un autre, les problèmes vont arriver et vous ne pourrez que faire durer un peu le plaisir en optimisant votre blog. Mais puisque vous êtes gentils, on va tout de même en parler un peu.

Les systèmes de cache sur disque

Cache fichier simple

Vous ne le savez peut-être pas, mais WordPress intégrait un système de cache sur disque depuis sa version 2.0. Ce cache s’activait en ajoutant dans son fichier wp-config.php la ligne suivante :

define('ENABLE_CACHE', true); // Enable the WordPress Object Cache

Les performances de ce cache étant plutôt décevantes, il fut désactivé dans la version 2.1 de WordPress pour finalement être supprimé dans la version 2.5. Pas la peine de courir sur votre fichier wp-config.php donc.

Pour ceux désireux de retrouver cette option de cache sur disque, les petits gars de chez NeoSmart ont développé un plugin réintrégrant cette fonctionnalité.

L’avantage d’un tel système de cache est qu’il est compatible a priori sur tous les environnements : aucune extension particulière n’est nécessaire, ce qui en fait donc un candidat intéressant pour les hébergements mutualisés.

Pour le téléchargement, ça se passe ici. Décompressez ensuite le fichier et transférez le sur votre hébergement dans wp-content.
Ce qui donne directement depuis le serveur pour ceux ayant une connexion SSH :

cd /var/www/votresuperblog/wp-content
wget http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/file-object-cache_1.0.zip
unzip -p file-object-cache_1.0.zip > object-cache.php.filebased

N’oubliez pas de donner les bons droits au fichier (à personnaliser évidemment) :

chown www-data:www-data object-cache.php.filebased

Puis, pour activer le cache, il suffira de faire :

cp -p object-cache.php.filebased object-cache.php

Le super cache : WP Super Cache

C’est le système de cache le plus connu pour les blogs sous WordPress.
Il est une amélioration du plugin WP-Cache 2 qui s’occupait déjà de créer des fichiers de cache des objets du blog.

WP Super Cache va plus loin : il crée pour chaque page appelée un fichier HTML (ou même html.gz) de la page. Vous aurez donc une copie complète de votre blog au format HTML sous wp-content/cache/supercache. Au niveau performances, elles seront excellentes puisque seul apache sera utilisé pour transférer les pages à vos visiteurs, et PHP/MySQL périodiquement pour rafraichir les pages.

Il existe même une fonction permettant de résister à la plupart des Digg Effect : le “Lock Down” qui permet de verrouiller les fichiers de cache et donc de ne pas les régénérer quand un nouveau commentaire est publié.

Pour utiliser WP Super cache, il faudra que votre hébergement supporte la réécriture d’URL via le fichier htaccess présent à la racine du blog. C’est un facteur qui peut être bloquant sur certains hébergements mutualisés.

Pour ceux en hébergement dédié, c’est le module rewrite qui est utilisé, et qui peut s’activer sous Apache 2 facilement avec un :

a2enmod rewrite

Vous devrez également utiliser une structure d’URL autre que celle par défaut (Réglages->Permaliens dans l’administration de WordPress).

Pour le reste, je vous laisse suivre la procédure d’installation.

Cache mémoire ou accélérateur PHP

Il existe plusieurs extensions WordPress permettant d’utiliser un système de cache mémoire ou certains accélérateurs PHP.

Ils nécessiteront tous une configuration particulière de PHP et/ou l’installation de binaires supplémentaires sur le système, ce qui en fait une solution réservée aux hébergement dédiés ou privés.

Dans tous les cas, l’installation sera la même : il suffira de copier un fichier object-cache.php dans wp-content.

XCache

XCache est un cache d’opcode, c’est à dire un cache permettant de stocker les fichiers générés par PHP juste avant leur exécution.
XCache est développé par le créateur de lighttpd (lighty), un serveur Web très performant utilisé par exemple par YouTube, Wikipedia et Mininova. Il est souvent utilisé pour distribuer le contenu statique (images, vidéos, CSS….

Avant d’installer le plugin XCache pour WordPress, il vous faudra installer XCache pour PHP.
Si votre système ne date pas de la guerre (vous n’utilisez plus Firefox 1 n’est-ce pas ?), la commande suivante devrait faire l’affaire :

apt-get install php5-xcache

Il faudra ensuite légèrement modifier la configuration d’XCache dans /etc/php5/conf.d/xcache.ini en modifiant certaines variables comme ci-dessous :

; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size  =                64M
 
...
 
; same as aboves but for variable cache
xcache.var_size  =            16M

Les valeurs sont données à titre indicatif, elles doivent seulement être non nulles.

N’oubliez pas de rédémarrer apache :

/etc/init.d/apache2 restart

Pour vérifier le bon chargement d’XCache, il suffit de créer un fichier phpinfo.php avec le contenu :

<?php
phpinfo();
?>

En accédant à cette page via le navigateur, une section XCache devrait apparaître :

Il ne vous restera plus qu’à télécharger le plugin XCache pour WordPress disponible sur cette page.

Ou directement depuis votre serveur :

cd /var/www/votresuperblog/wp-content
wget http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/xcache-object-cache_0.6.zip
unzip -p xcache-object-cache_0.6.zip > object-cache.php.xcache

On donne les bons droits au fichier :

chown www-data:www-data object-cache.php.xcache

Et une petite copie pour activer le cache :

cp -p object-cache.php.xcache object-cache.php

Pour surveiller le travail d’XCache, il faut paramétrer l’accès à la page d’administration. Pour cela, dans /etc/php5/conf.d/xcache.ini, paramétrez les variables “xcache.admin.user” et “xcache.admin.pass“.

Pour la variable xcache.admin.pass, il faut donner le md5 de votre mot de passe, vous pouvez l’obtenir en tapant :

echo -n "montmotdepasse" | md5sum

Modifiez ensuite la configuration d’apache en ajoutant la ligne :

Alias /xcache-admin/ /usr/share/xcache/admin/

(En supposant que les pages d’admin d’XCache se situent dans /usr/share/xcache/admin/. La commande “locate xcache” devrait vous aider à trouver le bon répertoire.)

Visitez la page /xcache-admin/ dans votre navigateur pour observer l’activité d’XCache :

MemCached

MemCached est un système distribué de cache d’objets en mémoire. Vous pouvez donc très bien installer le système de cache mémoire sur une autre machine que celle hébergeant votre site, et même multiplier les machines de cache.
Pour information, Facebook utilise plus de 800 serveurs Memcache. Twitter les utilise massivement aussi.

Pour installer memcached, il faudra donc deux choses : le service en lui-même ainsi que les modules et librairies nécessaires. Ce qui donne :

apt-get install memcached php5-memcache
a2enmod mem_cache

Puis, rajouter à la fin de la configuration de PHP (/etc/php5/apache2/php.ini et/ou /etc/php5/cli/php.ini ) :

extension=memcache.so

Un petit démarrage de memcached et un redémarrage d’Apache et tout devrait fonctionner :

/etc/init.d/memcached start
/etc/init.d/apache2 restart

Pour vérifier tout ça, jetez un coup d’oeil à phpinfo comme au dessus qui devrait afficher une section memcache :

Il faut enfin installer le plugin memcached pour WordPress téléchargeable ici.
Soit en ligne de commande :

cd /var/www/votresuperblog/wp-content
wget http://dev.wp-plugins.org/browser/memcached/branches/1.0/memcached-client.php?format=raw -O memcached-client.php
wget http://dev.wp-plugins.org/browser/memcached/trunk/object-cache.php?format=raw -O object-cache.php.ryan

On donne les bons droits aux fichiers :

chown www-data:www-data memcached-client.php object-cache.php.ryan

Et une petite copie pour activer le cache :

cp -p object-cache.php.ryan object-cache.php

Et voilà!

MemCached + BatCache

BatCache est un nouveau venu dans le monde des plugins de cache WordPress. Son nom était “supercache” pendant le développement mais comme “Super” était déjà pris, il a fallu trouver autre chose à la sortie du plugin. Je vous laisse imaginer d’où vient le “Bat”…

Le plugin utilise MemCached en backend pour sauvegarder les pages qui sont accédées plus de X fois en Y secondes et les stocke pendant Z secondes. X, Y et Z sont bien sûr paramétrables.

Vous ne pourrez pas utiliser WP Super Cache et BatCache en même temps, à vous donc de choisir entre un cache mémoire et un cache sur disque comme WP Super Cache.

Le créateur du plugin BatCache prétend que son activation réduit de 40 fois le temps de génération des pages de WordPress.

L’installation est détaillée sur cette page, le plugin étant tout jeune, il évoluera certainement dans les mois qui viennent. A suivre donc.

APC

APC est un cache d’opcode au même titre qu’XCache.

L’installation est très proche de celle d’XCache, soit à peu de choses près :

apt-get install php-apc
echo '
extension=apc.so' >> /etc/php5/apache2/php.ini
/etc/init.d/apache2 restart

Le plugin WordPress APC doit lui être copié dans wp-content sous le nom object-cache.php.

eAccelerator

C’est exactement la même chose avec eAccelerator qui est encore un autre cache d’opcode.

Pour l’installation, je vous laisse chercher sur Google pour quelques documentations. C’est relativement simple et rapide.

Le plugin s’installe ensuite comme les autres :

cd /var/www/votresuperblog/wp-content
wget http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/eaccelerator-object-cache_0.6.zip
unzip -p http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/eaccelerator-object-cache_0.6.zip > object-cache.php.eaccelerator
chown www-data:www-data object-cache.php.eaccelerator
cp -p object-cache.php.eaccelerator object-cache.php

Quelle solution choisir ?

En termes de performances, les caches d’opcode se valent. Certains donnent tout de même à XCache une légère longueur d’avance.

Si vous avez déjà un système de cache tel qu’XCache, Memcache, APC ou eAccelerator installé sur votre hébergement, le plus simple est certainement d’utiliser le plugin WordPress correspondant.

Quant à WP Super Cache, il permettra d’éviter la plupart des traitements coûteux, allégeant largement le serveur. La charge répercutée sur les disques (I/O) sera souvent insignifiante vu les volumes échangés. Attention tout de même sur les hébergements mutualisés : vous ne pourrez pas monopoliser les ressources disques du serveur sans vous attirer des problèmes.

WP Super Cache est donc de loin la solution de cache la plus efficace pour un blog WordPress.

Seuls les problèmes d’installation ou les inconvénients de son activation peuvent être bloquants. On peut citer l’incompatibilité avec les plugins générant du contenu dynamique sur une page (par exemple en fonction du referer comme avec landing sites), ou les problèmes avec certains compteurs ou plugins de statistiques.

Je conseillerai personnellement l’utilisation combinée de WP Super Cache + XCache, les deux solutions étant compatibles. WP Super Cache pourra être activé en permanence ou au besoin.

N’hésitez pas à apporter vos retours quant à la solution qui pour vous paraît la plus efficace.

Allez plus loin ?

L’utilisation d’un plugin de cache n’est qu’un moyen parmi d’autres d’optimiser son blog WordPress. Si vous avez entièrement la main sur votre hébergement, optimiser Apache/PHP et MySQL est tout aussi important (et laborieux). Voici quelques pistes souvent évoquées dans ce cadre.

MySQL

Parfois controversée, le cache sur les requêtes SQL peut aider à réduire la charge sur votre base de données. Dans /etc/mysql/my.cnf :

#
# * Query Cache Configuration
#
query_cache_type        = 1

Pour alléger MySQL, la meilleure solution reste de réduire le nombre de plugins utilisés et surtout d’éviter ceux très gourmands pour la base : compteurs de visites, WP-Stats et autres plugins générant une ou plusieurs requêtes par visiteur. Il est préférable d’utiliser des équivalents externes en JavaScript : Google Analytics, WordPress.com Stats, etc. Autant alourdir les bases de Google ou de WordPress.com plutôt que la votre.

Apache

La configuration d’Apache est plutôt compliquée et dépend fortement de votre matériel.
Extrait d’un fichier /etc/apache2/apache2.conf :

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 30
 
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On
 
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100
 
#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 8
 
##
## Server-Pool Size Regulation (MPM specific)
##
 
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       8
    MaxSpareServers      50
    MaxClients          250
    MaxRequestsPerChild   500
</IfModule>
 
# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
    StartServers          15
    MaxClients          250
    MinSpareThreads      10
    MaxSpareThreads      100
    ThreadsPerChild      100
    MaxRequestsPerChild   1000
</IfModule>

A vous de tester et de rechercher la meilleure configuration pour votre machine. Les forums d’OVH ou de Dedibox ne manquent pas de discussions sur le sujet.

Si votre site est encore peu utilisé, vous pouvez faire quelques modifications puis les tester en utilisant Apache Bench :

apt-get install apache2-utils
ab -n 1000 -c 10 http://www.monserveur.com/mapagedetest.php

La variable “Requests per second” vous indiquera le nombre de requêtes auxquelles votre serveur pourra répondre chaque seconde (pour la page testée).

PHP

Pour PHP, pensez à désactiver certaines fonctionnalités parfois pénalisantes en terme de performances (et surtout très mauvaises pour la sécurité) :

register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
 
 
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off

Vous pouvez également modifier les limitations en termes de ressources :

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
 
max_execution_time = 60     ; Maximum execution time of each script, in seconds
max_input_time = 30 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 128M      ; Maximum amount of memory a script may consume (128MB)
...
; Maximum allowed size for uploaded files.
upload_max_filesize = 6M

Voilà quelques pistes qui j’espère vous aiderons à optimiser votre blog et donc à économiser quelques euros pour votre hébergement. Maintenant la page blanche ne devrait plus venir de votre serveur mais seulement de vous, alors au boulot