Inquiétude concernant la consommation en ressources de Drupal (pour site à fort trafic)

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by mamadoo06 on

Bonjour,

J'ai installé Drupal, la plupart des modules qui m'apportent les fonctionnalités dont j'ai besoin pour mon projet et ai migré le contenu de mon site actuel vers le site off line Drupal.

Je commence le tagging et la mise en page mais une chose m'inquiète beaucoup.
Je fais tourner le site sur un serveur local plutôt body buildé (core 2 quad q8200 avec 4 Go de RAM) sur Wamp (avant de basculer sur Lamp) et, franchement, cache activé, moi en tant que seul utilisateur... ça rame...

Je ne peux pas me permettre d'attendre le lancement de la nouvelle version pour me rendre compte que le site nécessitera une architecture matérielle pas possible.

J'ai un objectif à court terme de 75 000 pages vues par jour et de 150 000 d'ici 18 mois.

Je vais devoir acheter une centrale électrique et 500 machines ???
Qui ici fait tourner sur Drupal des sites avec ce genre de trafic ? Sur quelle plateforme matérielle ?
Une Dedibox XL serait elle suffisante ?

Merci

Forum : 
Support général

Soumis par Yoran le 9 Juillet, 2009 - 15:14

Le problème est que "ça rame" est un notion assez vague :-) Que donnes comme chiffres FireBug (onglets réseau) ? C'est la page principale qui est lente à charger ? Les ressources ? Tout ?

En plus tu ne dis pas quel distribution tu utilises....

Pour info je suis à l'aise sur une Dedibox v1 (via C7 1go) avec en gros 6k pages/jours. J'ai en gros aussi des réponses dans les eaux de la secondes.

Sinon pour optimiser vite fait :

1/ Déjà, vérifie si "ça rame" lorsque tu es non identifié (sauf si tes 75kpages, tu comptes les avoir qu'avec des utilisateurs connectés). Le cache de page n'est pas utilisable lorsque tu es connecté, et donc tu n'as pas, en tant qu'admin par exemple, le bon ressenti sur la vitesse.

2/ Avec un tel espace mémoire, moi je mettrais un gros cache de requêtes à ton mySql/postgreSQL (qu'utilises-tu ?).

3/ As-tu installé/activé APC ? Si oui, as-tu désactivé la diabolique option "stat" ?

4/ Toujours avec cette belle mémoire, moi je prendrais le module "cache router" et je le paramétrerais pour utiliser APC pour stocker le cache de Drupal en mémoire et pas en base de données. Pour cela, tu dois aussi augmenter l'espace mémoire "user" dans le .ini d'APC

5/ Tu prends le "Database logging", et tu le mets à la poubelle (désactive le ça suffira :), et active le watchdog via le module "syslog".

6/ Tu es certains de ne pas avoir laissé dans ton code des choses comme rebuild_menu(), drupal_theme_registry_rebuild(), etc ?

7/ Monte la durée de vie de ton cache de page à quelque chose d'utile et raisonnable. Eventuellement passe le en aggressive.

8/ Si là ça rame toujours (en tant qu'anonyme hein :), là il faut installer le module "devel" pour voir si tu n'as pas des requêtes de malade générées par un vilain module.

Voilà ce qui me vient en tête

Soumis par mamadoo06 le 9 Juillet, 2009 - 15:49

Hé bhé, ça c'est de la réponse et beaucoup de tes remarques dépassent mes compétences ! Déjà, un GRAND MERCI.

Le serveur local n'est malheureusement pas la copie de ce que nous aurons pour l'hébergement, que ce soit niveau matériel ou logiciel (et là heureusement). C'est un PC tournant sur Win7 64bits avec WAMP, install par défaut. J'avais déjà testé avec une Ubuntu 64 et c'était sensiblement pareil en terme de temps de réponse.

Pour l'hébergement nous avions pensé partir sur une Dedibox XL en pensant que ce serait largement surdimensionné au début vu que notre site actuel, développé sur mesure par mes soins, peut tenir sans problème sur un 90Plan OVH même en charge, avec un record de 20 000 VU/jour (pour 80kPV).

Je précise de suite que je n'ai aucune connaissances en admin serveur, juste le minimum pour faire tourner un site. Je pensais prendre la dédibox et me payer les services d'un admin serveur pour l'install, paramétrage, optimisation.

Pour mon Drupal local :

  • Je précise d'entrée que je viens de tester NON connecté, le site est très rapide (remarque c'est quasi un site statique car tout est en cache).
  • Une fois connecté, l'enfer pointe le bout de son nez.
    Devel m'indique entre 180 et 270 requêtes par page (je n'ai jamais vu quelque chose de semblable).
    Une page classique (un article sur le site) prend entre 1 et 3 secondes à s'afficher totalement (du clic sur le lien à la fin de l'affichage) et je dirais que 90% de ce temps est du moulinage du serveur (dont j'entends les ventilos doubler de vitesse). D'autant plus étonnant que la RAM n'est pas du tout saturée et que la charge CPU ne dépasse pas les 30 % quel que soit le coeur.
  • Afficher une page crée avec Panels et contenant quelques bloc Views peut prendre 4 secondes.
  • L'affichage de la liste des modules (peut pertinent, je serai le seul à le faire) prend jusque 20 secondes et génère... 5840 requêtes...

Pour tes questions :
1) répondu
2) J'utilise Mysql5, nous avions prévu un seul dédié (dédibox XL) avec 2 Go de ram et Apache et SQL tournant sur une seule machine.
3) Non je ne sais même pas ce que c'est
4) idem
5) ok, ça vient d'accélérer les choses, on passe d'inadmissible à épouvantable lol
6) je n'y ai pas touché en tout cas
7) ok je ferai des tests
8) non, que en connecté, encore heureux...

Je ne peux pas prédire quelle sera la part de connectés / non connectés mais je pense que tabler sur 25 % n'est pas irréaliste. Si un seul user arrive à faire morfler ma machine locale, j'imagine même pas 200 personnes en même temps.

Dire que j'ai vendu Drupal comme quelque chose qui nous fera économiser des sous...

Soumis par haza le 9 Juillet, 2009 - 16:35

Et en connecté, mais sans devel.

Sinon, on peut pas (pour moi) comparer les perfs d'un wammp et d'un "vrai" serveur web. J'ai toujours eu des perfs bien bien meilleurs sur des environnement de prod, sans que ce soit forcement des machines de guerre.

Soumis par mamadoo06 le 9 Juillet, 2009 - 16:55

Sans devel, c'est simple (et je ne m'étais même pas posé la question) le gain va de 100% à 500%, incroyable de voir ce que ce module peut consommer comme ressources.

Mais on est toujours à une réactivité inacceptable vu la machine (et tenant compte du fait que rien ne transite par le web en plus) ET vu l'utilisation de Drupal que je vais faire (site éditorial pro):

Selon Firebug, 1 seul utilisateur connecté :
- de 1.8 à 3 sec pour afficher un article
- de 2 à 4.5 sec pour afficher la home
- de 2 à 4 sec pour afficher le contenu d'une catégorie (une liste de titres d'articles)
Et sans être connecté, la première consultation d'un type de page est quasi aussi lente, mais la seconde, grâce au cache a des performances de très haut vol :
- 79 ms (si si) pour la home
- 100 ms pour un article (contre 1.5 sec pour la première consultation)

Chaque anonyme se voit attribuer "son" cache ?

Pour un site amateur, vous allez trouver que c'est pinailler pour rien, mais pour un site pro, avoir des pages qui prennent une à 2 sec pour s'afficher est impensable !
Si Google était 30% plus lent, ... son CA chuterait de 30%.

EDIT : ah oui, j'ai testé sur un mutu OVH 90plan juste pour voir, vous pouvez tout multiplier par rien, deux ou trois selon les pages.
Mention spéciale pour certaines pages de l'admin qui ... ne s'affichent pas : time out !

Soumis par Yoran le 9 Juillet, 2009 - 17:01

Pour répondre à tes deux remarques :
180 et 270 requêtes par page (je n'ai jamais vu quelque chose de semblable).
Ce n'est pas mal mais c'est pas le pire non plus. Un MySQL proprement configuré devrait absorber cela très rapidement. Tu as affiché la liste de tes requêtes en les classant par temps d'exécution ?

Sinon moi c'est Windows que je ne connais pas, je ne me suis jamais trop amusé avec un WAMP (d'ailleurs c'est assez rigolo ce concept quant on connaît l'histoire de l'acronyme LAMP :). En tout état de chose, si tu es à 30% de cpu, c'est soit tes disques qui laguent (y'a un moyen d'avoir la charge IO sur windows ?) ou un problème réseau (DNS ?). Ton MySQL est en MyISSAM ou en InnoDB ?

Afficher une page crée avec Panels et contenant quelques bloc Views peut prendre 4 secondes.
Alors déjà rien que comme cela, faire un haut trafic avec du Panels et du Views, c'est assez osé :) Essaye au moins de te passer de Panels si c'est faisable.

L'affichage de la liste des modules (peut pertinent, je serai le seul à le faire) prend jusque 20 secondes et génère... 5840 requêtes
- La liste des modules, c'est assez normal que ça soit lent, mais à ce point là, tu as clairement un problème. Combien as-tu de modules ? Ah oui, une chose, désactive le module "Update Status" et dis moi si cela devient miraculeusement plus rapide ;-)

Pour les points numérotés
1) ok, pour te donner à ce moment là un ordre d'idée, ma machine de dev est assez proche de la tienne, j'affiche la page de garde d'un de mes client à "un peu plus" de 270 requêtes en 0.8s sur une VM a qui j'ai alloué 1GO et 1 core. Je suis à 0.2s avec 2 core hors la VM. Donc je confirme, t'as un soucis d'installation (ou alors c'est windows, mais là je suis pas compétent pour répondre).

2) Fait gaffe avec deux machines en Dedi, je ne suis pas certains qu'elles soient reliées par un switch privé. Donc tu risques de perdre du temps en communication réseau entre les deux bécanes.

3)4) APC est un accélérateur de code PHP, n'imagine même pas mettre un Drupal en production sans cela. En gros, cela précompile le code PHP en mémoire. L'intérêt du paramétre apc.stat c'est que tu l'obliges à ne lire le disque qu'un seule fois s'il n'a pas le fichier en cache. L'autre avantage d'APC est qui permet aux applications PHP de mettre leurs objets en cache mémoire, d'où le point n°4. Sur une machine de production à haut traffic, tu oublie l'idée de laisser le cache drupal en base de donnée, c'est en RAM ou en fichier. Les deux options sont utilisables avec "cache router"

5) Si cela a accéléré les choses, c'est que Drupal écrit beaucoup dans le watchdog, essaye de voir ce qu'il y racontes.

Dire que j'ai vendu Drupal comme quelque chose qui nous fera économiser des sous..
Ne soit pas choqué par ma remarque mais Drupal ne va pas te paramétrer ton environnement. Les performances que j'obtiens avec le même materiel prouve que le problème ne vient pas de Drupal. Si tu mets ne serait ce qu'une seconde pour effectuer 200 requêtes, c'est qu'il y a forcement un malaise.

Ceci étant dit, monter un site haut trafic avec Drupal c'est obligatoirement connaître chacun des modules que tu utilises, ça fait parti du travail.Si tu charges la mule avec beaucoup de module emboîtés les uns dans les autres sans évaluer le coup traitement-requête de chacun, tu vas au devant de gros problèmes.

Soumis par mamadoo06 le 9 Juillet, 2009 - 18:31

Premier point, encore merci pour ces réponses avisées et cordiales. Ca fait plaisir de ne pas se faire sauter dessus par des Geek !

Ensuite, non tu ne me choques pas, bien au contraire. Je suis bien conscient que non seulement une grosse part de l'optimisation doit se faire niveau serveur, mais aussi que je n'ai pas du tout les compétences pour dire que Drupal ne serait pas bon, ou lent, ou quoi que ce soit.

Pour répondre à tes remarques :
- Pour les performances de Windows Seven, mon site actuel tourne plus vite encore que chez mon hébergeur. De même, j'avais testé sur Ubuntu 64 et je n'ai pas noté de différence visible de performances. Je dois donc surement pâtir des paramètres et modules par défaut des install WAMP et LAMP.
- Pour ce qui est de la base MySQL, MyISSAM.
- Me passer de Views ???? Mais ??? Ca me parait impossible !
Pour Panels par contre, si j'ai bien compris, un thème sur mesure peut remplacer son usage. C'est bien ça ? (je suis "développeur" xhtml/css, pas de souci pour moi)
- Update Status était déjà désactivé, c'est le premier que j'ai dégagé.
- J'ai 39 modules mais dont certains sont insignifiants (Captcha, ou alors des sous modules comme celui permettant à CCK d'avoir un champ number). Dans les modules lourds, j'ai CCK et Views, j'ai désactivé Panel tout à l'heure.
- 1) ok pour l'info merci
- 2) non non, une seule comme dit plus haut :)
- 3)4) ok je vais voir comment installer ça
- 5) watchdog désactivé

10 ou 15 000 VU c'est pas ce que j'appelle du gros trafic!

Soumis par Yoran le 9 Juillet, 2009 - 19:01

Tout de même très fort cette histoire de localhost, ça m'assoie un peu sur le derrière... Mais bon...

Pour les performances de Windows Seven, mon site actuel tourne plus vite encore que chez mon hébergeur. De même, j'avais testé sur Ubuntu 64 et je n'ai pas noté de différence visible de performances. Je dois donc surement pâtir des paramètres et modules par défaut des install WAMP et LAMP.
Hum... Si tu veux Windows XP, le seul truc dont je me souvienne, s'était un machin appelé SP1... Windows je ne connais vraiment plus. Ce n'est ni par snobisme, ni par trollitude, je disais juste les choses comme elles sont : je n'ai pas la compétence pour en juger.

Me passer de Views ???? Mais ??? Ca me parait impossible !
Si si, c'est possible, je passe ma vie à ça ;-) Mais bon, déjà si tu peux virer Panels, ce sera pas mal. Fait déjà des tests avec et sans Panels et observe les différences pour voir si ça se justfifie. Même avec une mise en page en vrac, juste pour tester. Je ne connais pas sur le bout des doigts ce module, mais la dernière version m'a paru ressembler à une véritable usine à gaz

J'ai 39 modules mais dont certains sont insignifiants (Captcha, ou alors des sous modules comme celui permettant à CCK d'avoir un champ number). Dans les modules lourds, j'ai CCK et Views, j'ai désactivé Panel tout à l'heure.
Donc pas de soucis, ça devrait aller. Le problème vient donc bien de LAMP. Vérifie juste que tu n'as pas activé des modules de droits comme "content access" qui peuvent avoir le mauvais goût de modifier, et d'alourdir, les requêtes.

10 ou 15 000 VU c'est pas ce que j'appelle du gros trafic!
ça fait du 10 pages minutes en lissé, effectivement c'est pas énorme. Si ça peut te rassurer je monte à 5 fois plus avec de la réserve.

Soumis par mamadoo06 le 9 Juillet, 2009 - 19:19

Merci merci.

Par contre, tu as un site qui tournent à 5 x 15 000 soit 75 000 VU ?! C'est du lourd lourd lourd là. J'ai d'ailleurs, si tu le veux bien, quelques questions à te poser en privé du coup, conernant moins Drupal.
Avec un PVV moyen de 5 (belle performance pour un site éditorial, bof pour du communautaire) tu dois tourner à environ 375 000 pages vues / jour. Me dis pas que tu fais ça sur un "pauvre" Core 2 Duo avec 4 Go de RAM ?!

Soumis par Yoran le 10 Juillet, 2009 - 09:24

Je ne raisonne pas avec tes unités, je ne suis pas du monde du web à l'origine (je ne sais d'ailleurs pas ce que veut dire PVV). Le 5x est une estimation que j'ai essayé de rendre réaliste, ce qui n'est pas forcement fiable car les bécanes ne sont pas des DediXL (Quad core). Le site en question (qui n'est pas mon site, mais juste celui sur lequel j'interviens), on tourne maintenant entre 400 et 500 pages par minutes en étant pas encore à 100% de charge (d'où la réserve), avec une machine pour mySQL et 4 pour les apache/php avec un varnish pour la balance de charge. Et tout cela en Drupal 5. Je compte obtenir de bien meilleurs performances en Drupal 6, sachant que ce site à la spécificité d'être à majorité d'utilisateurs authentifié (donc pas de cache de page).

C'est tout cela que j'ai essayé de mettre dans "l'équation" pour te donne une échelle.

Soumis par mamadoo06 le 10 Juillet, 2009 - 09:36

PVV veut dire pages vues par visite et je me suis trompé en l'employant car je pensais à PVJ : pages vues jour.

Ok donc selon les stats que tu donnes, et si les 400 / 500 pages minute sont une moyenne et non une pointe, tu dois bosser sur un très très très gros site. Pour un tel trafic (donc estimable à 130 ou 150 000 visiteurs uniques par jour selon les PVV), 4 serveurs pour Apache/PHP et MySQL ne me choque pas. Je vise à moyen terme un trafic 10 à 5 (dans mes rêves les plus fous) fois inférieur donc un serveur devrait tenir la route, surtout que je ne pense pas que la plupart des visiteurs seront authentifiés.

Quels outils utilises tu pour faire du test de charge ?

J'avais discuté avec un des responsables de l'infogérance pour France 2 web et ça c'est du lourd.

Soumis par Yoran le 10 Juillet, 2009 - 10:10

Disons que c'est une moyenne qui dépend des périodes. Là c'est l'été et c'est bien plus calme.

Quels outils utilises tu pour faire du test de charge ?
Si tu parles de tests de charges avant production, aucun, car je n'ai pas grande confiance en ce genre d'outil et lorsqu'ils sont bien, c'est un travail de dingue de maintenir les scénarios. En revanche j'ai rajouté des indicateurs internes à Drupal pour me donner toutes les stats en temps réel (nb pages vues, temps de construction, temps pris en SQL (ventilé maj/select), hits memcache, etc.). C'est de là que je tire mes chiffres.

Soumis par mamadoo06 le 9 Juillet, 2009 - 18:55

Bon.

Je passe par 127.0.0.1, je n'ai rien fait d'autre à l'install par défaut de Wamp que d'installer APC.

Et là c'est miraculeux. Aucune page ne dépasse les 800ms pour requête, chargement et affichage complet.
Incroyable qu'un si petit fichier puisse métamorphoser une machine.

Donc c'est bien un problème de config.

Par contre, une question, comment faire un test de charge sur un site en local pour connaitre mon point de rupture à venir ?

Soumis par xaa le 15 Juillet, 2009 - 13:42

avec le module /devel tu pourrais avoir une première idée, non ?
http://drupal.org/project/devel

"Devel est destiné au développeurs et autres designers, il vous facilitera la vie lors du développement d'un nouveau site. Il peut ainsi générer des contenus factices (utilisateurs, noeuds, commentaires, catégories...), afficher les requêtes exécutées lors de l'affichage d'une page, et bien d'autres choses encore."
http://www.ineation.com/drupal_modules_partie1

Soumis par siiim le 21 Août, 2009 - 12:13

Salut les gens,

J'aurais aimé avoir quelques infos sur le module Cache Router. J'ai essayé de l'installer mais sans résultats. J'ai donc :

  1. Installé le module
  2. Modifié le fichier settings.php

C'est la que ça plante ! Il semblerai que c'est la ligne
$conf['cache_inc'] = '.sites/all/modules/cacherouter/cacherouter.inc'; qui fasse tout foirer (page vide toute blanche quand je laisse cette ligne).
Pourtant j'ai essayé de modifier cette adresse en remplaçant le point par "http://www.monsite.com/sites/all/modules/cacherouter/cacherouter.inc" ou par "http://www.monsite.com/modules/cacherouter/cacherouter.inc" ou encore par ""var/www/monsite/sites/all/modules/cacherouter/cacherouter.inc" etc.. Enfin bref de multiples combinaisons et toujours une page blanche.

J'ai donc cherché des patchs (http://drupal.org/files/issues/db_missing_argument_fix.patch, http://drupal.org/files/issues/file-engine-fix.patch, etc.) et toujours rien de bien.

Donc si tu utilises CacheRouter j'aimerai bien que tu me files des infos (ou des directions dans lesquelles chercher)

Sinon votre discussion est très intéressante et utile, Merci à vous.

Soumis par siiim le 27 Août, 2009 - 14:20

Salut,

petite infos supplémentaires à propos de CacheRouter :

  • J'ai l'impression qu'il faut avoir les URL simplifiées activées pour que ça fonctionne.

  • Tu peux choisir différentes manières de mise en cache : file (par fichiers), db(par ta base de données), APC, memcache, e-accelerator et x-cache. Les quatre derniers sont des extensions PHP à installer sur ton serveur. D'après ce que j'ai lu, file et db ne sont pas les plus performants, et APC reste le meilleur (à tester...).

  • Pour APC, il faut apparement installer sur ton serveur PHP un package APC, qui fait partie des extensions PECL. Il faut donc avoir accès à la config de ton serveur, ce qui n'est pas mon cas, je n'ai donc pas pu aller plus loin. Quelques adresses : http://pecl.php.net/package/apc pour le package et http://us.php.net/apc pour l'install et la config.

  • Visiblement, cacherouter n'apparaît pas dans les menus de configuration de Drupal (contrairement à ce que suggère les prises d'écran de drupal.org), il faut donc te débrouiller sans.

  • Pour finir, j'ai opté pour un autre module (Boost) qui en fait me convient parfaitement, puisqu'il met en cache toutes les pages uniquement pour les utilisateurs anonymes (les visiteurs). Il a divisé par deux ou trois les temps de chargement des pages. Cela dépend si ton site aura beaucoup d'utilisateurs connectés ou pas.

Voilà a peu près tout ce que je sais sur CacheRouter, mais ce serai bien de compléter ou corriger les infos, ça m'intéresse beaucoup pour mes futurs projets, et ça en intéressera beaucoup d'autres.

A bientôt,
Simon.

Soumis par Yoran le 6 Septembre, 2009 - 14:42

Cache router est encore un projet bien jeunot (mais à suivre de près). Après l'avoir pas mal éprouvé j'ai cependant opté pour memcache qui est largement plus stable. A backend équivalent (memcached), cache router avait une fuite (du coup un % de hit plus faible). Sûrement un bug qui traîne et qui n'est pas forcement présent sur les autres backends.

Soumis par nyl auster le 7 Septembre, 2009 - 11:23

Bonjour
La solution APC and co semble impossible si on ne posséde pas un serveur dédié ou virtuel du peu que je comprends à ces histoires.

A part le module boost qui semble améliorer la mise en cache pour les anonymes en passant par des fichiers plutôt que pour la db, est ce qu'il existe pour moi un moyen d'améliorer les performance sur un hébergement mutualisé qui ne supporte pas APC ?

meci pour votre avis :-)

Soumis par nyl auster le 7 Septembre, 2009 - 12:51

J'avoue que je ne comprends rien à tout ça... Est-il possible d'utiliser zend optimizer (installé par défaut chez infomaniak apparemment) avec Drupal ? Si oui que faut-il faire ?

Ou bien utiliser un "accélérateur php" requiert t-il forcément de passer par un module Drupal afin de "connecter" les deux?

Soumis par Yoran le 7 Septembre, 2009 - 15:36

C'est assez simple en fait. Pour commencer, les accélérateurs PHP quels qu'ils soient sont totalement transparent pour Drupal. S'ils sont installés, Drupal pédale plus vite mais il n'y a aucun module à installer pour cela.
Le "truc" c'est que ces accélérateurs utilisent une bonne quantité de mémoire pour faire leur job qui consiste à stoquer en mémoire le code PHP optimisé. Du coup, la majorité d'entre eux (tous ?) proposent un jeu de fonctions PHP permettant à un programme d'utiliser cet mémoire pour son usage. C'est là que les modules comme Cache Router rentrent en jeu.

En standard Drupal utilise le fichier includes/cache.inc pour gérer les 3 fonctions de cache (get/set/clear) qui se fait en standard dans des tables en base de données. Mais en paramétrant le settings.php il est possible de remplacer cette gestion par une autre comme celle de cache router qui permet d'assouplir les possibilités en ajoutant un stockage du cache dans la base de données (mode standard), dans des fichiers, ou encore en mémoire en utilisant ces fameuses fonctions fournies par les optimisateurs.

En somme, lorsqu'il s'agit d'utiliser ces fonctions pour le cache de Drupal, oui, il faut passer par un module. Pour ce qui est de Zend Optimizer je ne sais pas s'il est pris en charge par Cache Router (j'en doute) mais rien n'empêche de créer son propre "backend" en recopiant celui d'APC et en remplaçant par les fonctions spécifiques de cet optimizer (que je ne connais pas).

A notre que lorsqu'on a une grappe de serveurs, APC n'est pas utilisable car cela signifierais un cache par machine ce qui peut être très gênant. En effet, si l'on modifie un article, il sera à jour sur la machine qui reçoit le POST mais obsolète sur toutes les autres... Du coup, on passe par un véritable serveur de mémoire (memcached) qui permet de partage sur une des machines une portion de sa mémoire et aux autres d'y accéder via TCP/IP. Le backend memcache existe pour cache router mais là je conseille plutôt le module spécialisé "memcache" qui marche pour l'instant beaucoup mieux.