nope, I didn't, I think this feature wasn't available at that time. Also, I didn't use StreamingAddResource context-param as it required modifying our jsp.
On 8/20/06, Rogerio Pereira <[EMAIL PROTECTED]> wrote:
Have u done tests with client side state saving using compression? 2006/8/20, Frederic Auge <[EMAIL PROTECTED]>: > Hi guys, > > We had big performance problems with client state saving. > Changing to server helped a lot ! x4-5 improvement for serving pages ! > > We don't have any problems anymore. Our average load is 30 > requests/min 24/24 7/7 > And we could take a lot more (hopefully) > > We use a profiler when we have a specific performance problem > (understand a page that is slow). It's more likely to be in the > business tier than the web tier. > > Regards, > Fred > > On 8/20/06, Yee CN <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I am in the same boat – a distributed application that I was building has to > > be converted to become centralized, so the number of users suddenly becomes > > at least an order of magnitude larger. > > > > > > > > I am thinking memory might not be such a big issue as a multi-CPU Intel > > boxes with 8GB of memory is getting rather common place nowadays. But I am a > > bit concerned about view rendering time. A while back somebody posted a > > benchmark which I recalled was showing that JSF pages took about 4 times > > longer to render, and there were some non-linear issues as well. In > > principle faster CPU plus cheaper boxes for clustering should handle the > > problem, but I am dying for someone to share his/her experience on large > > scale deployment of JSF. > > > > > > > > I have no regret so far – after the initial learning curve the faster > > development/prototype time has been a great advantage to our team. > > > > > > > > Regards > > > > Yee > > > > ________________________________ > > > > > > From: Rogerio Pereira [mailto:[EMAIL PROTECTED] ] > > Sent: Sunday, August 20, 2006 7:31 AM > > To: MyFaces Discussion > > Subject: Re: the biggest myfaces webapp > > > > > > > > > > Thanks guys, this kind of discussion is very useful. > > > > > > 2006/8/19, Kevin Galligan <[EMAIL PROTECTED]>: > > > > > > If memory is the major concern, I think the real unknown is the view state > > storage. To be honest, this is an unknown for me also. Currently I'm > > keeping that stuff on the client. If the page download size isn't too big, > > I think this is the direction I'd stick with even in production, as I don't > > have to worry about old views getting dumped from the session in case the > > user really digs the back button. > > > > But, in general, I'm not sure what the memory issue would be beyond the > > view storage. I'm anti-session for most things anyway, besides carrying > > around some standard user info. I'm planning to rely on smart coding, > > tuning hibernate settings (which, obvisouly, requires the use of hibernate) > > and, possibly, turning on the hibernate cache for certain parts of the data. > > > > However, I do understand your concern. I'm sort of in the same boat. I'm > > implementing an app and I'm not sure how many people will be logging into > > it. I don't know what the performance will really be like. I still think > > there is some technical understanding of the JSF view that I've ignored > > until now that would probably help. If anybody happens to have a good page > > to point to that discusses the view, please forward that along. > > > > What kind of box will this be running on? I assume if this is a production > > app that you might have a few hundred megs of memory available for the > > application to play in? Making that assumption, you've got about a meg per > > user. Right? While compared to some other technologies, a meg per user is > > a lot, but at the same time, hardware is cheap compared to developer time. > > Again, the big question mark in my mind is the view storage. If it were > > stored on the client, in theory you wouldn't need much session space besides > > authentication, if any. Right? > > > > > > > > > > > > On 8/19/06, Eurig Jones < [EMAIL PROTECTED]> wrote: > > > > As far as I'm aware after the research I've done I haven't seen any > > large websites done in JSF. > > > > I'm in the same boat as you. I'm developing an application which > > potentially could have 200/300 users concurrently logged on and this is > > a worry for me too. I'm trying to code the application as carefully as I > > possibly can with the fact that "LOTS of users will be logged on at the > > same time", always in the back of my mind. Like with any web framework, > > you need to code the application in best possible practices and as > > efficiently as possible (avoid using session beans as much as you > > possibly can. etc.) > > > > My concerns are memory usage more than anything. But this is a concern > > not with JSF but with developing my site with Tomcat and J2EE in > > general. As for performance, to be honest with you, I feel like I'm > > sailing into unchartered waters, because I really don't know! I can't > > help looking at PHP/Apache and thinking how efficient and proven it is > > under heavy load (And that wasn't a call for a start on a PHP/Java debate). > > > > Regards, > > Eurig > > > > Rogerio Pereira wrote: > > > Somebody has myfaces webapps with more than 50/100 concurrent users? > > > > > > -- > > > Yours truly (Atenciosamente), > > > > > > Rogério (_rogerio_) > > > > > > > > > > > > > > > > > > -- > > Yours truly (Atenciosamente), > > > > Rogério (_rogerio_) > > http://faces.eti.br > > > -- Yours truly (Atenciosamente), Rogério (_rogerio_) http://faces.eti.br
