Re: the biggest myfaces webapp

[Martin Marinschek]

What Laurentiu is talking about is not what my original definition of
active was.

I was talking about a request every few seconds - with a few requests
per minute , a few hundred users shouldn't be a problem at all. In any
case I recommend doing performance measurements in such a case to make
sure that the app will be able to cope with the amount of users.

regards,

Martin

On 8/22/06, Eurig Jones <[EMAIL PROTECTED]> wrote:

It will definetly hold, as long as you code it efficiently and as long
as you have enough processing power and memory of course.

What I'm not sure about is how much processing power and memory you need
to achieve that certain level of load. It's impossible to say seeing as
that no-one seems to have created a high-load JSF web site yet.

Laurentiu Trica wrote:
> So there is no answer to this question.
> My app should have 200-300 users logged in at the same time.
> Let's say they will make 2-3 requests/min (each of them) => max 1000
> reqs / min.
> Is JSF going to hold?
>
> I don't know, I made only simple projects in JSF until now...
>
> Thanks in advance
>
> On 8/21/06, *Frederic Auge* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> 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]
> <mailto:[EMAIL PROTECTED]>> wrote:
> > Have u done tests with client side state saving using compression?
> >
> > 2006/8/20, Frederic Auge <[EMAIL PROTECTED]
> <mailto:[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]
> <mailto:[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]
> <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.
> > > >
>   

Re: the biggest myfaces webapp

[Eurig Jones]

It will definetly hold, as long as you code it efficiently and as long 
as you have enough processing power and memory of course.


What I'm not sure about is how much processing power and memory you need 
to achieve that certain level of load. It's impossible to say seeing as 
that no-one seems to have created a high-load JSF web site yet.


Laurentiu Trica wrote:

So there is no answer to this question.
My app should have 200-300 users logged in at the same time.
Let's say they will make 2-3 requests/min (each of them) => max 1000 
reqs / min.

Is JSF going to hold?

I don't know, I made only simple projects in JSF until now...

Thanks in advance

On 8/21/06, *Frederic Auge* < [EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


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]
<mailto:[EMAIL PROTECTED]>> wrote:
> Have u done tests with client side state saving using compression?
>
> 2006/8/20, Frederic Auge <[EMAIL PROTECTED]
<mailto:[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]
<mailto:[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]
<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]
<mailto:[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

Re: the biggest myfaces webapp

[Laurentiu Trica]

So there is no answer to this question. My app should have 200-300 users logged in at the same time.Let's say they will make 2-3 requests/min (each of them) => max 1000 reqs / min.Is JSF going to hold?
I don't know, I made only simple projects in JSF until now...Thanks in advanceOn 8/21/06, Frederic Auge <
[EMAIL PROTECTED]> wrote:nope, I didn't, I think this feature wasn't available at that time.
Also, I didn't use StreamingAddResource context-param as it requiredmodifying 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> &

Re: the biggest myfaces webapp

[Frederic Auge]

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 boa

RE: the biggest myfaces webapp

[David Friedman]

I 
thought someone recently updated the wiki to have a page with MyFaces 
performance tuning tips.  Specifically how adding a special server or 
filter helped pseed things up.
 
Regards,
David

  -Original Message-From: Julian Ray 
  [mailto:[EMAIL PROTECTED]Sent: Sunday, August 20, 2006 11:33 
  AMTo: 'MyFaces Discussion'; 
  [EMAIL PROTECTED]Subject: RE: the biggest myfaces 
  webapp
  Hi Guys,
   
  I'm in the process of tuning our MyFaces app and have 
  been focusing on the Hibernate cache so far. This discussion thread is 
  interesting as I have now moved into the JSF pages to look for bottlenecks etc 
  now thw database tier has been optimized. I'm using OpenSymphony's clicksteam 
  to map user requests and behaviours and page timings.
   
  My question is this. Are there any pluggable components 
  (listeners/filters etc.) that I can use to detemine average server load in 
  requests per min/sec etc. as Rogerio describes in his app before I go and 
  write these myself?
   
  Thanks
  Julian
  
  
  From: Rogerio Pereira 
  [mailto:[EMAIL PROTECTED] Sent: Sunday, August 20, 2006 
  10:11 AMTo: MyFaces DiscussionSubject: Re: the biggest 
  myfaces webapp
  Maybe client state saving with JBossSerialization can increase the 
  performance.
  2006/8/20, Rogerio Pereira <[EMAIL PROTECTED]>: 
  
  
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 
  30requests/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 
  thebusiness tier than the web tier.Regards,FredOn 
  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 hav

RE: the biggest myfaces webapp

[Julian Ray]

Hi Guys,
 
I'm in the process of tuning our MyFaces app and have been 
focusing on the Hibernate cache so far. This discussion thread is interesting as 
I have now moved into the JSF pages to look for bottlenecks etc now thw database 
tier has been optimized. I'm using OpenSymphony's clicksteam to map user 
requests and behaviours and page timings.
 
My question is this. Are there any pluggable components 
(listeners/filters etc.) that I can use to detemine average server load in 
requests per min/sec etc. as Rogerio describes in his app before I go and write 
these myself?
 
Thanks
Julian


From: Rogerio Pereira 
[mailto:[EMAIL PROTECTED] Sent: Sunday, August 20, 2006 10:11 
AMTo: MyFaces DiscussionSubject: Re: the biggest myfaces 
webapp
Maybe client state saving with JBossSerialization can increase the 
performance.
2006/8/20, Rogerio Pereira <[EMAIL PROTECTED]>: 

  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 
30requests/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 
thebusiness tier than the web tier.Regards,FredOn 
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 

Re: the biggest myfaces webapp

[Rogerio Pereira]

Maybe client state saving with JBossSerialization can increase the performance.2006/8/20, Rogerio Pereira <[EMAIL PROTECTED]>:
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 30requests/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 thebusiness tier than the web tier.

Regards,FredOn 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 sit

Re: the biggest myfaces webapp

[Rogerio Pereira]

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 30requests/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 thebusiness tier than the web tier.
Regards,FredOn 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 real

Re: the biggest myfaces webapp

[Frederic Auge]

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

the biggest myfaces webapp

[Yee CN]

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 

Re: the biggest myfaces webapp

[Eurig Jones]

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] 
> 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_)

Re: the biggest myfaces webapp

[Rogerio Pereira]

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 anylarge websites done in JSF.I'm in the same boat as you. I'm developing an application whichpotentially 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 Ipossibly can with the fact that "LOTS of users will be logged on at thesame time", always in the back of my mind. Like with any web framework,
you need to code the application in best possible practices and asefficiently as possible (avoid using session beans as much as youpossibly 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 ingeneral. As for performance, to be honest with you, I feel like I'msailing into unchartered waters, because I really don't know! I can'thelp 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,EurigRogerio 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

Re: the biggest myfaces webapp

[Kevin Galligan]

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 anylarge websites done in JSF.I'm in the same boat as you. I'm developing an application whichpotentially 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 Ipossibly can with the fact that "LOTS of users will be logged on at thesame time", always in the back of my mind. Like with any web framework,
you need to code the application in best possible practices and asefficiently as possible (avoid using session beans as much as youpossibly 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 ingeneral. As for performance, to be honest with you, I feel like I'msailing into unchartered waters, because I really don't know! I can'thelp 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,EurigRogerio Pereira wrote:> Somebody has myfaces webapps with more than 50/100 concurrent users?>
> --> Yours truly (Atenciosamente),>> Rogério (_rogerio_)

Re: the biggest myfaces webapp

[Eurig Jones]

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_) 

Re: the biggest myfaces webapp

[Kevin Galligan]

I mean the following in the nicest way possible.  You sound like my old boss.  You're looking for an assurance without any real detail or logic.  What if I told you that yeah, you'd be fine?  Would you build the app in JSF?
"several hundreds of users active at the same time"Does this mean several hundreds logged in and casually looking around?  Several hundred concurrent requests at the same time?What will they be doing?  Several hundred people logged in for 10 minutes each, and maybe filing out one or two basic forms?  I think you'd be fine.  5 people logged in with database intensive processes that take 5-10 seconds each, and each user is making a request every 15 seconds?  Your app will fail.  And it'll have nothing to do with JSF.
To make a realistic determination, you need to specify what the app will be doing, what the anticipated usage pattern will be, roughly how many users will be on the app, and the class of hardware this will be on.  From the usage pattern and the number of users we can probably figure out how many requests/minute to expect, and if we know what the app is doing, that'll give us a chance to see how intensive the requests will be.
Even then, obviously, no guarantees.It also depends on how stable your application design is.  Personally, I'm coding a site in JSF now, yet I also have struts set up in the app, just in case there are some seriously heavy pages that aren't performing well enough.  In fact, I'm mentally prepared to rewrite the entire app if needed after its done.  Why?  Well, its a lot easier to copy an existing app than to code one from scratch with fuzzy design (which is what I have).  Coding is faster (generally) in JSF, so its faster to prototype and rewrite.  At the same time, I doubt JSF's performance will be a problem.  If the application performance is bad, its more likely due to a database or application design issue.
Rant over.  Details please.On 8/19/06, Laurentiu Trica <[EMAIL PROTECTED]> wrote:
I understand that if I want to build a web application for several hundreds of users active at the same time I should use another technology? JSF would not work? Or you guys just didn't tried it?I'm interested because I'm going to make that web app and I want to know if I can do it with JSF - seams the best for the code, but I don't know many about it's speed...
On 8/19/06, Martin Marinschek <
[EMAIL PROTECTED]> wrote:
More than 100 concurrent users (concurrent meaning active at the sametime) - no!regards,MartinOn 8/19/06, Werner Punz <
[EMAIL PROTECTED]> wrote:> Rogerio Pereira schrieb:
> > Somebody has myfaces webapps with more than 50/100 concurrent users?> >> To my knowledge Irian has done several installations> in the past which are way bigger,> but Martin can comment on that one, not me ;-)
>>>--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development and
Courses in English and GermanProfessional Support for Apache MyFaces
-- Best regards,Laurentiu

Re: the biggest myfaces webapp

[Laurentiu Trica]

I understand that if I want to build a web application for several hundreds of users active at the same time I should use another technology? JSF would not work? Or you guys just didn't tried it?I'm interested because I'm going to make that web app and I want to know if I can do it with JSF - seams the best for the code, but I don't know many about it's speed...
On 8/19/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
More than 100 concurrent users (concurrent meaning active at the sametime) - no!regards,MartinOn 8/19/06, Werner Punz <[EMAIL PROTECTED]> wrote:> Rogerio Pereira schrieb:
> > Somebody has myfaces webapps with more than 50/100 concurrent users?> >> To my knowledge Irian has done several installations> in the past which are way bigger,> but Martin can comment on that one, not me ;-)
>>>--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
-- Best regards,Laurentiu

Re: the biggest myfaces webapp

[Martin Marinschek]

More than 100 concurrent users (concurrent meaning active at the same
time) - no!

regards,

Martin

On 8/19/06, Werner Punz <[EMAIL PROTECTED]> wrote:

Rogerio Pereira schrieb:
> Somebody has myfaces webapps with more than 50/100 concurrent users?
>
To my knowledge Irian has done several installations
in the past which are way bigger,
but Martin can comment on that one, not me ;-)






--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: the biggest myfaces webapp

[Werner Punz]

Rogerio Pereira schrieb:

Somebody has myfaces webapps with more than 50/100 concurrent users?


To my knowledge Irian has done several installations
in the past which are way bigger,
but Martin can comment on that one, not me ;-)

Re: the biggest myfaces webapp

[Rogerio Pereira]

No, just to know.2006/8/18, Gerald Müllan <[EMAIL PROTECTED]>:
You have performance problems with jsf? :)cheers,GeraldOn 8/18/06, Rogerio Pereira <[EMAIL PROTECTED]> wrote:> Somebody has myfaces webapps with more than 50/100 concurrent users?
>> --> Yours truly (Atenciosamente),>> Rogério (_rogerio_)--Gerald MüllanSchelleingasse 2/111040 Vienna, Austria0043 699 11772506
[EMAIL PROTECTED]-- Yours truly (Atenciosamente),Rogério (_rogerio_)

Re: the biggest myfaces webapp

[Gerald Müllan]

You have performance problems with jsf? :)

cheers,

Gerald

On 8/18/06, Rogerio Pereira <[EMAIL PROTECTED]> wrote:

Somebody has myfaces webapps with more than 50/100 concurrent users?

--
Yours truly (Atenciosamente),

Rogério (_rogerio_)



--
Gerald Müllan
Schelleingasse 2/11
1040 Vienna, Austria
0043 699 11772506
[EMAIL PROTECTED]

Re: the biggest myfaces webapp

[Matthias Wessendorf]

martin ?

On 8/18/06, Rogerio Pereira <[EMAIL PROTECTED]> wrote:

Somebody has myfaces webapps with more than 50/100 concurrent users?

--
Yours truly (Atenciosamente),

Rogério (_rogerio_)



--
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

the biggest myfaces webapp

[Rogerio Pereira]

Somebody has myfaces webapps with more than 50/100 concurrent users?-- Yours truly (Atenciosamente),Rogério (_rogerio_)