Caching as the page is generated would not help, but pre-caching on
server start up could solve your problem. I would think that the huge
overhead you're experiencing is that when it tries to assemble the page in
question, it's creating and destroying objects to retrieve the proper
language string from the resource bundle and so forth. And with a page with
a large amount of fmt tags, you're doing a great deal of unnecessary
round-tripping.
However, on the other hand, if you create a memory map of all the
translations on server startup, with a more efficient method, then the
servlet should be able to reference the translations much more efficently.
That is assuming that the strings can be used across all requests.
You'd need to replace the fmt tags with custom tags to read off the
memory map instead.
This is the problem I was experiencing (as I described in a previous
email). I was opening a file object, parsing in the xml from the file,
finding the correct value, closing the xml, closing the file, then returning
the value. And it was happening over 100x per page - talk about
inefficient!
When I re-did it to read in all values and store it in memory on
startup, my benchmarks showed that page render times dropped from 700ms per
page to only 10ms, a 70 fold improvement.
Just my two cents.
>
> Some idea. I, however, can't see how it can solve my problem. Again, not lot
> of data has been used previousely.
> Caching can't solve the problem.
>
> Thanks for your thought.
>
> Vernon
--
Tim Kettering
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
