On Fri, Apr 11, 2014 at 5:35 PM, Mikolaj Rydzewski <m...@ceti.pl> wrote:
> On 11.04.2014 17:22, Robert Klemme wrote:
>
>> JSP _is_ a templating mechnism. In what way do you expect another
>> templating mechanism to help here? All the strings (among other stuff)
>> need to be stored somewhere in memory anyway.
>
> Well, IMHO JSP is not only a templating mechanism. It's also a compiler and
> deployer :-(
> All the strings are already stored on disk, I see no reason to store them in
> memory as well.
Then you underestimate the cost of IO and parsing.
> Similar case applies to various CMS systems out there -
> content is stored in database, no reason to keep it permanently in memory.
It makes a whole lot of sense to keep data that is repeatedly needed
closer to where the content is created for clients. (Side note: there
was even a webserver that kept preformatted TCP packets in memory to
be able to serve client requests faster. IIRC this was done by folks
at Sun.)
> My point was to consider using templating engine like e.g. Velocity. There's
> one servlet that is capable of serving any page. Compare it to 16000
> servlets.
You still face the same issue: either you load every template every
time it is needed, this incurs cost for IO as well as parsing of the
template. Or you keep all templates in memory (if most are used anyway
it does not really matter if you load them on demand or at start time)
where you pay the memory cost. You get a little more control with
Velocity because you could devise your own caching scheme. OTOH then
you also need to ensure it's fast for concurrent access etc. The JVM
does all that already with it's GC.
> I mean: anything is good that will read/process content on the fly and will
> not keep it forever in memory.
I beg to differ: careful analysis must show where the problem lies.
Then one can come up with a proper solution. Generally leaving things
out of memory is certainly not a good advice.
Kind regards
robert
--
[guy, jim].each {|him| remember.him do |as, often| as.you_can - without end}
http://blog.rubybestpractices.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
