Some time ago, I also came to the same conclusion that when activating velocity caching of templates, rendering is done much faster. One thing I still don't know how to solve is the following: In Dag velocity.properties example there is the line:
> file.resource.loader.path = .,WebRoot which if I understand correctly is necessary for enabling caching. Is "WebRoot" some magic word for velocity/ww2 or is just an guideline so that one should put there specific path where the templates are located. If so, the problem is I don't want to have hardcoded the WebRoot path, in the configuration. Does anyone know out to enable caching in velocity (using ww2) which doesn't require such hardcoded path configuration? Thanks On Thursday 08 January 2004 23:46, Patrick Lightbody wrote: > Dag, this is great work -- could you please open a bug for this? > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Dag Liodden > Sent: Thursday, January 08, 2004 2:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load > > > I think that using the taglib is slow due to the massive amount of > template parsing that is associated with rendering of the tags. By > default, Velocity does not cache templates and so each tag will result > in loading and parsing the templates. I've done a very simple > stress-test with profiling and turning on resource increased performance > > noticeably on results with extensive use of the taglib (e.g a large > input form). Mathias, since you obviously have a test-harness ready to > go, perhaps you could turn caching on and give us some figures? > > Below is a simple Velocity configuration that goes into > velocity.properties in WEB-INF with caching turned on. The modificattion > > interval is in seconds and could probably be adjusted up too (I use 2 > seconds since it's adequate for development) - I think zero means never > refresh but I can't really remember from the top of my head. > > -- Snip -- > > velocimacro.library = VM_global_library.vm,tigris-macros.vm > > runtime.log.error.stacktrace = true > runtime.log.warn.stacktrace = true > runtime.log.info.stacktrace = true > runtime.log.invalid.reference = true > > # Resource loaders > resource.loader = file, class > > file.resource.loader.description = Velocity File Resource Loader > file.resource.loader.class = > org.apache.velocity.runtime.resource.loader.FileResourceLoader > file.resource.loader.path = .,WebRoot > file.resource.loader.modificationCheckInterval = 2 > file.resource.loader.cache = true > > class.resource.loader.description = Velocity Classpath Resource Loader > class.resource.loader.class = > org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader > file.resource.loader.modificationCheckInterval = 2 > file.resource.loader.cache = true > > velocimacro.permissions.allow.inline = true > velocimacro.permissions.allow.inline.to.replace.global = true > velocimacro.permissions.allow.inline.local.scope = false > > velocimacro.context.localscope = false > > #----------------------------------------------------------------------- > ----- > # INTERPOLATION > #----------------------------------------------------------------------- > ----- > # turn off and on interpolation of references and directives in string > # literals. ON by default :) > #----------------------------------------------------------------------- > ----- > runtime.interpolate.string.literals = true > > > #----------------------------------------------------------------------- > ----- > # RESOURCE MANAGEMENT > #----------------------------------------------------------------------- > ----- > # Allows alternative ResourceManager and ResourceCache implementations > # to be plugged in. > #----------------------------------------------------------------------- > ----- > resource.manager.class = > org.apache.velocity.runtime.resource.ResourceManagerImpl > resource.manager.cache.class = > org.apache.velocity.runtime.resource.ResourceCacheImpl > > -- Snip -- > > Cheers, > > Dag > > Jason Carreira wrote: > >I think there's still a major Velocity tuning issue there that we need > >to address... > > > >>-----Original Message----- > >>From: Francisco Hernandez [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, January 08, 2004 3:28 PM > >>To: [EMAIL PROTECTED] > >>Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load > >> > >> > >>i've noticed that using webwork2 taglibs is slow.. the more i use the > >>slower requests get > >> > >>BOGAERT Mathias wrote: > >>>Hi, > >>> > >>>I'm currently stress testing my application on WebLogic 8.1 under > >>>extreme load. It seems Xwork has some blocking issues, especially in > >>>regard to OGNL (getting/setting values on the stack). > >>> > >>>Before I go further to investigate deeply, did anyone see > >> > >>this before? > >> > >>>And are there any best practices concerning threads and the > >> > >>way a web > >> > >>>application should be written? > >>> > >>>Thanks, > >>>Mathias Bogaert > >>> > >>> > >>>------------------------------------------------------- > >>>This SF.net email is sponsored by: Perforce Software. > >>>Perforce is the Fast Software Configuration Management > >> > >>System offering > >> > >>>advanced branching capabilities and atomic changes on 50+ platforms. > >>>Free Eval! http://www.perforce.com/perforce/loadprog.html > >>>_______________________________________________ > >>>Opensymphony-webwork mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: Perforce Software. > >>Perforce is the Fast Software Configuration Management System > >>offering advanced branching capabilities and atomic changes > >>on 50+ platforms. Free Eval! > >>http://www.perforce.com/perforce/loadprog.html > >> > >>_______________________________________________ > >>Opensymphony-webwork mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > >------------------------------------------------------- > >This SF.net email is sponsored by: Perforce Software. > >Perforce is the Fast Software Configuration Management System offering > >advanced branching capabilities and atomic changes on 50+ platforms. > >Free Eval! http://www.perforce.com/perforce/loadprog.html > >_______________________________________________ > >Opensymphony-webwork mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
