Ok.
I understand. I thought that there was no cache at all.
In development, I also need tempalte to be reloaded as soon as possible.
But in production, I don't care at all so this si not, for me, a
performance issue ...
Thanks
Mike
Vlad2006 a écrit :
Hi Mike,
As written in the Wiki:
"Freemarker fails to properly cache templates when they are retrieved from
the classpath. Copying them to the WEB_APP root allows Freemarker to cache
them correctly. Freemarker looks at the last modified time of the template
to determine if it needs to reload the templates. Resources retrieved from
the classpath have no last modified time, so Freemarker will reload them on
every request."
Thus I don't think it is possible to fix cache problem without moving
templates out of the jar. I guess playing with "template_update_delay" you
could achieve that templates are recompiled very seldom. If it is enough for
you, why not. As for me, I would like them to be recompiled as soon (with
small delay) as they changed.
From my experience, more than 90% of all CPU time was spent in Freemarker
classes (template compilation) when I started using tags with templates.
After I have moved templates out of the webwork.jar - it is not an issue
anymore.
Best regards
Vlad
Mike Baroukh wrote:
>If it is your case, you could make it faster, you have to extract
templates
>out of webwork.jar (in your case probably struts.jar) and put them in,
for
>example, WEB-INF/templates directory.
Just to know, I saw this many times but without doing this and using
only "template_update_delay" in freemarker.properties, I can see many
logs like
2007-02-26 13:28:05,624 DEBUG (freemarker.cache:81) -
template/css_xhtml/form-validate.ftl[fr_FR,utf-8,parsed] cached copy not
yet stale; using cached
So do you think the log is wrong and cache is not used or has the
loading template from classpath been corrected ?
Mike
Vlad2006 a écrit :
Hi Zheng,
Have you profiled your application? Are you sure it is OGNL that makes
your
application slow?
From my experience it is not so slow. At least I have not found it too be
a
bottleneck in my application. Not yet :-).
What is really slow in WebWork/Struts2 is jsp tags like, textfield,
radio,
anchor, and other which are using FreeMarker templates.
If it is your case, you could make it faster, you have to extract
templates
out of webwork.jar (in your case probably struts.jar) and put them in,
for
example, WEB-INF/templates directory.
There is a page on WebWork Wiki about it:
http://wiki.opensymphony.com/display/WW/Performance+Tuning
I am not using Struts2 yet, but I believe most of the tips will work for
Struts2.
One more thing that could make application slower is when resource
bundles
are constantly reloaded. It is good for dev but not acceptable for
production. Check in struts property like: webwork.i18n.reload=false
Best regards
Vlad
Shuai Zheng wrote:
Dear All,
I am using struts 2.0.6, but honestly the performance is very bad (not
need
to think about scalability), to speed to load a simple page is much
slower
than pure JSP (I haven't compared with struts 1). To refresh one page it
is
3-5 seconds with only one user. The profiler tells me the OGNL is the
bottleneck.
I notice that there are some complains on OGNL about the performance
already, may I know any other way to replace OGNL with anything else to
get
a faster speed? Currently the speed is not acceptable for production.
Regards,
Zheng Shuai
--
Mike Baroukh
---
Cardiweb - 31 Rue de Mogador Paris IXeme
06 63 57 27 22 - 01 53 21 82 63 - Jabber: [EMAIL PROTECTED]
http://www.cardiweb.com
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mike Baroukh
---
Cardiweb - 31 Rue de Mogador Paris IXeme
06 63 57 27 22 - 01 53 21 82 63 - Jabber: [EMAIL PROTECTED]
http://www.cardiweb.com
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
