Sweetdev-Ria : des éléments sur la charge serveur

Après vérification, il se confirme que la solution consistant à conserver en session les objets java (les beans) correspondant à l'ensemble des lignes (et pas seulement les lignes comprises dans la première page) surcharge le serveur.

Dans une configuration de 20.000 lignes par 20 colonnes. Il faut compter entre 10 et 20 Mo pour chaque utilisateur !

Il est donc clair que cette solution ne peut pas perdurer.

Solution 1

Utiliser une connexion directe à la base de données et faire une gestion page par page. De cette façon , l'ensemble des actions (comme un tri ou le passage à une autre page) se fait directement en base de données sans rien conserver en session.

Solution 2

1) Faire une requête ramenant l'ensemble des lignes sur le serveur,

2) créer un flux JSON correspondant à l'ensemble des lignes, l'envoyer sur le poste client et faire les actions en javascript dans le navigateurs

à titre indicatif, un tri en javascript de 20.000 lignes (via un sort), prend moins d'une seconde ce qui a priori est comparable avec une requête en base de données pour faire la même requête.

Par ailleurs, si la génération sur le serveur de la chaîne JSON ne pose pas de problème, il n'en n'est pas de même quand la même chaîne est réutilisée par Velocity pour générer la chaîne finale. Dans ce cas, Velocity fait monter le process jusqu'à 500Mo de Ram pour une génération (toujours sur 20.000 lignes par 20 colonnes).

Préconisation (solution 2) : courcircuiter Velocity pour la partie correspondant aux lignes : Velocity se contente en effet de recopier la chaîne JSON (mais explose l'occupation RAM pour ça). Velocity peut donc servir pour la génération de l'entête et éventuellement du pied de table mais devrait être court-circuité pour ce qui est de la gestion des lignes.

Noter que dans ce cas le temps occupé par Velocity devrait être à peut prêt stable (il reste cependant dépendant du nombre de colonnes, mais pas du nombre de lignes).

Un commentaire

  1. Après vérification, le problème de l’utilisation de RAM n’est pas du à Velocity mais bien à la création des objets (Beans) à partir des données brutes.
    Il semble qu’il y ait un rapport de 1 à 10 entre la taille des données brutes et la taille des objets créés à partir de ces mêmes données brutes.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.