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

Reply via email to