I'm working on a web based application that belongs to an automobil manufacturer, developed in Spring-Hibernate with MS SQL Server 2005 database.
Through this application, end users can request for creating a Car, Bus, Truck etc through web based interfaces. When a user logs in, a HTML form gets displayed for capturing technical specification of vehicle, for ex, if someone wanted to request for Car, he can speify the Engine Make/Model, Tire, Chassis details etc. There are overall 100 form elements on Create Vehicle Request screen, out of which 30% are drop downs (SELECT boxes) for displaying options (i.e. users are allowed to choose one of them) . These SELECT boxes gets populated from values stored in database (Master data). This master data changes at least once a week by running a stored procedure in back-end.
There are approximately 10,000 users for this application globally and at the most we are expecting 5000 hits everyday for new vehicle request, i.e. 5000 times Create vehicle form will be displayed.
My question is, Do i need to go with Second level cache option for storing the values for form field getting displayed from master data?
Since these values are getting displayed from a set of Master tables that will change once a week only, I'm thinking caching of master data will help improving performance, but I'm not too sure as I've yet to move my application to Production to see the real performance and to see, if i really need caching.
If I go with caching, I might need to spent a week or two figuring out how to configure that and I don't wanted to spend a week or two without seeing any real benefit?
Need experts help on this. Also if someone can share practical scenarios, where caching is really needed would be of great help.
My question is, Do i need to go with Second level cache option for storing the values for form field getting displayed from master data?
You don't need to, but you could. And and read-only data (or mostly read) such as immutable reference data (countries, states, tax codes or, in your case, Engine, Tire, Chassis, etc) are perfect candidates for second level caching (and query caching if required).
Since these values are getting displayed from a set of Master tables that will change once a week only, I'm thinking caching of master data will help improving performance,
Well, depending on how much hardware, the size of your cluster, etc, your app might just be able to handle the load. But as I wrote, it's very common to cache read-only data:
Just keep in mind that caching things means that their object representation won't be garbage collected so it might increase the memory needs a bit.
but I'm not too sure as I've yet to move my application to Production to see the real performance and to see, if i really need caching.
Honestly, you should not wait until production to see if there is a performance problem. You should load or stress test your application before in a dedicated environment and tune your application, the JVM, the app server, the database, etc. And don't forget, you can't improve what you can't measure.
If I go with caching, I might need to spent a week or two figuring out how to configure that and I don't wanted to spend a week or two without seeing any real benefit?
It is not that complicated. You need to activate second level caching and query caching in the Hibernate configuration and to choose a caching provider. My recommendation would be to use EhCache and the relevant properties are:
hibernate.cache.use_second_level_cache=true
hibernate.cache.use_query_cache=true
hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider
Then, mark the relevant entities as cacheable (and cache the queries used to retrieve the data if you don't load them by id).
And if you decide to use the second level cache, you'll have to evict the cache manually since you're not updating the data through Hibernate API but using a stored procedure (with the evict methods on the SessionFactory). This will require some lines of code. If this is possible, restarting your app would be another option.