12 étapes pour optimiser les performances de son blog WordPress

Date: 6/09/2010 | Catégories: Blog,Open-source,Systeme,Web | Tags: ,,,,

Lorsque l'on choisi d'héberger son blog WordPress (sur un serveur dédié ou virtuel), la problématique des performances vient assez vite sur le tapis. En effet, l'optimisation du blog permet non seulement de réduire le temps de chargement des pages (et donc d'être bien vu par seigneur gOOgle) mais également de dimensionner au plus juste son serveur: gain de temps d'un coté, gain d'argent de l'autre.

Nous allons donc dans ce billet parcourir une liste non exhaustive de techniques d'optimisations:

  • ETAPE 1: Hardware
  • ETAPE 2: Noyau Linux
  • ETAPE 3: Mise à jour du système d'exploitation
  • ETAPE 4: MemCached
  • ETAPE 5: Les modules Apache
  • ETAPE 6: Configuration d'Apache
  • ETAPE 7: XCache (PHP)
  • ETAPE 8: MySQL
  • ETAPE 9: WP-DBManager
  • ETAPE 10: W3 Total Cache
  • ETAPE 11: Thème WordPress
  • ETAPE 12: Tester/Surveiller

Les commentaires seront bien sur là pour nous faire partager vos solutions !

Le hardware

ETAPE 1) C'est un peu le serpent qui se mort la queue... En effet il est assez difficile de dimensionner le hardware d'un serveur sans avoir fait les optimisations est sans connaitre précisément le trafic du blog (surtout vrai pour les nouveaux blog).

C'est en partie pour ces raisons qui j'ai choisi un serveur VPS de chez Gandi. En effet il est possible d'augmenter ou de diminuer les "parts" affectées à son serveur de manière dynamique (une "part" correspond à une ressource CPU, mémoire et disque).

J'ai actuellement "3 parts" sur le serveur du Blog de Nicolargo mais je m'en sers également pour d'autres besoins (je pense que pour ce blog, un serveur avec "2 parts" suffirait largement). Pour une première expérience dans le monde du blogging, un serveur "1 part" devrait convenir (environ 12€ HT par mois).

Je n'entrerai pas dans les discussions sur le coups relativement élevé de cette solution par rapport à un serveur dédié comme l'offre Dedibox de Online.net.

Le système d'exploitation

L'optimisation du système d'exploitation dépend bien sûr de la distribution Linux utilisée. Lors de la création de mon serveur j'ai choisi d'utiliser Ubuntu Server 8.04 que j'ai fait évolué en 9.04. Pourquoi cette distribution GNU/Linux ? Tout simplement car c'est celle que je connais le plus...

ETAPE 2 ) On commence par optimiser le noyau Linux . Je passe rapidement sur les explications. Il existe de nombreux article sur le net détaillant ces configurations. La configuration donnée est celle de mon serveur VPS (3 parts, 1 Go de RAM), elle doit être adaptée à votre configuration hardware.

Il faut éditer/modifier le fichier /etc/sysctl.conf (disponible sur GitHub):

Puis on applique:

sudo sysctl -p

Sources:

ETAPE 3) La première chose à faire quand on administre un serveur est bien entendu de le maintenir à jour au niveau des logiciels systèmes et applicatifs. Pour cela je m'aide d'un petit logiciel nommé cron-apt. Ce dernier permet de m'avertir par mail quand une mise à jour est disponible (par exemple une nouvelle version d'Apache ou une librairie PHP). En plus de corriger des failles de sécurités, les mises à jours permettent souvent d'obtenir de meilleures performances (que ce soit en rapidité ou en consommation de ressources).

L'installation est des plus simple:

sudo aptitude install cron-apt

Configuration en éditant le fichier /etc/cron-apt/config, notamment les lignes suivantes:

MAILTO="nom@domaine.com"

MAILON="always"

Un mail sera automatiquement envoyé à l'adresse nom@domaine.com, tout les matins à 4:00. Voici un exemple:

On peut voir qu'une mise à jour est disponible. Il ne reste plus qu'a se connecter en SSH sur le serveur et faire un:

sudo aptitude safe-upgrade

Il est possible de faire automatiquement les mises à jour mais je pense cela risqué si quelque chose se passe mal...

On critique souvent les serveurs VPS pour leurs faibles performances disque. Bien que je trouve celle des VPS Gandi plutôt acceptable (environ 6 Mo/s pour l'écriture et 24 Mo/s pour la lecture de petits fichiers type script PHP), il est intéressant de mettre en place un cache mémoire sur notre serveur. Ainsi, les applications compatibles pourront lire et écrire les données en RAM et non plus sur disque.

ETAPE 4) Nous allons donc installer MemCached, un cache mémoire libre.  On commence par installer le cache ainsi que la librairie Perl associée (qui sera utilisée par WordPress):

sudo aptitude install libcache-memcached-perl php5-memcache memcached

Par défaut, le cache écoute sur l'adresse 127.0.0.1 et sur le port TCP/11211. La taille du cache mémoire est de 64 Mo. J'ai gardé ces paramètres pour mon utilisation.

On peut obtenir des statistiques sur l'utilisation de MemCached en utilisant la commande:

# echo "stats" | nc localhost 11211

STAT pid 2806

STAT uptime 698465

STAT time 1283351366

STAT version 1.2.2

STAT pointer_size 32

STAT rusage_user 31.829989

STAT rusage_system 123.891742

STAT curr_items 12834

STAT total_items 1394993

STAT bytes 48830599

STAT curr_connections 11

STAT total_connections 16845

STAT connection_structures 31

STAT cmd_get 4012823

STAT cmd_set 1394993

STAT get_hits 2547543

STAT get_misses 1465280

STAT evictions 5694

STAT bytes_read 10561103955

STAT bytes_written 37908972470

STAT limit_maxbytes 67108864

STAT threads 1

END

Apache & PHP

On continue ensuite avec l'optimisation du serveur Apache (version 2.xx au moment de l'écriture de ce billet).

ETAPE 5) Apache se base sur un système de modules pour ajouter de nouvelles fonctions à votre serveur Web. Sous Ubuntu Server, la liste des modules actifs se trouvent dans le répertoire /etc/apache2/mods-enabled. Un petit ls dans ce répertoire vous donne donc la liste. L'optimisation consiste à supprimer les modules non utilisés. Je vous conseille la lecture de ce billet qui donne la liste des modules nécessaires au fonctionnement de WordPress. Attention, si votre serveur héberge d'autres sites Web que votre blog, il faut vérifier de ne pas supprimer un module utile...

Voici la liste de mes modules sur mon serveur:

alias.conf autoindex.conf dir.conf negotiation.load

alias.load autoindex.load dir.load php5.conf

auth_basic.load cgi.load env.load php5.load

authn_file.load dav.load expires.load rewrite.load

authz_default.load dav_svn.conf headers.load setenvif.conf

authz_groupfile.load dav_svn.load mime.conf setenvif.load

authz_host.load deflate.conf mime.load status.conf

authz_user.load deflate.load negotiation.conf status.load

ETAPE 6) On configure ensuite la manière dont les processus Apache sont lancés et gérés en mémoire et d'autres paramètres. Il faut éditer la section suivante dans le fichier /etc/apache2/apache2.conf (ou httpd.conf sur d'autre distribution GNU/Linux). Pour une description des paramètres, merci de lire le billet suivant:

<IfModule mpm_prefork_module>

StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxClients 40

MaxRequestsPerChild 2000

</IfModule>

# KeepAlive: Whether or not to allow persistent connections

KeepAlive On

# MaxKeepAliveRequests: The maximum number of requests to allow

MaxKeepAliveRequests 200

# KeepAliveTimeout: Number of seconds to wait for the next request

KeepAliveTimeout 5

# Timeout: The number of seconds before receives and sends time out.

Timeout 50

J'ai également modifier le fichier /etc/apache2/conf.d/optimization pour gagner quelques précieux  points aux tests Yslow et Page Speed:

Header unset ETag

FileETag None

On applique la configuration en relançant Apche:

sudo /etc/init.d/apache2 restart

Sources:

ETAPE 7) WordPress se base sur le langage PHP qui est connu pour être flexible mais pas très performant. C'est pour cela qu'il est nécessaire d'installer un cache PHP sur votre serveur Web WordPress. En gros, il permet de mettre en cache le code PHP déjà compilé. J'utilise personnellement XCache.

L'installation est simple:

sudo aptitude install php5-xcache

On configure ensuite le fichier/etc/php5/conf.d/xcache.ini (à adapter à votre configuration):

xcache.size = 64M

On relance le serveur Web:

sudo /etc/init.d/apache2 restart

Source:

MySQL

Souvent décriée, MySQL reste à l'heure actuelle la base de donnée officielle supportée par le moteur de blogging WordPress. Nous allons donc étudier quelques techniques d'optimisation.

ETAPE 8) On commence par éditer le fichier de configuration /etc/mysql/my.cnf pour ajuster la taille des caches (encore une fois les valeurs sont à adapter en fonction de votre audience/configuration):

query_cache_type = 1

query_cache_limit = 2M

query_cache_size = 32M

ETAPE 9) On installe ensuite le plugin WordPress WP-DBManager. Ce dernier permet de maintenir une base de données optimisée à travers le temps. En plus des fonctions de sauvegarde (manuelle ou automatique) et de restauration de votre base de données WordPress, ce plugin permet de d'optimiser et réparer cette même base.

Source:

WordPress

ETAPE 10) L'installation standard de WordPress (la fameuse installation en 5 minutes) ne tient pas en compte de l'optimisation. Nous allons voir comment configurer l'utilisation parallèle de XCache et Memcached (préalablement installé dans les étapes n°3 et n°5). Pour cela nous allons utiliser l'indispensable plugin W3 Total Cache.

Après l'installation du plugin, il faut se rendre dans le menu Performance > General setting de la page d'administration de WordPress puis cliquer sur le bouton Compatibility check pour vérifier que XCache et Memcached sont bien détectés:

Opcode cache: XCache

Memcache extension: OK

Ensuite on configure WordPress pour utiliser Memcached en activant toutes le fonctions de cache (CDN mis à part) et en utilisant le démon Memcached. Exemple de configuration pour les pages:

Dans le menu Page cache settings j'active toutes les fonctions sauf pour les pages 404:

Dans le menu suivant (Minify settings), j'active toutes les fonctions. Cela à pour but d'optimiser les pages, css et js avant d'être envoyés vers les lecteurs (attention, certains JS n'aiment pas beaucoup ces optimisations, à tester donc...).

Enfin, dans le menu Browser Cache setting, j'active toutes les fonctions et les expires header lifetime à:

  • 3600 secondes pour JS / CSS
  • 3600 secondes pour le HTML
  • 2592000 secondes pour les autres fichiers

A l'heure actuelle, le trafic généré par mon blog ne nécessite pas l'utilisation de caches réseau répartis (CDN). Mais c'est une optimisation à prendre en compte pour les "gros" sites.

Sources:

ETAPE 11) Rien ne sert d'avoir un kernel Linux, un serveur Web, un moteur PHP et un WordPress optimisés si le thème de votre blog est mal développé. Il est important de tester ce thème et notamment les plugins utilisées. Ces derniers utilisent souvent des JavaScripts qui peuvent pénaliser fortement le temps de chargement de vos pages. Rien de tel que des mesures de type YSlow et Page Speed pour mettre en évidence ce qui ne va pas.

Sources:

Tester/surveiller son serveur

ETAPE 12) Pour tester les optimisations mise en place, j'utilise l'outil  GTMetrix qui donne les valeurs YSlow et Page Speed (avec un archivage vous permettant de voir l'évolution des performances de votre blog à travers le temps).

De manière locale et surtout pour valider la configuration de votre serveur Web (Apache dans ce document), vous pouvez utiliser la commande suivante:

ab -t30 -c5 http://blog.mondomaine.com/

La ligne intéressante donnant le nombre maximal de requête par seconde que votre blog peut supporter est la suivante:

Requests per second: 158.19 [#/sec] (mean)

A un niveau plus bas, la commande Linux netstat permet de donner pas mal d'informations sur l'état des sockets:

netstat -tan | grep ':80 ' | awk '{print $6}' | sort | uniq -c

Enfin, pour surveiller l'activité de MySQL, j'utilise la commande MySqlReport.

Autres optimisations possibles

D'autres optimisations sont possibles, pour vous donner un exemple, je suis tombé l'autre jour sur le première article d'une série en cours sur le blog d'Antoine Benkemoun qui propose d'utiliser Squid pour booster les performances de votre site. C'est une technique très intéressante mais qui nécessite, pour être vraiment efficace, l'utilisation deux deux machines différentes. Une servant de reverse proxy-cache et une autre hébergeant votre blog.

Il est aussi possible de se passer du serveur Web Apache (il est vrai un peu lourd à administrer) pour se pencher vers des serveurs plus légers comme NGinx ou Cherookee. Update: Ou bien d'utiliser NGinx comme serveur Web pour les pages statiques et Apache pour les pages dynamiques (voir exemple de configuration ici). L'avantage d'une telle configuration est un gain non négligeable en terme de consommation mémoire.

Il existe un nombre incalculable d'optimisations possibles, j'espère d'ailleurs en découvrir de nouvelles dans vos commentaires...

  • http://www.dsfc.net Denis

    Quelques oublis :

    – CacheEnable pour Apache
    – eAccelerator pour Php ? WP Super Cache ???
    – dbReloaded sous WordPress
    – Squid en mode proxy transparent en flux sortant

    Très bon billet.

  • http://www.nicolargo.com NicoLargo

    @Denis:

    >> – CacheEnable pour Apache
    Je ne connais pas, mais d’après ce que j’ai lu cela fait un peu double emploi avec le système de cache des pages mis en place par le pluging W3 Total Cache / Memcached.

    >> – eAccelerator pour Php ? WP Super Cache ???
    eAccelerator n’est plus trop développé, il vaut mieux utiliser Xcache qui fait la même chose.

    >> – dbReloaded sous WordPress
    Je ne connais pas, pour le caching des requêtes de la base de donnée MySQL, je me base sur la fonction de caching proposée par W3 Total Cache / Memcached. Mais ce plugin est peut être plus pointu. Quelqu’un a un retour sur le sujet ?

    >> – Squid en mode proxy transparent en flux sortant
    C’est clair que c’est une bonne solution d’optimisation bien que sa mise en place soit un peu plus complexe que ce que j’aborde dans ce billet.

    En bonus, un billet intéressant sur la comparaison de plugins de cache WordPress:
    http://cd34.com/blog/scalability/wordpress-cache-plugin-benchmarks/

  • http://www.woueb.net Romain

    Merci pour l’article, il est chouette !
    Moi j’aurais rajouté pour les blogs à fort traffic :
    – squid en proxy pour le contenu static
    – lighthttpd

    Sinon j’aimerais bien tester Nginx ces prochains temps pour voir la différence.

  • http://www.dsfc.net Denis

    CacheEnable, c’est du memcache !

    xcache n’est pas dispo dans les paquets de la Centos, y compris dans RpmForge. J’hésite à employer Rpm.Pbone. eAccelerator marche plutôt bien et, contrairement à ce que tu dis, est un projet qui est maintenu.

    Je n’ai pas testé W3 Total Cache. Je vais regarder.

    • http://www.horizonlinux.org Charles

      epel + http://iuscommunity.org/

      pour du php52 ou 5.3 avec les modules de cache ( memcached, apc, xcache, eaccelerator )

      Pour les options sysctl, a ce que j’en ai compris en lisant vos sources sont pour des serveurs avec beaucoup de mémoire.

      sinon un très beau article avec plein de bon conseils.

      Un truc intéressant qui n’est pas mentionné c’est de coupler nginx pour le contenu statique et apache pour le dynamique. Ça fonctionne assez bien pour pratiquement n’importe quel site qu’il soit wordpress ou autre.

  • http://www.voie-militante.com Denis

    W3 Total Cache est beaucoup plus lent que WP Super Cache +2s : 7.3s au lieu de 5.5s.

  • http://www.nicolargo.com NicoLargo

    @Denis: Quel configuration pour W3 Total cache ? Cache sur disque ou utilisation de Memcached ? Quand j’ai fait mes tests interne il n’y a avit pas photo, W3 Total Cache était plus rapide…

  • http://www.dsfc.net Denis

    J’ai Memcache. Je n’ai pas xcache. Du coup, je n’ai pas pu activer l’option eAccelerator disponible dans le menu de W3 Total Cache. Je vais regarder. Je dispose uniquement de l’option “Disk”.

    NN W3 Total Cache intègre DB Cache Reloaded.

  • http://www.nicolargo.com NicoLargo

    @Denis: je pense que le gap de performances entre l’utilisation de l’option “Disk” et “Memcached” dans W3 Total Cache n’est pas négligeable, surtout si ton serveur est, comme moi, virtualisé (les accès disques ne sont pas très performant sur ce type de serveur).

  • http://www.dsfc.net Denis

    Le “Du coup” est en trop !

  • http://www.woueb.net Romain

    Au fait Nicolargo, ton test :
    ab -t30 -c5 http://blog.mondomaine.com/

    tu l’as fait en local ou à partir d’un serveur distant ?

  • http://www.nicolargo.com NicoLargo

    @Romain: En local pour mettre de coté toutes les problématiques réseau.

  • http://www.nicolargo.com NicoLargo

    Quelqu’un a t’il déjà essayé d’utiliser Varnish (http://www.varnish-cache.org/) avec Apache 2 (et des virtual hosts) ?

  • http://www.webynux.net Pfff

    HUmmm je pensais avoir suivi l’etape 3 et 5 mais le compatibility check me dit que memecached n’est pas installé :-/

    une idée de la boulette? il faut activer un truc sur un dédié?

    Merci

  • http://www.nicolargo.com NicoLargo

    @Pfff: non mais bien vérifier que ton firewall ne bloque pas les requêtes TCP/11211

  • http://www.webynux.net Pfff

    j’ai ouvert le port…pas de changement:
    Memcache extension: Not installed
    et
    root@webynux:~# echo “stats” | nc localhost 11211
    root@webynux:~#

    pas de resultats :-/

  • http://www.nicolargo.com NicoLargo

    @Pff: tu es sur qu’il est lancé ton memcached ? Tu le vois avec une commande du type:

    ps auxw | grep memcached

  • http://www.webynux.net Pfff

    root@webynux:~# ps auxw | grep memcached
    nobody 23521 0.0 0.0 44756 1128 pts/0 Sl 21:59 0:00 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
    root 24623 0.0 0.0 3336 812 pts/0 S+ 22:08 0:00 grep –color=auto memcached
    root@webynux:~#

  • http://www.nicolargo.com NicoLargo

    @Pfff: bizarre… Tu as bien insatllé la librairie libcache-memcached-perl ? Si c’est le cas, je ne vois pas d’ou vient le pb. Regarde dans ton fichier /var/log/messages si tu vois pas passer des message d’erreur (filtrage firewall ou erreur interne de Memcached)…

  • http://www.jeyg.info JeyG

    @Pfff: il faut également installer le paquet php5-memcache (marche pour moi sur Debian Squeeze)

  • http://kidrek.fr/blog/ kidrek

    Très bon article,
    pour les septiques, l’accès à la mémoire vive est beaucoup plus rapide que les accès disques.
    Pour ma part, j’ai mis un nginx en frontal qui fournit tous les fichiers statiques puis les pages dynamiques sont fournies par un apache en backend. J’avoue les performances sont au rendez vous. Merci encore pour ce tuto, surtout pour les paramètres noyau, bonne continuation. ++

  • http://www.nicolargo.com NicoLargo

    @JeyG: effectivement ! J’ajoute cette dépendance dans le billet…

  • http://www.montersonbusiness.com Rémy Bigot

    Merci pour ces nombreux conseils intéressants !
    Y’a plus qu’à mettre les mains dans le cambouis ^^

  • http://www.webynux.net Pfff

    Bon, ben mystère…. memcached apparait comment non installé …

  • http://www.jeyg.info JeyG

    @Pfff: une fois php5-memcache ajouté au reste, tu peux tenter de redémarrer apache et de rafraichir la page de validation sans le cache navigateur par un ctrl+F5.

  • http://blog.cheramy.name guidtz

    Très intéressant comme article, du travail en perspective. Est-ce que l’ajout d’un serveur DNS local qui fait office de cache peut faire gagner un peu de temps ?

    Très bon article
    Slts
    guidtz

  • http://www.webynux.net Pfff

    Merci à Tous et en particulier à Nicolargo et JeyG, memcache fonctionne a present

  • http://kidrek.fr/blog/ kidrek

    guidtz > Je ne suis pas sur qu’installer un serveur DNS te permette d’obtenir de meilleurs performances au détriment de perte de ressources. Personnellement j’utilise NSCD qui s’occupe de gérer un mini cache des requêtes DNS les plus effectuées.

  • http://www.nicolargo.com NicoLargo

    @guidz & @kidrek: effecfivement installé un DNS local n’apportera pas un quelconque gain de performance. Peut être un cache DNS comme le proopose Kidrek mais je ne suis pas vraiment sûr vu que le nombre de reqêute DNS est relativement faible pour l’affichage d’un site (mis à part quelques références externes)…
    De plus, sur un système GNU/Linux, les requêtes DNS les plus courantes sont déjà mises en cache.

  • http://blog.cheramy.name guidtz

    Hello,

    ok pour les DNS.

    Question supplémentaire, sous Debian le paquet php5-memcached n’existe pas mais il y a php5-memcache … une différence … à part le d en plus bien sur ?

    Slts

  • Pingback: Solutions pour accélérer WordPress()

  • http://www.dsfc.net Denis

    Désolé de mes remarques. J’étais un peu dans les choux. J’ai réussi à implanter memcached sur Centos non sans difficulté. C’est effectivement fulgurant. Une fois mis en cache via W3 Total Cache, le temps d’accès aux pages est 4 fois inférieur. Vendu !!!

    Sur l’accélérateur, eAccelerator se comporte très bien. J’ai regardé avec apc et xcache. C’est pas mieux.

    Merci pour ce tuto dont je n’avais compris toute la “subtilité” !!!

    -> http://www.dsfc.net/internet/hebergement-internet/accelerer-wordpress/

  • http://www.agencearagon.com Scuzzu

    J’aurai effectivement aimé savoir pourquoi tu as choisi le VPS chez Gandi plutôt que la Dedibox chez Free. Au moins quelques arguments.
    Je suis en train de faire un choix, je me pose aussi des question par rapport au VPS de Sivit.

  • http://www.nicolargo.com NicoLargo

    @Scuzzi: je ne vais pas être de bon conseil car j’ai fait ce choix car je disposais déjà d’un VPS Gandi au moment du hack de mon site. Je ne me suis donc pas posé la question.

    Avec un peu de recul je ne regrette pas ce choix par défaut car la flexibilité donnée par le système de “parts” chez Gandi est quand même sympa. Surtout si tu penses héberger autres choses que des sites/blog sur ton serveur.

    Ceci dit la solution de Online.net (Dedibox) est très compétitive. Je ne sais pas comment est leur support par contre…

    Pour t’aider un peu dans ton choix je te conseille la lecture de ce résumé du dernier WDFR de l’ami Francis:

    http://wdfriday.com/2010/09/wdfr14-quel-hebergement-choisir/

    A+

  • http://www.dedizones.com dedizones

    Merci pour ce tutoriel, je vais optimiser mes vps et mon blog

    Question/Réponse vps:

    Tout dépend de la technologie utiliser, comment tu brides la cfg du vps, les grand font du vps de masse c’est dire le bute est de mettre au max du vps donc tu vas devoir réduire les ressources etc..

    Moi, j’ai opté pour une solution openvz en cluster 4 serveurs sur 3 fournisseurs sa me donne un seule serveur de 32Ghz, et 72Go de DDR3 sa me permet de gérer les ressources correctement :p

    @ bientôt

  • Pingback: Sécuriser son blog Wordpress #1()

  • http://xavier.robin.name/ Xavier

    Je ne suis pas sûr de bien comprendre l’intérêt de MemCached sur une machine unique. C’est un ouitl destiné aux clusters, non ?

    Une chose qu’il ne faut pas oublier c’est les buffers et caches du système, ceux qu’on voit avec la commande “free”:
    total used free shared buffers cached
    Mem: 252516 222648 29868 0 65996 80036
    -/+ buffers/cache: 76616 175900
    Swap: 634556 8412 626144

    Si de la mémoire est disponible (= non utilisée par les applications), le noyau Linux va y charger les fichiers les plus fréquemment utilisés. Dans la sortie de free, c’est la ligne “-/+ buffers/cache” qui indique la mémoire réellement utilisée par les applications. Ce comportement est assez bien documenté, voir par exemple http://www.linuxjournal.com/article/2770?page=0,0 http://www.linuxhowtos.org/System/Linux%20Memory%20Management.htm ou http://sourcefrog.net/weblog/software/linux-kernel/free-mem.html

    Ainsi les fichiers lus par le serveur web ne sont en fait pas lus depuis le disque dur, mais depuis la mémoire (pour autant qu’on en ait suffisamment, ça va de soi). L’intérêt de Memcached me semble donc quasiment nul…

    • http://www.nicolargo.com NicoLargo

      Ce que tu dis est vrai pour un site statique ou un serveur web va juste lire puis diffuser les fichiers vers les clients. Par contre dans le cas d’un site dynamique (par exemple un blog généré par un CMS de type WordPress), chaque requête cliente va générer: un lancement de script PHP, un appel à une base de donnée, une génération de page HTML. Autant dire que l’apport de Memcached dans de tel cas n’est pas négligeable…

  • http://www.comohacerencasa.com Schubert

    Très bonne information, merci pour le partage, salutations

    • http://www.herbi-mag.com HerBiV

      Merci bien pour ce billet !

      Ca date déjà, certes, mais pour un vieux serveur ovh RPS qui n’en peut plus, j’ai presque gagné 2 sec de chargement par page !

      :)

  • http://www.visipure.com Visipure

    J’ai abandonné le RPS d’OVH pour le Simple Hosting de Gandi. Sans aucune optimisation ça marche nickel, pas de latence énorme comme avant, j’ai trop galéré avec ce RPS à ce niveau.

  • Pingback: Cas pratique d’optimisation de WordPress | PostBlue()

  • http://www.lolokai.com Lolokai

    Depuis peu, on a CloudFlare qui fait un super boulot en matière d’optimisation du chargement d’un site internet et de sécurisation aussi.

    Un outil intégré nativement est souvent oublier en matière de tuning de base de données : les index ;). On peut optimiser ses requêtes en bases en indexant certaines tables ;).

    Sinon super article comme toujours ;)

  • Alex

    There is a nice plugin that covers almost all the points here and also brings some other optimization methods to the table. It’s extremly user friedly and you don’t have to know much to may it work. http://codecanyon.net/item/performance-optimizer-plugin-for-wordpress/2413770

  • Pingback: Boite A Trouvailles | Optimiser les preformances de votre site internet !()