You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Tom Butler <to...@adelphia.net> on 2006/01/20 05:19:20 UTC

application vs. request scope and performance

The initial page of my app is a search page.  The app may have up to 100+
concurrent users.

 

I was considering whether it would be better for performance to set the
backing bean for the search page within the application scope (bean is
multi-threaded and same bean accessed by all users), or, request scope (bean
created/removed for each user accessing the search page)?  

 

Any recommendations?  I see benefits of application scope being bean is
already loaded in memory, but may cause performance issues if too many users
access at once - is there anyway to have multiple copies of an application
scope bean to improve performance?

 

Sorry these are probably more general java questions (within a JSF app) -
let me know if there is a more appropriate forum to post to.

 

Thanks

Tom


Re: application vs. request scope and performance

Posted by Simon Kitching <sk...@apache.org>.
On Thu, 2006-01-19 at 23:19 -0500, Tom Butler wrote:
> The initial page of my app is a search page.  The app may have up to
> 100+ concurrent users.
> 
>  
> 
> I was considering whether it would be better for performance to set
> the backing bean for the search page within the application scope
> (bean is multi-threaded and same bean accessed by all users), or,
> request scope (bean created/removed for each user accessing the search
> page)?  
> 
>  
> 
> Any recommendations?  I see benefits of application scope being bean
> is already loaded in memory, but may cause performance issues if too
> many users access at once – is there anyway to have multiple copies of
> an application scope bean to improve performance?
> 
>  
> 
> Sorry these are probably more general java questions (within a JSF
> app) – let me know if there is a more appropriate forum to post to.
> 

I expect the different in performance will be so small either way that
you'd be very hard pushed to measure it, unless the constructor for your
class has large amounts of processing in it (or member objects doing
that).

Given that JSF uses significant amounts of reflection to perform its
work, the small amount of work done to instantiate a managed bean isn't
significant. 

And anyway, if you use a single multithreaded bean then you'll have to
add synchronisation everywhere which has its own issues.

I would suggest going for the *reliable* approach here - ie avoiding
shared objects with their related threading issues, and just using
request-scope or session-scope beans.

Regards,

Simon