Mise en cache pour les requêtes fréquemment modifiées

Question

Nous avons une application Web qui écoute les appels de service Web, construit les requêtes, extrait les données de la base de données et renvoie les résultats au client. Étant donné que nous rencontrons des problèmes de performances, nous souhaitons mettre en cache les données côté serveur. Les requêtes sont complexes qui impliquent plusieurs jointures. La base de données est mise à jour via une autre application qui se trouve en dehors de l'application Web. Je ne pense pas que nous puissions utiliser EHCache car la base de données n'est pas mise à jour via la même application et les paramètres de la requête changent fréquemment. Quelles stratégies de Caching pouvons-nous adapter ici pour améliorer la performance? Remarque: Les requêtes sont optimisées pour de meilleures performances.

Answer 1

Je ne pense pas que nous utilisons ca EHCache que la base de données est mise à jour ne par la même application

Si vous ne passez pas par l'API Hibernate, Hibernate ne sera pas en mesure de invalidate les zones de cache de second niveau pertinentes si nécessaire. Mais vous pouvez le faire vous-même (voir les diverses méthodes evictXxx sur le SessionFactory). Selon la fréquence des mises à jour, vous pourriez avoir des avantages. Notez également que EHCache est juste une mise en œuvre de cache de second niveau parmi d'autres (que vous utilisiez EHCache ou non, cela n'utilise pas le cache de second niveau qui est pertinent pour la question).

(...) et les paramètres de requête changent fréquemment.

C'est plus ennuyeux. L'utilisation du cache de requêtes fonctionne bien pour les requêtes fréquemment exécutées (y compris les paramètres). Si la ré-exécution d'une requête donnée (y compris les paramètres) est un événement improbable, vous ne tirerez pas beaucoup de bénéfices du cache de requêtes.

Dans ce cas, j'essaierais peut-être d'utiliser Query#iterate() au lieu de Query#list(). Alors que le plus tard retourne les résultats de la requête comme List, avec l'ancien:

Les entités retournées comme les résultats sont initialisés à la demande. La première requête SQL renvoie des identifiants uniquement.

Cela pourrait donner de meilleures performances IF les entités correspondant aux ID sont dans le cache de niveau 2. Si ce n'est pas le cas, cela ne fonctionnera pas mieux.

Quelles stratégies de mise en cache pouvons-nous adapter ici pour améliorer les performances?

Je n'ai pas de meilleure suggestion que celle ci-dessus. La mise en cache fonctionne lorsqu'un cache est un événement probable.

Remarque: Les requêtes sont optimisées pour de meilleures performances.

Hmm ... que voulez-vous dire? :)