Performance and scalability: MVC architecture--very poor perfomance...
Hello, I support a big application that was implemented using MVC architecture. The controller is a servlet. This application is creating big objects, stores them in session variables. Those session objects add up and the application becomes unacceptably slow as more users log in. Any suggestions on how I can improve performance?
- Posted by: Bodny Olivince
- Posted on: March 23 2004 14:32 EST
- MVC architecture--very poor perfomance... by stephen smithstone on March 23 2004 16:20 EST
- MVC architecture--very poor perfomance... by Mircea Crisan on March 25 2004 02:58 EST
- Java Performance Tuning - Try JView by Mario C on March 29 2004 18:03 EST
maybe add a cache system ( oscache and more can never quite remember the other one but tss use it something like coherence) to store the object then retreive them instead of writing to memory write to the local filesystem
But how do I approach this? Were you thinking of using database objects? Do you have any good links or examples you could point me to? A solution to this problem would basically save my life...
You can easily cache the data retrieved from the database using Coherence as well as decreasing the frequency of writes back to the DB. Take a look at the Coherence Forums (link below) there are a few examples of the CacheStore implementation there I believe.
Tangosol Coherence: Cluster your Work. Work your Cluster.
As I understood from your post the problem is that the client state mainitained in the session is too large. When the number of users increases propably there is a session serialization/deserialization to/from the disk that slows down the application. There are different things you can do to avoid this:
1. Write custom optimized serializations for your objects as they might improve a little the serialization speed. This has the drawback that whenever you change your obbjects you need to adjust the serialization.
2. Maybe some of the client state objects could be shared between users. Keeping such objects in the application scope greatly reduces the number of objects associated with each user. The drawback here is that this could be a big change that is and might involve changes in your application architecture. It might also create some bugs :-(. So I recomend a lot of care and testing when doing this.
3. If the client state involves large collections of beans, it could be a good idea to maintain this state in the database. If these objects are not needed on every client request, querying the databse once in a while is acceptable. You have to be carefull to delete the database client state when the session is closed or expires.
4. Maintain part of the client state in the client browser: hidden fields in forms, params in URLs, etc. This is very messy and error prone and I don't recommend this.
Best regards, Mircea
While architecture redesign of those objects would probably be the best bet, if you need short term results, try JView 2004 at http://www.devstream.com. It's an easy to use Java performance monitor and profiler.