Utilisez le cache de requête intégré de MySQL au lieu d'essayer de le maintenir vous-même. Il effacera automatiquement les requêtes mises en cache dans les tables lorsqu'elles seront écrites. De plus, il fonctionne en mémoire donc il devrait être très efficace...
Aussi, ne vous contentez pas de mettre en cache les requêtes. Essayez de mettre en cache des segments entiers de l'application à différentes étapes du cycle de rendu. Vous pouvez donc laisser MySQL mettre en cache les requêtes, puis mettre en cache chaque vue individuelle (rendu), chaque bloc individuel et chaque page. Ensuite, vous pouvez choisir d'extraire ou non du cache en fonction de la demande.
Par exemple, un utilisateur non connecté peut obtenir la page complète directement à partir du cache. Mais un utilisateur connecté peut ne pas être en mesure de le faire (en raison de son nom d'utilisateur, etc.). Donc pour lui, vous pourrez peut-être rendre 1/2 de vos vues sur la page à partir du cache (puisqu'elles ne dépendent pas de l'objet utilisateur). Vous bénéficiez toujours de la mise en cache, mais celle-ci sera échelonnée en fonction des besoins.
Si vous vous attendez vraiment à beaucoup de trafic, cela vaut vraiment la peine d'examiner Memcached
. Laissez MySQL stocker vos requêtes pour vous, puis stockez tous les éléments du cache utilisateur dans Memcache...
Modifier : Pour répondre à votre modification :
Les systèmes de fichiers peuvent devenir lents si un seul répertoire grossit. Tant que vous "espacez les noms" par répertoire (ainsi, chaque répertoire ne contient qu'une petite partie des fichiers de cache), tout devrait bien se passer de ce point de vue. Quant au seuil exact, il dépendra vraiment de votre matériel et de votre système de fichiers plus que de toute autre chose. Je sais que EXT3 devient assez lent s'il y a une charge de fichiers dans un seul répertoire (j'ai des répertoires avec littéralement des centaines de milliers de fichiers, et cela peut prendre jusqu'à une demi-seconde pour simplement stat() l'un des fichiers, et encore moins faire n'importe quel type de liste de répertoires)...
Mais sachez que si vous ajoutez un autre serveur, vous allez soit avoir une duplication du cache (ce qui n'est pas une bonne chose), soit devoir réécrire toute votre couche de cache. Y a-t-il une raison de ne pas utiliser Memcached depuis le début ?
Modification 2 : Pour répondre à votre dernière modification :
C'est encore trop difficile d'appeler. J'ai une application qui a une base de données avec environ 1,5 milliard de lignes (croissance d'environ 500 000 par jour). Nous n'utilisons aucune mise en cache car nous n'avons pas de problèmes de concurrence. Et même si nous le faisions, nous ferions mieux de lancer plus de serveurs MySQL plutôt que d'ajouter une mise en cache, car toute forme de cache aurait un taux de réussite si faible qu'il ne vaudrait pas la peine de le développer pour l'ajouter.
Et c'est la raison pour laquelle je suis si catégorique sur le fait de ne pas mettre en cache pour la vitesse. Il y aura toujours un objet qui n'est pas en cache. Donc, si vous accédez à une page avec l'un de ces objets, il doit toujours être rapide. En règle générale, j'essaie de mettre en cache tout ce qui sera de nouveau accessible dans les prochaines minutes (je garde un temps de vie d'environ 5 minutes en production sur d'autres applications de toute façon). Donc, si les éléments ne reçoivent pas plus de quelques occurrences au cours de cette période, ou si le taux de réussite est très faible (moins de 90 %), je ne prends pas la peine de mettre cet élément en cache....
