Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: gvanmatre@comcast.net (Gary VanMatre)
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [shale] some improvement proposal for performance 
Date: Thu, 25 May 2006 04:55:13 +0000
Message-Id: 
 <052520060455.27503.447538B100011F0600006B6F22092246270A9D9B0E03020E9009@comcast.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="NextPart_Webmail_9m3u9jl4l_27503_1148532913_0"

--NextPart_Webmail_9m3u9jl4l_27503_1148532913_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

>From: �� �� <aftermath_lin2@hotmail.com> 
>
> Hello, every one. I'm an chinese, my english not good enough to express my 
> concepts fluently. say sorry first. 
> 

No worries, but I'm not sure what my excuse for poor English is since it's the only 
language I know :--)

> I would like to start an new idea project in which jsf ,page flow and work 
> flow are integrated seamlessly . it will use pageflow(or dialog) as the 
> user form interfaces for every human activity. Shale clay also acts as an 
> very important role to supply html template capabilities for form 
> designing.Developers can directly bind variables(/beans) of different 
> scopes to jsf component, such as workflow scope(long running, shall be 
> persistent), pageflow scope(may be only lived in session),and other 
> conventional scope(request, session, application). 
> 
> Because its goal aim as an enterprise application, the performance should 
> be considered first.I had read some core code of myfaces and shale clay for 
> finding potential performance defects. so fortunately or my poor skill, 
> only some design look like performance defects. 
> 
> the core thing of JSF processing can be understood as concentrating at 
> managing and consuming component tree(creating, iterating). while using JSF 
> in actual scenarios, component tree may grow larger and larger. so, too 
> many components would influence cpu consuming, and cause reponse speed 
> downward. 
> 
> In every JSF lifecycle phase, walk through the whole component tree 
> depth-firstly every time in myfaces implement. if we have 500 
> components(children components already counted) in a page,we will iterate 
> every component 6 times at least (restoreveiw, applyrequest, validate, 
> updatemodel, invokeapplication, render), and all count is 500 * 6. 
> Apparently, in applyrequest and validate, updatemodel, invokeapplication 
> phases, if we directly mapping and find corresponded component to the 
> request ratherthan using children list and iterating all, we can execute 
> more quickly. Isn't it right ? 
> 

This seems like a valid concern but how do you think a page that large would 
compare to the same page implemented in JSP/Servlet?  My guess is that you 
would have a lot more custom code for each page than the reuse that you get
 with JSF.  

You might have 500 components but you probably only are using 10 unique JSF 
components per page that you most likely didn't have to develop. 

The JSF framework handles more of the non-functional requirements so that you 
only have to develop and maintain the code that solves the business problem.  

However, performance would be a non-functional requirement and I see your concern.  
I would have to evaluate this one in terms of developer resources versus infrastructure 
cost over the long term.
 

> About shale clay, I find a improvable implement point. when clay parsing an 
> raw html template, it will divide every content between "<" and ">" and 
> make them as node tree, and then use builder pattern to transform them into 
> ComponentBean tree, and then transform into JSF Component tree again.But it 
> might well generate too many Verbatim HtmlOutputText components. for 
> example, to string ""<li>a<br>b<br>c<br>d<br></li>", ", clay will eventually 
> generate ten HtmlOutputText component for it even thought it shall be only 
> one HtmlOutputText component. So, if we use large html template,it probably 
> create thousands of components , and cause serious performance problem, and 
> be enlarged largely because current JSF impl will iterate all components 
> over and over again. so , why do not we merge adjacent Verbatim components 
> to one ? 
> 

I've had the same concern.  The clay html parser makes a DOM like tree
from the document.  This makes it easy to convert to a JSF component tree.
Each html node finds a corresponding builder object based a rule.  I couldn't
find a way to merge nodes.

Something that I've been working on this week is allowing for multiple 
namespaces.  The namespaces is associated with a chain of rules that
assign builder.  I was planning on creating support for the standard JSF core
and html namespaces with an extra jsfid attribute (similar to facelets).
I wouldn't want to loose this direction but we might be able to find a way
to merge these verbatim nodes.  

Furthermore, each verbatim node has two components.  One for the beginning
and ending nodes. I was thinking about creating a custom renderer for the 
outputText/verbatim that would eliminate several components within the 
page component tree.

One advantage of the html node to JSF component is that we might be
able to add some ajax effects in the future by just using html markup. 


> The other worry is about 
> "org.apache.shale.clay.config.beans.ConfigDefinitionsWatchdogFilter". this 
> filter will work in every request. so, if we have one hundred html or xml 
> templates, in every request there are also 100 dirty check for those files. 
> if we use URL obj to access files time property,i think it may be an 
> expensive and no-worthy operation. why do not we place watch dog dirty 
> checking work in an independent daemon thread and intervally check, i.e. 
> check every 1 minute?Of course, if we can use hotswap object when dirty 
> checking to assure thread safe, it would be more perfect. 


The html templates are cached after the first time they are processed.  The 
TemplateConfigBean checks its internal map and doesn't re-parse if it can find 
a "top-level" component definition.  

There is an optional preprocess filter command ConfigDefinitionsWatchdogFilter
in the chain-config.xml that looks for files defining the cached ComponentBean's.
This command is triggered on every invocation based on the includes.

includes="\S*\.faces,\S*\.html,/index\.jsp,\S*\.xml"

There are dependencies between the types of configuration files.  The common
config files are loaded on startup.  The html templates are loaded on demand and 
the XML templates that define the page entry point can be loaded on startup or
on demand.  All of the config files have a dependency with the common configs.
If one of these files are changed, all of cache has to be invalidated.  There are
also checks from the other two types of templates. 

It should be removed for production ready code.  We talked about threads but 
decided against any threads not managed by the web container.  


> 
> the following code demo an hotswap design for file change monitoring. the 
> only limitation is that shall use getMap() first and once. 
> 
> map idMap = getMap(), and latter use idMap variable through an request 
> thread. you can use weaked referenced variable and threadlocal to improve 
> the following demo further. 
> in clay, watchdog maybe hotswapable I think. 
> 

I'm not sold on the Thread based file watch but I don't have a good handle on
what types of threading are allowed.  I'll go with Craig's opinion on
this one. 

I like your ideas about reducing the number of components.  Let's take a look
at this one.  

Gary


> regards 
> aftermath 
> ==================================================================== 
> public class SecurIDUserAuthMechanism 
> implements UserAuthenticationMechanisms, FileChangeListener{ 
> private static SecurIDUserAuthMechanism instance = new 
> SecurIDUserAuthMechanism(); 
> 
> private Map usr_mchnsm_map = new HashMap(); 
> private Map usr_mchnsm_map_old = new HashMap(); 
> 
> private SecurIDUserAuthMechanism() { 
> } 
> public static SecurIDUserAuthMechanism getInstance() { 
> return instance; 
> } 
> public void fileChanged (File file){ 
> load(file); 
> } 
> synchronized public boolean load(InputStream input) { 
> try { 
> Map temp = new HashMap(); 
> BufferedReader reader = new BufferedReader(new 
> InputStreamReader(input, 
> "GB2312")); 
> String line; 
> while((line=reader.readLine())!=null) { 
> if (line.trim().length() > 0) 
> temp.put(line.trim(), "DYNAPASSWORD"); 
> } 
> setMap(temp); 
> return true; 
> } 
> catch (Exception ex) { 
> return false; 
> } 
> } 
> synchronized public boolean load(File file) { 
> boolean success = false; 
> try { 
> FileInputStream in = new FileInputStream(file); 
> success = load(in); 
> } 
> catch (Exception ex) { 
> } 
> return success; 
> } 
> private synchronized Map getMap() { 
> return usr_mchnsm_map; 
> } 
> private synchronized void setMap(Map map) { 
> usr_mchnsm_map_old = usr_mchnsm_map; 
> usr_mchnsm_map = map; 
> } 
> public boolean isHasMechanism(Principal user, String mechanismName){ 
> Map map = getMap(); 
> if (map.containsKey(user.getName())) { 
> return true; 
> } 
> else 
> return false; 
> } 
> public boolean isHasMechanism(Principal user, SecurityLevel level){ 
> return isHasMechanism(user, level.getSecurityLevelName()); 
> } 
> public boolean isHasMechanism(String user, String mechanismName){ 
> Map map = getMap(); 
> if (map.containsKey(user)) { 
> return true; 
> } 
> else 
> return false; 
> } 
> public boolean isHasMechanism(String user, SecurityLevel level){ 
> return isHasMechanism(user, level.getSecurityLevelName()); 
> } 
> } 
> 
> _________________________________________________________________ 
> �����������ѽ��н�������ʹ�� MSN Messenger: http://messenger.msn.com/cn 
> 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org 
> For additional commands, e-mail: dev-help@struts.apache.org 
> 
--NextPart_Webmail_9m3u9jl4l_27503_1148532913_0--