Session Bean x Request Bean

What's the throble using session managed bean in an application with jsf?How scalability could be lost with it?
Someone could explain it, please?

Antonio Lazaro Carvalho wrote:What's the throble using session managed bean in an application with jsf?How scalability could be lost with it?
Someone could explain it, please?

Session beans consume long-term memory. The more/larger session beans, the more memory. Multiply that by the number of concurrent users, you get "n*m". Scalability is where you can have something more like simply "n", or at least "log(n)" or something that only grows slowly as you add users.

Unfortunately, JSF tends to require session-scope objects more than most web technologies. Which is why JSF 2 devised new scopes that have more limited lifespans, so that you wouldn't have a lot of internal overhead cluttering up the user's session on a long-term basis.

Often you can trade off memory for CPU. For example, instead of storing an ORM Model object in a session, you can store a handle and dereference that handle when the business logic needs the object.

I have an application that daytime performance is degraded throughout the day. The beans used are session bean, this can cause environmental degradation? How can I monitor this?
At the begining of the project everithing was fine, but the numer of users grows and with it my problems too...
Any evidence that this is my problem?How can I prove it?
I'm new at the project and I need to fix this behavior, but I'm not sure if a change the bean scope will fix it.

It can tip the server into heavy usage of virtual memory. VM is often thousands of times slower than RAM, and worse yet, you can end up in a vicious cycle of page-in/page-out operations known as "thrashing", where the machine is essentially just flailing its arms and not actually getting much done. Unfortunately, simply moving to Request scope may cause the system to cease functioning entirely.

More than that I couldn't say without actually seeing internal stats on the server in question.

I'm trying get this kind information, but at prodction server I have no acess. So I need to prove that is very important running a profiling tool to get this to know what's happen with app.
Simply change scope could be the solution, but the bootnackle could not be there. There is no warning about overhead of memory at the server or connection pool because of it I think that is the jsf scope that cause the lazy problem...