Nous rencontrons des problèmes d'utilisation inhabituellement élevés de mémoire. Et j'ai observé que de nombreux endroits de notre code, nous tirons des centaines de disques de DB, en l'emballant dans des objets de données personnalisés, en ajoutant à une arraylist et de stocker en session. Je souhaite savoir quelles sont les données recommandées de stockage de la limite supérieure de la session. Juste une bonne pratique de mauvaise pratique genre de chose.
J'utilise JRockit 1.5 et 1,6 Go de RAM. J'ai fait profilement avec JProbe et j'ai constaté que certaines parties de l'application ont une empreinte de mémoire très lourde. La plupart de ces données sont en cours de session à utiliser plus tard.
7 Réponses :
Si vous stockez des données de la session pour améliorer les performances, envisagez d'utiliser une liste de mise en cache véritable puisque le cache est à l'échelle de l'application, tandis que la session est par utilisateur, ce qui entraîne une duplication non spécifique d'objets similaires.
Si, toutefois, vous les stockez à l'utilisateur pour éditer ces objets (ce que je doute, car des centaines d'objets sont trop trop nombreux), essayez de minimiser la quantité de données stockées ou de la recherche optimiste de contrôle de la concurrence.
Je dirais que cela dépend fortement du nombre de sessions actives que vous attendez. Si vous écrivez une application intranet avec <20 utilisateurs, ce n'est certainement aucun problème à mettre quelques MB dans la session. Toutefois, si vous attendez une session de 5000 live par exemple, chaque MB de données stockées par session comptait 5 Go de RAM.
Cependant, je recommanderais généralement de ne pas stocker de données de DB en session. Il suffit de chercher à DB pour chaque demande. Si la performance est un problème, utilisez un cache à l'échelle de l'application (par exemple, le cache de 2e niveau de 2e niveau de Hibernate).
Qu'est-ce que type de données est-ce? Est-ce vraiment nécessaire par session ou pourrait-il être mis en cache au niveau de l'application? Avez-vous vraiment besoin de toutes les colonnes ou seulement un sous-ensemble? À quelle fréquence est-il accessible? De quelles pages doivent-elles être disponibles sur? Et ainsi de suite.
Cela peut rendre beaucoup plus logique de récupérer les enregistrements de la DB lorsque vous avez vraiment besoin. Stocker des centaines d'enregistrements en session n'est jamais une bonne stratégie.
Son besoin par session, je ne peux pas mettre en cache le niveau d'application. Ne sera-t-il pas une performance péage si je récupère à chaque fois de dB même lorsque j'en gagne à la mémoire
Et vous avez besoin de toutes les données de colonne ? Et toutes ces lignes? Sur chaque page? Vous devez être capable d'optimiser un peu. Et oui, stockant généralement des centaines d'enregistrements à part entière en session, peu importe la charge, etc., n'est pas une bonne stratégie.
Cela dépend entièrement du nombre de sessions présentes (ce qui dépend à son tour du nombre d'utilisateurs que vous avez, combien de temps ils restent sur le site et le délai de session) et de la quantité de RAM Votre serveur.
Mais d'abord: avez-vous utilisé un profileur de mémoire pour vous dire que votre "utilisation haute de la mémoire" est causée par des données de session ou simplement deviner?
Si le seul problème que vous avez est "Usage de la mémoire élevée" sur une machine de production (c'est-à-dire qu'il peut gérer la charge de production mais ne fonctionne pas aussi bien que vous le souhaitez), la solution la plus facile consiste à obtenir plus de RAM pour le serveur - beaucoup plus rapide et moins cher que de redéfinir l'application.
Mais la mise en cache des ensembles de résultats entiers dans la session est également mauvais pour une raison différente: que si les données changent dans la DB et que l'utilisateur s'attend à voir ce changement? Si vous allez au cache, utilisez L'un des systèmes existants qui font cela Au niveau de la demande de DB - ils vous permettront de cacher des résultats entre les utilisateurs et ils disposent d'une facilité d'invalidation de cache.
A ajouté encore plus de détails dans la question.
Je dirais essayer de stocker la quantité minimale de données qui suffira à recréer l'environnement nécessaire dans une demande ultérieure. Si vous stockez en mémoire pour éviter un aller-retour de la base de données, une vraie solution de mise en cache telle que MemCache pourrait être utile.
Si vous stockez ces sessions en mémoire au lieu d'une base de données, le rond-point est enregistré et que les demandes seront servies plus rapidement tant que la charge de la mémoire est faible, et il n'y a pas de pagination. Une fois que le nombre de clients augmente et que la pagination commence, la plupart des clients verront une dégradation énorme en temps de réponse. Ces variables et inversement liées.
Il est préférable de mesurer la latence à votre serveur de base de données, qui est généralement assez faible dans la plupart des cas comme un moyen viable de stockage au lieu de la mémoire.
Essayez de scinder les données que vous enregistrez actuellement dans la session dans des données statiques spécifiques à l'utilisateur. Puis implémentez la mise en cache pour toutes les parties statiques. Cela vous donnera beaucoup de réutilisation à l'échelle de l'application et vous permettra toujours de cacher les données spécifiques qu'un utilisateur fonctionne.
Vous pouvez également faire une base de données par utilisateur mini-sqlite et la connecter à celui-ci, et stocker les données que l'utilisateur est accessible, puis récupérez les enregistrements à partir de celui-ci, tandis que l'utilisateur le demande et après la déconnexion de l'utilisateur juste Supprimer la base de données SQLITE.
Je suis en train d'exécuter une application J2EE Struts sur Weblogic 10
C'est une question de plate-forme agnostique vraiment.