Additionally, a slight warning: there are some caveats in the "special JSF implementation MyFaces" regarding performance right in the moment, not all is implemented with performance as the first priority...
The biggest problem might be that the response is cached in memory before it is sent out - with large responses, that might be a problem for your application. I don't believe there are any such caveats with many users, though... Generally: If you use client side state saving, you have higher CPU impact, but less memory requirements, server side state saving turns this upside down... regards, Martin On Thu, 13 Jan 2005 23:17:44 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On Fri, 14 Jan 2005 00:58:22 -0500, Adib Saikali <[EMAIL PROTECTED]> wrote: > > I too am trying to making a decision about using JSF or not in a production > > project. I building an web app that is modular with rich user interactions > > and I want to run the app as an application server provider model. I highly > > attracted to the component nature of JSF and the fact that JSF ships with > > nice components that I can use right away. > > > > The choice to use Java has been made but I am not sure if should be using > > JSF or some other framework. Is there anything about how JSF works that will > > put it at a significant performance disadvantage compared to Struts? How > > would the CPU and memory profiles of JSF app compare to the same app built > > in Struts? > > > > When I was early in my computer career (the 1970s, ancient history for > many of you :-), the PL/1 language was just coming onto people's > radar. What was interesting is that there was more than one compiler > for the language -- and the code generated by the various compilers > had dramatically different performance on different types of > benchmarks. When you think about it a bit, this is exactly what you > should expect -- different compilers would have different optimization > strategies, focused on different types of use cases. But what was the > predominant press statement? > > "PL/1 is slow." > > Does anyone appreciate the naivety that is illustrated by such a statement? > > What does the specification of a language have to do with whether a > particular compiler implementation sucks or not? > > What does the fact that implementation X might suck at particular task > A have to do with the fact that implementation Y might excel at that > task? > > Yes, you can make the case that there are features of the particular > technology that are hard to implement efficiently. There are > certainly pieces of JSF's requirements that can create performance > challenges for an implementation. That being said, there is NO WAY to > predict any particular performance characteristics of JSF versus any > other particular technology ... the precise performance implications > are going to be a combination of the particular JSF implementation you > are using, plus the precise way you are using it. > > A question like "is JSF scalable" is not possible to answer in any > general sense. You can only rationally ask "is implementation X of > JSF scalable for use case Y". There is no such thing as meaningful > generalizations on the performance of a technology (like JSF) with > multiple implementations (like JSF) in particular use cases (like > yours). > > Craig > > > > -----Original Message----- > > Wrom: UCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXR > > Sent: January 13, 2005 11:49 PM > > To: MyFaces Discussion > > Subject: Re: JSF - Robust? Scaleable? Ready for prime time? > > > > Before trying to evaluate JSF as a potential technology solution for > > your requirements, I would first try to figure out if the webapp > > paradigm (no matter what implementation technology you choose) is > > appropriate to the task. For order entry environments that are > > primarily form fill-in (with little server interaction until the order > > is complete), it is likely that this approach is appropriate. If you > > need *lots* of interactions during the process of filling out the form > > (i.e. making one choice dramatically affects the UI for subsequent > > choices), you need to think carefully about whether a thick client > > approach might be more appropriate. > > > > If a web architecture looks suitable for your requirements, you'll > > find that JSF implementations in general are on the CPU-intensive side > > of the scale on the server side (but it's a *big* scale, with *lots* > > of application specific variations), but this is counter balanced by > > the fact that the client side interactions consume zero server side > > resources. If your primary constraints are database or network, it's > > not likely to matter at all. If your primary constraint is CPU speed > > on the app server (not common, but might occasionally be the case), > > this potentially matters. > > > > As you can see, there's no such thing as a general answer to your > > question. The only true benchmark for your application is running > > your application :-). > > > > Craig > > > > On Thu, 13 Jan 2005 21:59:40 -0600, Aaron Bartell > > <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > I am curious to know the different scenarios people have implemented JSF > > > and how intense the applications were. The reason I am asking is I am > > > wondering if JSF could survive the replacement of a 5250 Order Entry > > > application written in RPG on an iSeries. This particular application > > > has 500+ users hitting it with many different database requests. Note > > > that you cannot relate 500+ users using a standard website to the > > > demands of an order entry app. There is just a lot more going on in > > > order entry vs a shopping basket. > > > > > > I understand that a lot has to do with the hardware you are running, how > > > well you are load balanced, memory dedicated to your app server, etc. I > > > am more wanting to know if JSF can perform with the best (the best being > > > legacy systems that support thousands of users off of one server). > > > > > > I am not necessarily skeptical, I just need positive reinforcement. > > > > > > Thanks for any input, > > > Aaron Bartell > > > > > > > >
