Re: AW: [OS-webwork] Xwork/WebWork2 under extreme load

Fri, 30 Jan 2004 19:22:09 -0800

velocity.properties should be placed in WEB-INF, not on the class path.

Dag

Fernando Martins wrote:

I think by adding this to your wework.properties.
webwork.velocity.configfile=velocity.properties


On Friday 30 January 2004 18:45, Hans Prueller wrote:


how can I configure velocity template caching in webwork?? just adding a
velocity.properties into classpath???

thx
hans



-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im
Auftrag von Fernando Martins
Gesendet: Freitag, 30. Jänner 2004 18:28
An: [EMAIL PROTECTED]
Betreff: Re: [OS-webwork] Xwork/WebWork2 under extreme load


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


-------------------------------------------------------
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




-------------------------------------------------------
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

Reply via email to