2010-07-20 6 views
3

Je viens de profiler mon application de reporting lorsque j'ai essayé de générer quatre fois le même rapport d'affilée. le premier a pris 1859ms alors que les suivants ont seulement pris entre 400 et 600ms. quelle est l'explication de cela? pourrais-je en quelque sorte l'utiliser pour rendre mon application plus rapide? le module de rapports s'exécute sur le serveur et attend que l'utilisateur clique sur "imprimer le rapport".accélérer jasperreports

Répondre

3

Les passages suivants du rapport ont une mémoire étendue et remplissent divers caches. N'ayant jamais vu votre application, je suppose que le plus grand effet est que votre serveur de base de données met en cache les données que vous recherchez. Il charge les données du disque et en mémoire, et n'ayant rien de mieux à faire avec cette mémoire, il le laisse là. La prochaine fois que la requête arrivera, la base de données n'aura pas à aller sur le disque pour les données, elle est toujours là en mémoire.

La manière la plus simple et la plus simple d'exploiter ceci est d'exécuter une requête "fausse" avant que vos utilisateurs ne soient lâchés sur le système; Cela signifie que vous aspirez l'attente de 1800 ms et que vos utilisateurs obtiennent le bon 400. Malheureusement, cela ne fonctionnera que si toutes les requêtes sont identiques, c'est-à-dire si tout le monde demande le même rapport. S'il existe différents rapports et différentes données, les caches seront vidées pour différentes données et il faudra plus de temps pour charger les nouveaux résultats. En bref: Si vous avez toujours eu la même requête, vous pouvez donner des réponses très rapides, mais vous ne présenterez rien de nouveau.

+0

Merci pour le conseil! Je n'utilise pas de fichiers db mais xml mais l'effet est le même .. une grande partie du temps du premier appel va à la requête xpath. Je ne m'attendais pas à cela, car cela semble si trivial. – martin

+0

Parsing XML est une quantité incroyable de travail! À quelle fréquence ce code XML change-t-il? Vous pouvez configurer un écouteur de cycle de vie qui analyse le code XML dans un DOM et le stocke dans la session de servlet. Ensuite, les requêtes exécuteront XPath mais n'ont pas besoin d'ouvrir ou d'analyser le fichier. Si le code XML est mis à jour occasionnellement, vous pouvez écrire une autre servlet qui force une nouvelle analyse. –

+0

Avant que vous m'écoutiez: Faites un peu de journalisation et découvrez quelles opérations sont en train d'absorber le temps. Mon conseil aborde le coût de la lecture des fichiers et de l'analyse XML, mais il est possible que le temps soit dépensé ailleurs. –