Martin, If you look at any postback, the areas that chew up time are:
1. Recreating the component tree 2. Going through the full lifecycle 3. Saving the component tree 4. Rendering the response If you want a hyper-efficient async, granular JSF response, you have to tackle each of these, both in terms of raw CPU and memory allocation (the latter more important when you look at multi-user scalability). Each of these has its own trickiness, and is harder than it seems at first. :) I really have to start blogging; each of these is like a separate article... So, yes, optimizing the lifecycle is a good start, but it's not a complete solution. -- Adam On 11/16/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Sounds promising to me! > > Even though from the perfomance tests that have been posted to the > mailing list a while ago, it doesn't look like going through the > lifecycle is the big problem - but rather restoring/saving the state > if you use client-side state saving. > > Adam, can you confirm that from your experience with ADF Faces? > > regards, > > Martin > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Thanks. That confirms what I suspected (as far as being able to have > > a custom lifecycle using an init param.) > > > > So the suggestion would be in MyFaces to create a new custom lifecycle > > that included the default lifecycle and other optional steps. With > > the right URL or request parameter you would use the nonstandard > > phases (or jump around in a non-standard way). Otherwise you would > > follow the standard steps only. By default (without the special > > servlet context init parameter) you would get the default lifecycle. > > Would this work? > > > > sean > > > > On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > You can configure FacesServlet to have a custom lifecycle using > > > a servlet context init parameter. But you can't, say, have two > > > FacesServlets each running a different lifecycle - one standard, > > > one trimmed for AJAX-ing. That's what JSF 1.2 adds, because > > > you can configure the lifecycle ID as a servlet config > > > parameter, not just a context init parameter. > > > > > > -- Adam > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > I think Craig was referring to the *current* ability to configure a > > > > custom lifecycle. From the javadocs it looks like this is supported. > > > > Can you clarify this some? > > > > > > > > sean > > > > > > > > On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > For the type (a) components (where you need the component tree and > > > > > > model), Craig offered an interesting solution. He was toying with > > > > > > the > > > > > > idea of a custom lifecylce. I hadn't even realized this was > > > > > > possible > > > > > > but it sounds interesting. > > > > > > > > > > > > I posted something on struts-dev asking him for more details. Not > > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile. > > > > > > Perhaps we could modify FacesServlet so that the default lifecycle > > > > > > still applies but that you can also configure it with a specialized > > > > > > lifecycle. > > > > > > > > > > JSF 1.2 offers support for configuring multiple instances > > > > > of the FacesServlet with different lifecycles. Jacob's idea, > > > > > IIRC. (Craig hasn't been especially involved in the JSF > > > > > EG for quite awhile now.) > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
