There was _very_ significant gain when caching was turned on. However, I didn't do any exact benchmarks, but it did appear that the gains were on the order of 4X to 5X.
Pat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dag Liodden Sent: Wednesday, January 21, 2004 1:17 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load Has anyone benchmarked this yet? Just curious. :) Francisco Hernandez wrote: > excellent, ill give this a shot. > > Dag Liodden wrote: > >> >> 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 ------------------------------------------------------- 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
