With regards to client/server view state. I did a simple test and
compared file-size of a request with both. This was a simple form with
about 7 items on it and no images...
Client state: The download was about 11.92kb
Server state: 7.3kb
Another example which was with a more complex page
Client state: 24.3kb
Server state: 8.6kb
These are my own crude tests so bear that in mind ;-)
Kevin Galligan wrote:
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]
<mailto:[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_)
