On 3/4/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > Good point, fixing jasper servlet is a not going to help in production > > env ( and precompiled jsps), so it's probably not worth it. > > > > However - I disagree that JSPs are 'just' servlets - or at least they > > should not be plain and stupid translation of text to 'println' > > servlets. The current behavior of jsps wrt memory is horrible if you > > have lot of content - all the plain text ends up in memory, as part of > > the class. It's good for cheating on benchmarks - bad for production. > > There are far better ways to use the memory. > > The alternative is wasting CPU and disk reading stuff from disk all over > again for nothing, which for most servers are even more useful > resources. We're talking about using less than 128MB of memory here, so > it's not too much (who has more than 128MB of static text in his JSPs ?).
The point is not how much memory you have - but to have control over how it is used. There are plenty of other things that might benefit from staying in memory - a large cache for the data, etc. Many servers might have 4+ G RAM, but they tend to run multiple processes and a JVM might not get all the memory ( also keep in mind the interaction between java and swap might not be pleasant - and jsp/class data can't be paged out, it's very MM unfriendly ) > > If you're interested in the lowest footprint, JSP is not the right > technology: you need a templating (or anything not compiled) technology > and disable its caching features (it will be quite slow, but will use > minimal amounts of resident memory). I'm interested in having control over memory use. Jasper currently requires that all JSP content is kept in RAM - but it can as well use some fixed cache ( like 64M or 128M ) and work better for sites with lots of jsps or less ram. I think JSP is not that bad ( well, there are a lot of bad things in it ) - it is good to have the logic compiled to a java class. My problem is with the static data implementation in jasper. > The only solution is to forbid > scriptlets (or as an option use a processing when a page does not > contain scriptlets - and of course, rewrite a significant amount of > Jasper - way cool :D), in which case compilation is not needed, and we > can simply execute the nodes (memory is saved by optionally discarding > the nodes between requests). Why ? It could as well save all static content in a separate file ( I remember this was implemented at least in part ), and instead of generating the strings in the class, use a cache that manages the string table. That would be more flexible than this patch - and allow more control over how much memory is used. Well - with all the APR and sendfile you could even try to send large chunks of static content from disk - not sure what's the performance benefits in the static servlet for example. > > > IMO separating the strings and loading/unloading them using a cache > > would help a lot in such situations ( i.e. large number of jsps == > > huge memory use ). Unloading not frequently/recently used jsps ( and > > servlets, and webapps ) might also be very nice, assuming they can > > handle being unloaded. But I agree that the current patch is not the > > right solution. > > Unloading the servlet's instance is possible, not the class definition. That's because of the class loader per webapps - I think a flat classloader ( jboss-style ) could handle unloading serlvet definition. But this is not the problem with jsps - if the static content is stored as data ( in separate file from .class ), you don't even need to unload the jsp instance. Unlike a servlet, jsp has the flexibility to generate any code it wants. > Unloading webapps is not possible at the moment (even if it was, modern > webapps take ages and tons of resources to start, so it wouldn't be > practical IMO). Case by case. Unloading and loading webapps dynamically used to work :-) > It still doesn't cost much to give some more perm gen to Sun's VM (still > a fairly manageable amount IMO, but of course, if you want to do hosting > or it's an embedded situation, it's a problem). Many cases would benefit from more control over memory - hosting or embedded or sites with lots of jsps or lots of data. Forcing all static content in memory is not the best use of the memory. > BTW, I am ok with shipping additional presentation technologies with > Tomcat, we do not need to give JSP any special treatment anymore. True, may be better to implement such a thing without all the complexity of taglibs, etc. Well - my home web server has 32M RAM on a 200 Mhz arm ... :-). Of course, I don't plan to run jsp on it - but coyote works well enough. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
