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: [EMAIL PROTECTED] (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: 林 明 <[EMAIL PROTECTED]>
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
