Mise à l'échelle avec memcached pour stocker le fichier gzippé

Question

J'ai un service Web qui sert un fichier source javascript aux navigateurs. Le fichier javascript est compilé par php en temps réel avec certains fichiers inclus. Le fichier résultant change seulement quelques fois par jour. Il est gzippé par apache avant d'être servi aux navigateurs. Je voudrais utiliser memcached pour le servir de la mémoire pour éviter les charges de disque et de processeur d'inclusion de fichiers et de répéter gzip.

Ma question est comment puis-je gzip et stocker un fichier javascript dans memcached et le servir (de php)?

Il me semble que si le fichier n'est pas en stock, je devrais obtenir le fichier par include, récupérer le tampon de sortie, le gzip et le stocker dans memcached. Ai-je raison? Y a-t-il des en-têtes que je devrais ajouter à la sortie ou quoi que ce soit d'autre que je devrais faire pour rendre le résultat compatible avec le fichier gzippé actuellement servi par mon apache?

Mise à jour: Je n'ai pas mentionné que le fichier a plusieurs variations contrôlées par un paramètre url qui provoque l'inclusion de différents fichiers def. Chacune des variations est plutôt statique comme décrit ci-dessus.

Answer 1

Peut-être que la bonne solution est de utilisez la mise en cache intégrée d'Apache sur vos serveurs Web eux-mêmes.

Après tout, ce n'est pas comme s'il y avait beaucoup de variations différentes, ou que cela change fréquemment. Ce ne serait pas (je suppose) un grand succès si chaque serveur de votre ferme génère sa propre copie de temps en temps.

La mise en cache d'Apache respecte l'en-tête "Expires", dans la sortie, il est donc assez facile de l'activer simplement pour ces URI et de sortir les en-têtes appropriés. L '«avantage» de memcached est que vos serveurs memcached forment un pool qui ressemble à un seul cache et peut être partagé par tous vos nœuds Web; ce n'est pas vraiment pertinent si vous n'avez qu'un très petit nombre d'éléments (dans ce cas, il semble que vous en ayez un ou quelques-uns).

Answer 2

Il est préférable d'utiliser les outils appropriés pour les tâches pour lesquelles ils ont été conçus.

Dans votre cas, vous avez un fichier qui change lentement et qui serait servi statiquement. Je veux dire par là que cela ne dépend pas de la requête, mais c'est la même chose pour chaque requête pendant son temps de validité. Pour cela, utilisez un bon serveur Web de mise en cache ou placez un cache/équilibreur de charge devant votre (vos) serveur (s). Soit Squid, Varnish ou NginX ferait l'affaire. En fait, l'un ou l'autre peut servir un fichier statique aussi rapidement que memcached. Assurez-vous simplement de gzipping le fichier vous-même et le servir comme ça. Memcached bat n'importe lequel d'entre eux en vitesse d'écriture, ne sert pas. C'est donc la meilleure réponse pour le contenu qui change avec les paramètres de la requête, donc il doit être généré et expiré constamment (et se chevaucher).

Comme vous compresserez et écrirez le fichier seulement quelques fois, le temps de fermeture/écriture n'est pas important. Après cela, les nombreux niveaux de cache vous permettront d'obtenir les meilleures performances.

Notez également que depuis mencached n'est pas un serveur web, il est cache pas « fermer » au client comme un cache Web approprié serait, annihilant toute la performance de lecture hypothétique avantage