struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 林 明 <aftermath_l...@hotmail.com>
Subject Re: [shale] some improvement proposal for performance
Date Thu, 25 May 2006 07:20:37 GMT
thanks much for comments.

Now give some explaination from me. 
To jsf component tree iterating, I only give a guess if we use treemap but 
not arraylist to store children components. The disadvantage of that is 
necessary space of component tree struture will be great larger. But we can 
direct find corresponded component to the request data. for example if we 
find "id0:id8:subview:clay:id19", we can quickly use treemap to find it 
like viewroot.children("id0").children("id8").children("subview")... and so 
on. Because except restoreview and render phase or broadcast event of other 
phases, actually we only need get few components from tree for 
applyrequest,validating or updatemodel. Current, myfaces uses visitor 
pattern to traverse the whole tree. In our project , some page may have 
tens of form inputs components, but have many other layout components , 
component instances easily come up hundreds. so, if we only process 
components needed, jsf will not burden with not good reputation of 
performance.

To merge adjacent verbatim components, because those components usually 
stand in the same
children list and already not in hierarchical node tree after you 
processing and creating ComponentBean Tree, you can at this point to merge 
them.

regards.

aftermath :-)



>From: gvanmatre@comcast.net (Gary VanMatre)
>Reply-To: "Struts Developers List" <dev@struts.apache.org>
>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
>
> >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
> >

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message