Jacob Hookom's Blog

JSF More Performant than Action Frameworks?

With traditional Action MVC frameworks (Struts), you have a specific set of scopes to store state in over transactions: request, session, and application. Often, while developing applications with Action MVC frameworks, you have to make a decision to store objects/state in the request or the session. There can be consequences to the the performance of your application in either case. You can go the transient route and just retain state for a request cycle, or you can live with and manage it in your session.

Let's disect a request to an MVC application-- when you compare the time your in-memory Java code takes compared to DB calls, often times, the time spent by the MVC framework is marginal-- JSF or Struts. So we go back to trying to fix performance with the DB by either specializing operations in the request or storing results in the session.

JSF has acted as a foundation for frameworks like JBoss Seam and Oracle ADF because it provides context to user interactions. These contexts can be used to scope cached data in more meaningful processes without committing to a full transient (request) or persistent (session) solution. It becomes much more practical to store results from the DB within the context of a particular paging table component, avoiding the 600ms->20sec DB queries. I hope you see my point.

Take a look at your caching strategies and ORM mappings-- what's driving those fetch policies and associations? Are you making decisions to not-lazy fetch an association because you display it with the parent object? I would say that a lot of your decisions around caching/fetching policies is formulated by what's being coordinated in the presentation. Doesn't it make a lot of sense then to have a MVC solution that retains and manages those contextual associations for you?

Now, pair that meaningful, contextual state management with encapsulated AJAX components that can communicate back to that managed state without 'requiring' DB calls for partial requests....

Comments

• Is this a joke? I thought you were serious up until you tossed in the obligatory AJAX shout-out. Not I'm not so sure. Hopefully you're just joshing with us poor readers.

  Posted by: plightbo on February 08, 2006 at 04:05 PM

• Just to be clear: only about the most trivial applications store objects in such simplistic scopes as request/session/application. Real apps actually have caches that have very complex policies for clearing and are finely tuned for maximum performance, regardless of your web framework.

  Posted by: plightbo on February 08, 2006 at 04:10 PM

• Patrick, it's not a joke at all-- I was hoping to engage some serious conversation around MVC bottlenecks-- and based on the numbers I've seen in presentations and online, the performance issues really come down to resource bottlenecks outside of the MVC framework itself. New'ing a bunch of crap in eden memory vs. stateless decoration is comparatively nothing to the overhead of ORM reflection and DB accesses. So no matter if you pick JSF or WebWork, you are still left with the necessary optimization or resolve of resource performance and management within Web scopes.

  Posted by: jhook on February 08, 2006 at 04:11 PM

• My point is that we constantly tune our applications towards the needs of the user/presentation. What makes the most obvious sense given the interaction or process the user is completing. While you are right in saying that 'real' apps actually have caches with very complex policies for clearing and are finely tuned.... maybe the point is that solutions like Seam or ADF remove those complexities since they are based around our first goal of tuning performance for user interaction.

  Posted by: jhook on February 08, 2006 at 04:15 PM

• Give me a break. Real apps require clustering, and all of this simplistic crap you're talking about goes out the window. Then you start needing something like Coherence to manage your cache, or else you go and hit the database every time.

  Posted by: jcarreira on February 08, 2006 at 08:42 PM

• Thanks for re-emphasizing my point-- it shouldn't have to get thrown out and it shouldn't require embeding a separate caching solution just to get around managing your http session efficiently over a set of interactions.

  Posted by: jhook on February 08, 2006 at 09:05 PM

• the more components you have the more data will be there. And you can not reuse data. Plus your pages will be so huge.

  Posted by: dnamiot on February 09, 2006 at 04:09 AM

• As someone that built a large enterprise application with JSF, I can say that it was great for rapid development. Having so much context information available with every request was great when developing a complex application with constantly changing business requirements.
  However, we ran into major scaling issues with JSF due to this context information. With complicated views, the JSF Component Tree gets very large, which leads either to large sessions, or a large data transfer on the client with each request/response. With large sessions, you hurt your clustering efforts, with large client data transfers, you reduce the number of clients that a single node can support.
  Much of this problem can be reduced by reducing the context information that JSF transmits with each request. Essentially, each request only needs a _very_ limited amount of the JSF Component Tree's context, but you always get the whole thing.
  Furthermore, a lot of data that is essentially hard-coded in a JSP, CSS styles, attribute values, etc. Rather than being stored directly in the compiled JSP, it must be stored in the JSF component tree where it is usually unprocessed and passed directly into the outputted HTML.
  JSF is great for prototyping, but you cannot ignore that web development is limited by HTTP's inherent transaction-based nature. You cannot use a rich-client programming model to interact with a controller on a server the same way you could with a controller on a client. Action-based frameworks are based around these transactions, and gain great performance from that basis.
  Unfortunately, we had to retire our JSF application soon after it was moved to production. We just couldn't get it to scale. We've since moved to Eclipse RCP. Ironically, it took a move to a rich-client to realize the scaling power of a transactions-based system.

  Posted by: heaththegreat on February 09, 2006 at 06:50 AM

• Sorry about the bad formatting, I included the allowable html, but it obviously didn't work.

  Posted by: heaththegreat on February 09, 2006 at 06:53 AM

• +1 for heaththegreat.

  jacob, I didn't re-emphasize your point. For many enterprise applications, state can't be maintained on only one node, and once you need to start replicating the state, you REALLY want to have tight control over what you're saving. From Heath's story, it sound like that was the problem they had with JSF.

  Posted by: jcarreira on February 09, 2006 at 06:56 AM

• jason, i don't think you can use this as an example as to why action based frameworks are better-- they went to eclipse RCP-- not an action based framework.

  Posted by: jhook on February 09, 2006 at 08:41 AM

• Some things need to be rich client apps. Some things need to be web apps. JSF unfortunately tries to straddle the fence between the two.

  Posted by: jcarreira on February 09, 2006 at 08:57 AM

• oh yeah? well my MVC framework can beat up your MVC framework's daddy!

  Like someone said above, the real power of performant db-backed apps are in the caching layer or indexes of some sort to query against. I'm not even sure what's attempting to be proven here, but whatever it was, it didn't include numbers!

  Posted by: ilazarte on February 09, 2006 at 09:36 AM

• no... really-- ummm... some sort of query with caching layers-- yeah-- that's what I'm talking about. let's make everything stateless within our IoC and MVC and then worry about going back in and trying to setup proper lifecycles around our data for given user transactions... what if your caching policies are around what the user is doing-- you fetch tabular data or an order over a series of transactions, what choice do you have for managing those lifecycles in relation to other things the user may be doing? do you simply maintain that cache scope at the global level with a 'cache layer' so you are so separated from your process context that you are doing maintaining everything as a special case across layers? Why not have an MVC foundation in place that caters to 'real world' interactions instead of constantly dealing with the lowest common denominator of HTTP in a rampant series of special cases around state transfer and caching?

  Posted by: jhook on February 09, 2006 at 09:47 AM

• We went to an action-based framework for our DB queries. Basically, we now have a stored procedure for every DB hit we need to make. We have customized translators to avoid needing to rewrite translation code to and from our SQL statements. This really helps performance. --newline--- The reason we went to RCP over JSF was the ease of building a solid user interface in RCP. JSF has too many Javascript gotchas because its deployed to HTML. We even had the luxury of deploying only to IE6, and we still had lots of Javascript bugs. ---newline--- Again, I'm not bashing JSF. I really liked it for rapid application development. When performance must take a back seat to agility, it can't be beat. However, if I had to do everything all over again, I'd probably look to force as much down to the client as possible. Probably, with web services invoked with an XmlHttpRequest or hidden iframe and xslt. This allows for a great separation of concerns. Your Java guys can create great services, and your AJAX guys can create a great web interface.---newline--- Of course, I've never tried to do this on a grand scale, so I could be totally wrong. Thankfully, RCP may have saved me from needing to prove myself right.

  Posted by: heaththegreat on February 09, 2006 at 01:09 PM

• There's a group of us in JSF, working to basically embed the SOA- or partial processing requirements you're bringing up. At the very least, JSF's ability to manage components in iterative contexts eases developer concerns. I really appreciate the fairness of your comments.

  Posted by: jhook on February 09, 2006 at 01:31 PM

• Just so it's clear: I wasn't claiming anything about MVC frameworks or styles. I just think that even supposing that one style produces a better outcome when discussing such a complex topic as performance is being a litte disingenuous.

  Posted by: plightbo on February 09, 2006 at 01:34 PM

• i'm not going to beat around the bush, my intentions were to get others looking at a different way to increase performance, other than simply walking away from the ideas of stateful/component MVC frameworks.

  Posted by: jhook on February 09, 2006 at 02:08 PM

• heaththegreat: fyi, I blogged about the issues with JSF state saving; I totally agree that the current implementations save waaaaay too much unnecessary information. (It's JSP's fault.)

  Posted by: adamwiner on February 09, 2006 at 05:42 PM

• Adam and Jacob,
  I've been really impressed with the strides that JSF has made in the past year. It really makes me disappointed that I had to leave the community (I used to be a MyFaces Developer). I hope this gets worked out.

  (BTW, for formatting, use <br> not <br/> Having the slash screws up the preview page.

  Posted by: heaththegreat on February 10, 2006 at 06:39 AM

• Mr. Hookom - does this entry hint at what Gavin King and the JBoss Seam folks have brought to the table being married to JSF/Facelets/Avatar ?

  Posted by: colintoal on March 02, 2006 at 02:09 PM

• > Essentially, each request only needs a _very_ limited amount
  > of the JSF Component Tree's context, but you always get the whole thing.
  I have not delved that deep into JSF, but I know that ASP.NET allows to turn viewstate on/off for a whole page or for specific components. What does JSF offer in this regard?

  Posted by: michael_jouravlev on March 07, 2006 at 02:20 PM

• each component has the ability to be marked 'transient', also you can avoid using the JSF h:form which will prevent state from even being written/stored.

  Posted by: jhook on March 07, 2006 at 02:30 PM

This work is licensed under a Creative Commons License.