Avant de détailler les systèmes de caching que l’on peut trouver au sein d’une infrastructure, je vous recommande de lire le billet sur le système de cache fichier pour bien appréhender le mécanisme d’optimisation sous-jacent.

pour répondre aux problématiques de montée en charge des services, on aura recourt à plusieurs niveaux de cache. Cette stratégie d’optimisation est faîte de manière globale et prend en compte tous les paramètres de l’infrastructure et de l’application pour être optimale. Ces moyens permettent de soulager l’infrastructure et de résorber des goulots d’étranglements. Le design et l’intégration de ces solutions imposent tout de même d’avoir les réflexions suivantes :

  • Est-ce que nous devons tout mettre en cache ?
  • Est-ce que tout est cachable ?
  • Le mécanisme d’invalidation du cache peut-il remettre en cause le choix technique ou impose-t-il des développements complémentaires ?

Pour répondre aux mieux à ces questions, nous présenterons, dans un premier point, le cache d’OpCode, puis au travers d’une infrastructure technique, nous verrons comment s’intègrent les autres systèmes de cache (Memcache ou Varnish) et autres mécanismes d’optimisations. L’objectif étant de répondre à la question suivante : La charge de mes serveurs augmente, comment faire pour maîtriser le problème et ne pas être en rupture ?

Système de cache d’opcode

La mise en place d’un cache d’opcode est le moyen le plus simple de gagner en performance sans avoir besoin de modifier le code PHP. Ci dessous, nous avons schématisé le flux généré lorsqu’un utilisateur va demander une ressource. Le cache d’opcode va éliminer toutes les étapes d’analyses (flux orange) qui sont opérées durant l’exécution d’un script PHP. L’opcode va être stocké dans un cache de type « mémoire ».

cache Opcode : principe de fonctionnement

cache Opcode : principe de fonctionnement

Il faut savoir que tout ce qui réside en mémoire est volatile. Partant de ce principe, il ne faut pas stocker dans ces caches, des données persistantes qui seraient utilisées par d’autres flux métiers. Pour vos développement, Vous ne pouvez pas faire le postulat que le cache mémoire sera toujours disponible. Voici quelques cas concrets de cette volatilité :

  • au sein d’une architecture technique où les serveurs web sont gérés de manière élastique (Environnement cloud EC2 par exemple), le cache d’Opcode peut disparaitre à tout moment avec l’instance,
  • le service web peut être redémarré suite à une mise à jour : le cache d’opcode va lui aussi disparaitre,
  • le cache est réinitialisé car sa durée de vie a expiré.

Il existe plusieurs caches d’opcode dont voici les principaux :

  • APC (http://www.php.net/manual/en/ref.apc.php),
  • eAccelerator (https://eaccelerator.net/),
  • Xcache (http://xcache.lighttpd.net/) …

APC : un cache opcode efficace

APC est un cache d’opcode et améliore les performances de manière significative en mettant en mémoire le résultat de la pré-compilation du script PHP. Installons le module et réalisons notre benchmark.

//récupérer les sources d’APC (http://pecl.php.net/package/APC) et décompressez-les et positionnez-vous au sein de ce dernier.
//exécution des commandes suivantes :

phpize
./configure
make
make install

L’extention «apc.so» a été ajoutée dans le répertoire des extensions php. Ce répertoire va dépendre de votre environnement d’exécution. Pour connaitre son emplacement, faîtes un phpinfo(). Il ne reste plus qu’à modifier notre fichier de configuration PHP et à redémarrer le serveur Apache dans notre cas.

//positionnez-vous à la fin du fichier php.ini
extension = apc.so
apc.enabled = 1
apc.enable_cli = 1
apc.num_files_hint = 1024
apc.shm_segments = 1
apc.shm_size = 128M
apc.ttl = 3600
apc.user_ttl = 3600

// noubliez-pas de redémarrer votre serveur web et de vérifier qu’APC est bien activé par un phpinfo();

APC étant disponible, faisons notre benchmark avec AB : ab -n1000 -c20 http://www.test.local/index.php
Après plusieurs tests, nous avons une moyenne de 2200 requêtes par seconde. Le cache d’opcode a effectivement apporté une amélioration significative par rapport au précédent test (voir billet sur le cache fichier).

APC dispose aussi d’un ensemble de fonctions PHP pour être manipulé. Certaines fonctions permettent de stocker et de récupérer des blocs de données qui auront été mises dans la mémoire utilisée par APC. La librairie Cache lite va nous permettre de générer la page html à cacher, et les fonctions PHP d’APC seront utilisées pour le stockage et la délivrance de cette dernière.

Utilisations d’APC comme un cache mémoire

APC est un cache d’opcode de type mémoire et dispose de fonctions php pour être manipulé. Regardez la documentation d’APC afin de prendre connaissance des possibilités qui vous sont offertes. Nous allons modifier notre script de test en intégrant la fonction « apc_add() » pour cacher la page HTML qui sera restituée par « cache lite ».

<?php
$id = 'cache';

//Est ce que le cache existe ? pour l’id donné
if (apc_exists($id)) {
	echo apc_fetch($id);

//pas de cache : je vais construire ma page
} else {
	## pas de cache, on utilise cache lite pour le générer et récupérer les flux de sortie
	require_once('Cache/Lite.php');

	$options = array(
    'cacheDir' => '/mon_rep_de_cache/',
    'lifeTime' => 3600
	);
	$Cache_Lite = new Cache_Lite($options);

	$txt = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. ';
	//boucle
	for ($t=0; $t<10; $ii++)
	{
    	$txt .= $txt;
	}
	//traitement
	$temp = asort( explode(‘ ’,$txt));
	$fin = array_keys($temp,‘dolor’);
	$html = ‘’;

	foreach($fin as $clef=>$values) {
		$html .= $clef . ‘--’ . $values . ‘<br>’;
	}

    $Cache_Lite->save($html,$id);
	apc_add($id,$Cache_Lite->get($id));
	echo $html;
}

?>

Nous relançons notre benchmark avec AB : ab -n1000 -c20 http://www.test.local/index.php
Après plusieurs tests, nous avons une moyenne de 3800 requêtes par seconde. Ce résultat est dû au fait que nous utilisons la mémoire plutôt que le disque comme espace de stockage pour le cache. Ce résultat est à pondérer si votre serveur dispose de disque de type SSD.

Combiner les systèmes de cache : une optimisation gagnante

Il y a une vrai complémentarité dans les solutions de cache. Chaque système de cache va apporter une pierre à l’édifice dans un objectif de maximisation des performances. Le graphique ci-dessous montre le résultat de nos benchmarks.

Ce qu’il faut retenir :

  • Cache lite : librairie PHP vous permettant de définir vos blocs à cacher de manière simple. Elle peut être utilisée sur tous les types d’hébergement,
  • APC : cache d’opcode pour améliorer la vitesse d’exécution des scripts PHP. Il peut être utilisé pour cacher des flux générés par cache lite. C’est une solution réservée à de l’hébergement dédié principalement,
  • le cache d’Opcode est lié au serveur sur lequel il a été compilé : il n’est donc pas centralisé et ne doit pas être utilisé pour cacher des éléments partageables entre plusieurs instances,
  • le cache en mémoire est très rapide : éviter la mise en cache sur disque si possible (plus lent).

Passer d’un serveur dédié à une architecture : une mise en oeuvre qui n’est pas toujours simple et qui nécessite de prendre du recul. La mise en place des caches est différente, la stratégie d’attaque l’est donc aussi : il faut composer.

Intégration des caches dans une infrastructure

L’approche du caching applicatif au sein d’une infrastructure peut devenir complexe.
Nous ne sommes plus dans un univers « mutualisé » ou munit d’un serveur dédié. L’objectif est de maximiser l’utilisation de l’infrastructure (absorption du trafic) tout en minimisant sont coût (nombre de serveurs déployés).

Chaque situation est différente. Elle est différente car les applications qui y sont déployées sont toutes différentes. Il est important avant de mettre en place une solution, de réfléchir de manière transversale et métier. Nous allons partir d’une infrastructure technique simple et voir comment les caches peuvent améliorer une situation de montée en charge.

mise en place de l’architecture web

Ci-dessous une proposition d’infrastructure pour démarrer notre exposé.
Pour rappel :

  • Load balancer : serveur qui va router ou répartir les requêtes http sur les différents serveurs web (www). Cela permet de résorber la charge sur les serveur web. Plus on met de serveur web, plus on peut accepter de requêtes,
  • BDD : Base de données : l’ensemble des serveurs web accèdent au SGBD et nous démarrons avec une seule instance,
  • Versionning (SVN/GIT) : Cela permet d’avoir une centralisation du code et une stratégie de déploiement efficace,
  • NetApp : Filer de stockage pour le partage des données utilisateurs et des médias (fortement dépendant de l’application),
  • OP : Cache OpCode APC compilé et présent sur l’ensemble des serveurs web.

APC étant disponible, nous pourrions vouloir l’utiliser pour cacher des objets métiers de notre application (comme vu dans le point précédent).
Le problème est que nous évoluons au sein d’une infra qui a plusieurs serveurs web. On ne peut donc pas prévoir le chemin que prendra la requête HTTP. Le Load balancer étant maître du routage, nous ne pouvons pas utiliser les possibilités de caching d’APC pour stocker des objets PHP ou des blocs de données. On pourrait se retrouver dans une situation où les informations métiers seraient désynchronisées entre les serveurs web.

Dans l’architecture actuelle, le filer est un élément central. Le filer pourrait être utilisé dans un premier temps pour cacher certaines données.

Utiliser le filer pour cacher des données n’est pas forcément une bonne idée. Le filer est relié aux serveurs web par un protocole réseau : NFS. Sans rentrer dans les détails, ce protocole n’est pas très performant mais peut être amélioré par un système de cache réparti.

Le filer peut être une solution transitoire. Il est préférable de s’orienter sur une solution de cache centralisée (réseau) et de type mémoire. Memcache est une solution de cache centralisée pouvant répondre à nos besoins. Comme tout système de cache mémoire, ce dernier est volatile et il est important de le garder à l’esprit.

Memcache : un cache mémoire distribué

Memcache est un service de cache mémoire réseau. C’est un moyen efficace de partager des données au sein d’une infrastructure. Comme tout système de cache mémoire, il est volatile et donc non persistant. On va pouvoir cacher des éléments qui ne nécessitent pas de persistance ou bien qui ne provoquent pas de problème d’intégrité.

Ci-dessous la nouvelle architecture avec la mise en place de Memcache.

Je vous propose une installation de Memcache

## Récupération des sources (memcached.org) , décompression et positionnez vous dans le répertoire

//compilation : vous aurez besoin de «libevent» (libevent.org)
./configure
./make
./make install
./make clean

//le binaire a dû être placé dans /usr/local/bin par défaut et pour le lancer tapez la ligne suivante

./memcached -d -m512 -u nobody -l 127.0.0.1 -p 11211

// Allocation de 512 meg de Ram pour une communication en localhost sur le port 11211

## pour compiler l’extension PHP pour memcached, nous avons besoin de compiler la lib «libmemcached» (https://launchpad.net/libmemcached/+download). Téléchargez l'extension PECL (pecl.php.net/package/memcached)

//Compilation de libmemcached : positionnez-vous dans le répertoire
./configure
make
make install

//compilez la lib PHP : positionnez-vous dans le répertoire
phpize
/* il est possible que «configure» vous demande le chemin de la lib libmemcached si elle n’a pas été installée dans un répertoire conventionnel. Lors de la compilation de la lib libmemcached, ce chemin vous a été donné ou bien utilisez la commande find.
Vous pouvez activer le support JSON lorsque vous lancez la procédure de configuration.
*/
./ configure
make
make install

//Activez l’extension dans votre php.ini et pensez à redémarrer votre serveur web

extension = memcached.so

// petit script php pour voir que tout est ok
<?php
$memcache = new Memcached();
$memcache->addServer(‘localhost’,11211);
var_dump($memcache->getVersion());
?>

Pour utiliser memcached pour la gestion des sessions PHP, vous devez éditer votre php.ini et modifier les lignes suivantes :

session.save_handler = memcached
session.save_path = "localhost:11211"

Memcache étant actif, vous pouvez stocker en mémoire des objets PHP ou tout autre type de bloc de données. Je vous recommande de prendre connaissance de la documentation.

En conclusion de ce point, Memcache va vous permettre de :

  • gérer les sessions PHP qui étaient sur le filer : vous n’avez pas besoin de changer vos scripts PHP. Le mécanisme est transparent et on aura une amélioration des performances,
  • stocker des objets PHP ou des blocs de données comme avec APC. Il convient d’être prudent mais permet d’avoir des améliorations sur des workflows maîtrisés. Nous donnerons des pistes en conclusion du billet,
  • cachez des requêtes SQL et pourquoi pas le résultat de ces dernières.

Anticiper et résoudre les problèmes structurels d’infrastructure doivent s’accompagner d’une introspection du code applicatif et notamment du SGBD.

Optimisation du SGBD : cache & analyse de requêtes

Le SGBD porte une partie de la logique métier. Qu’il soit relationnel ou orienté document, nous y stockons des données. La création, la lecture, la mise à jour et la suppression (CRUD) des données en fonction de la charge globale sur l’application va peut être générer de nouveaux goulots d’étranglement.

L’optimisation de base de données va s’opérer à plusieurs niveaux :

  • requêtes : prendre connaissance des requêtes les plus lentes qui génèrent de la charge (ratio des 20% / 80%). Activez les SLOW QUERY LOG et utiliser EXPLAIN pour comprendre le plan d’exécution des requêtes,
  • analyse du schéma : normalisation VS dénormalisation,
  • structure des champs : optimisation intéressante sur une grosse volumétrie,
  • structurelle : sharding, partitionnement et infra maître esclaves,
  • cache SQL : SQL Query Cache permet de cacher des requêtes qui sont régulières et qui ne changent pas dans leur structure. C’est à utiliser en complément de Memcache. Pour plus d’information sur SQL query cache, je vous recommande de prendre connaissance de la documentation de MySQL

Malgré la mise en place de toutes ces solutions d’optimisations, la fréquentation de l’application web impose de devoir mettre en place une solution ultime de cache en frontale.

VARNISH : un proxy cache dopé aux stéroïdes

VARNISH est un reverse proxy ou serveur de proxy cache inverse. Il est installé en tête de l’infrastructure et va jouer le rôle de cache local et de load balancer. Il est un maillon fondamental dans une stratégie d’amélioration des performances sur des sites web à fort trafic. Son rôle sera de soulager l’infrastructure sous-jacente.

Fonctionnement de VANISH

VARNISH permet d’écrire des règles de routage dans un pseudo langage (VCS), permettant d’écrire des règles très puissantes :

  • j’ai la page html demandée en cache et je la retourne,
  • je retourne des ressources statiques (css,js,jpeg,…) suite au chargement de la page HTML,
  • je sais quelle page retourner et elle est composée d’éléments dynamiques qu’il va falloir demander à l’infrastructure,
  • c’est une authentification : je laisse passer le flux,
  • je suis capable de gérer du Load balancing …

Par rapport aux solutions de caches précédentes, VARNISH permet de décharger significativement la charge des serveurs applicatifs et cela à plusieurs niveaux. Les règles de routage, de gestion du cache écrites en VCL, seront compilées en langage C par VARNISH qui lancera le compilateur GCC pour obtenir un code natif : l’interprétation des règles et la restitution des données sont de ce fait très rapide.

Avant d’utiliser cette solution technique, il faut prendre en considération le coût d’apprentissage de cette mise en place. Dans la plupart des cas, nous oeuvrons pour des solutions web dynamiques. Les règles de cache doivent être ajustées aux contextes d’usage. Tout n’est donc pas cachable. Il est important d’identifier les éléments communs de ceux qui seront directement liés à l’utilisateur.
Pour cela VARNISH intègre partiellement la norme ESI implémentée à la base pour les solutions de CDN Akamai. Cette norme permet de définir des patrons de pages dont certains blocs seront cachés.

Gestion du cache : création et invalidation

La gestion du cache avec cette solution devient un projet à part entière. Il convient de choisir avec précaution les éléments qui devront être cachés et d’écrire les règles conformes au bon fonctionnement de l’application sous-jacente.

Si nous restions à ce niveau d’explication, il semblerait que coté application (code), il n’ y ait pas de modification à faire pour l’utilisation du proxy cache. Effectivement, les règles sont écrite dans le pseudo langage de VARNISH et le code PHP n’a pas à être impacté.

Pourtant dans un état où la plate-forme technique est en charge, l’invalidation du cache peut devenir la source d’une rupture de service. L’invalidation du cache entraine mécaniquement la régénération des pages qui y étaient présentes. Le temps de cette régénération, sera source de la rupture du service. Par ce que nous sommes en présence d’un site à forte charge, les N utilisateurs vont demander en même temps la régénération de la page qui vient d’être invalidée.

Le processus d’invalidation doit être intégré en amont au sein de l’application. Ce n’est pas à VARNISH de décider que les éléments cachés ne sont plus valides. Les actions utilisateurs et/ou administrateurs de l’application vont piloter la mise à jour du cache. On peut imaginer des scénarios de mise à jour en fonction des droits des utilisateurs sur l’application.

Conclusion sur les caches applicatifs

A chaque situation, il y a une solution technique adéquate pour améliorer la performance des applications. Il est important au début d’un projet d’essayer de se projeter et d’adopter des bonnes pratiques de développement. L’optimisation ne doit pas être au coeur des préoccupations. A trop vouloir optimiser, on perd en lisibilité et en simplicité. L’optimisation doit être une tâche transversale à tout projet web mais pas l’élément directeur. Des outils existent pour orienter ses choix et faire des tires de charge. Seule une mise en situation réelle nous apprend comment l’application se comporte. Il est donc primordial d’être vigilant à ce que l’administrateur système peut nous remonter comme information sur l’état de la plate-forme. Il faut être réactif et analyser les pistes d’améliorations sans oublier les améliorations fonctionnelles qui peuvent aller de paire.

La mise en place à plusieurs niveaux de cache (Opcode, cache SQL, Cache mémoire et fichier, proxy inverse …) comme nous l’avons vu, sont des moyens pour améliorer les performances globales. Pour que l’ensemble de ces optimisations soit efficace, et obtenir des améliorations tangibles, il convient aussi de remettre en question les flux métiers, les algorithmes associés et donc le code PHP. Tout ne peut pas reposer sur la performance des administrateurs systèmes. Les développeurs doivent aussi remettre en question leur programme et utiliser les rapports d’activités des administrateurs système. qui fournissent des informations qualitatives sur l’état global de l’application au sein de l’infrastructure.

16 réflexions au sujet de « Caching avancé et stratégie d’optimisation pour des applications web à forte charge »

  1. Merci pour le rappel ;-), du coup je me suis abonné aux flux :).
    Sinon le billet est de très bonne qualité… Je n’avais pas pensée à utiliser APC pour du cache mémoire. Effectivement, on ne peut l’utiliser que dans un cas bien précis et sur une infra où on a besoin de partager un ensemble d’éléments, il est préférable d’utiliser memcached. J’aurais aimé avoir plus de retour sur Varnish :). Un prochain billet la dessus ?

    • Merci Eric pour ton commentaire. Varnish est compliqué et je n’ai fait qu’une introduction. Pour bien faire, il faudrait l’installer, le paramétrer et faire des jeux de tests sur un cas concret. J’ai vu qu’il y avait des fichiers de règles toutes faites pour WordPress. Cela pourrait faire l’objet d’un prochain billet :). En ce moment je regarde Cassandra (base de donnée NoSQL).

  2. Si on active MySQL query cache alors quel est l’intérêt de cacher le resultat de requête avec memcache ?

    De plus est-ce une bonne idée de cacher (dans un modèle MVC), non pas la couche modèle mais la couche controleur, c’est-à-dire le résultat d’une action ?

  3. Bonjour,
    Il me semble que dans une infra ou il y a N serveur MySQL esclave, cette stratégie n’est valable que sur un hôte MySQL : Memcached étant un service distribué, il est plus approprié de l’utiliser pour gérer la distribution des éléments à cacher. Je pencherais sur le fait que moins on sollicite le service, mieux cela vaut. Si on fait supporter un niveau de cache à MySQL alors, on aurait certainement pu éviter une connexion à ce serveur.

    Dans un model MVC, le M pour Model est aussi le M de métier. Il peut être intéressant de vouloir cacher des workflow.
    Le contrôleur de dialogue du MVC est bien le maître d’oeuvre et à ce titre, si une requête d’utilisateurs aboutie toujours au même résultat : pourquoi ne pas cacher le résulta de cette action répété N x dans le temps ? cela évite à ce dernier d’appeler des objets Métiers du M.

    • Mince pour le query cache de MySQL je n’avais pas pris en compte l’archi distribuée. Du coup, on a bien intérêt a cacher les resultats de requêtes SQL.

      Au final, je pense qu’il y a pas de solution fixe de strategie de cache. Il faut analyser et adapter a son application et il est peut-être intéressant de cacher directement au niveau du controller.
      Cependant contrairement à la couche Model où l’on pourrait « automatiser » le cache pour la couche Controller il s’agira obligatoirement d’un caching « manuel » à la charge du développeur.

      • En effet, il n’ y a pas une solution mais bien une stratégie d’optimisation à mettre en place. Le dev doit prendre connaissance de l’infra, discuter et travailler avec l’équipe de Sysadmin (devops) . Lorsque l’infra subit, on agit toujours en mode pompier alors que l’on aurait pu anticiper le comportement de l’application en la mettant en situation de stress.

  4. C’est peut être vraiment con comme idée mais j’y pensais:
    Si on utilise en parallèle Memcache et APC en tant que « user caching », donc je parle pas du Opcode.
    On sait très bien que le problème d’APC est qu’il est local au server, donc non partagé avec les autres servers web mais en contrepartie il est bien plus rapide que Memcache.

    Cependant on pourrait imaginer un système qui utilise un double cache. On aurait d’un côté un « fast cache » (APC) et un « slow cache » (Memcache).
    Exemple:
    Serveur_1 reçoit une donnée « cacheable » mais qui n’est pas « hit », il va donc executer le « script » puis « cacher » le résultat dans APC et Memcache.
    Maintenant un client lambda veut accéder à la donnée via le Serveur_2, celui-ci n’aura qu’a check si elle est présente dans APC puis memcache (et je précise bien PUIS car c’est important pour les performances).

    Jusque la, pas trop de difficulté, le gros problème est pour l’invalidation… C’est ici que je n’ai pas de réelle solution car si un client lambda modifie la valeur du cache sur Serveur_1, alors celui-ci va bien invalidé sur APC Serveur_1 et memcache mais pas sur APC Serveur_2. Donc si on fait une demande sur APC Serveur_2 il n’y a aucun moyen de savoir si sa valeur dans APC est à jours, sauf si on compare avec memcache (mais si on fait ça on perd donc tout l’intérêt car il faudrait à chaque requête checker dans APC et memcache ce qui rend APC useless).
    Il faudrait donc créer une sorte de communication entre le Serveur_1 et Serveur_2 pour lui dire que le cache APC a été invalidé. Soit à la manière d’un « trigger » (qui peut être lourd en communication) soit à la manière d’un cron job.

    Cela va forcément impliquer une possibilité que les clients ne voient pas tous la même chose au même moment. Mais dans une application non critique ce risque peut être raisonnable. D’autant certaines bases NoSQL ont aussi la propriété que plusieurs clients n’aient pas la même vue au même moment.

    • C’est une bonne idée de mixer les deux. L’invalidation doit être prévu au niveau applicatif afin d’agir sur le local et sur le serveur Memcache. L’idée d’utiliser APC pour du cache doit être fait avec parcimonie (à mon avis). Il est bon d’avoir un cache d’OPCODE dans tous les cas. Ensuite pour gérer un cache centralisé d’objets métiers, Memcached est une très bonne solution ainsi que Redis.
      Ensuite, il ya le killer caching : Varnish ! Il y a une conf sur le sujet à la conf PHP de cette année.

      • Pourquoi dis tu que Varnish est un « killer caching » et qu’a t il de plus que Squid en reverse proxy ? Qui au passage à l’air d’avoir un coup d’apprentissage moindre que Varnish

        • Je n’ai jamais eu l’occasion d’installer et de paramétrer Varnish. Par contre, là où je travail, les AdminSys ont mis en place une infra avec du Ngnix + Varnish et ca dépote. D’après leur propos, Squid ne serait pas approprié pour de la haute dispo et supporter une charge importante : c’est ce que j’ai pu comprendre :).
          Pas mal de personne parle de la vélocité de Varnish et de ses capacités à segmenter le cache : Il me semble que lequipe.fr utilise ce système.

  5. Je titille mais as tu eu la chance d’expérimenter le cache via un système de storage « in-memory » dédié comme redis ?

    Je suis conscient qu’il ne s’agisse pas d’un système distribué mais il a rien à envier aux perfs de memcached (d’après ce que j’ai pu lire).
    En contre partie d’un système non distribué, redis offre beaucoup de fonctionnalité que memcached tout en étant plus simple d’installation.

    Pour une application plus modeste, il peut être une belle alternative. Et j’ai même lu que http://stackoverflow.com/ utilise redis comme cache layer (http://meta.stackoverflow.com/questions/69164/does-stack-overflow-use-caching-and-if-so-how/69172#69172).

    • J’utilise Redis pour y stocker des métriques. On peut effectivement l’utiliser comme système de cache avec l’avantage d’avoir de la persistance.

  6. Cela permet de mettre un temps d’expiration sur l’élément mis en mémoire au sein d’APC. La valeur 0 est la valeur par défaut de ce dernier. Si le cache se remplit et que la mémoire Max est atteinte et qu’il y a besoin de cacher un nouvel entrant, alors avec cette valeur par défaut, tout le cache est vidé. Avec une valeur > à 0, APC va essayer de vider les éléments expirés. Il y a d’ailleurs une doc très complète sur toutes les directives d’APC sur php.net (http://php.net/manual/fr/apc.configuration.php)

  7. Ping : Optimisation Web PHP : des caches à tous les niveaux « Le blog PHP de Nicolas Hachet – Développeur Web – Lead dev PHP MySQL

  8. Hello,
    Je rencontre un problème sur un des mes sites web (présent sur un petit serveur dédié). Le nombre de requêtes par secondes est très vraiment faible (10 / sec ). Or j’ai bien installé APC.

    (J’ai essayé de lui associer le zend cache par défault mais ça m’augmente le temps de chargement de la page par deux ou trois, donc j’ai viré le zend cache).

    L’affichage des pages semble pourtant relativement rapide (la home page sur laquelle je fais le test via b -n1000 -c20 http://... s’affiche dans firebug aux allentours 266ms ).

    Voici le retour du test :
    Concurrency Level: 20
    Time taken for tests: 98.367 seconds
    Complete requests: 1000
    Failed requests: 0
    Write errors: 0
    Total transferred: 11351000 bytes
    HTML transferred: 10988000 bytes
    Requests per second: 10.17 [#/sec] (mean)
    Time per request: 1967.350 [ms] (mean)
    Time per request: 98.367 [ms] (mean, across all concurrent requests)
    Transfer rate: 112.69 [Kbytes/sec] received

    Auriez-vous une soggestion pour m’aider à améliorer le nombre de requêtes / secondes ?

Répondre à Djib's Annuler la réponse.

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>