Refactor the user of BigDecimal to improve memory utulization
GENERAL
TESTING
GENERAL
TESTING
Description
From David Haines @ UMICH:
We've upgraded to a new infrastructure and the load test we are using doesn't find that the database [at] issue. Performance now collapses because of garbage collection. The app servers quickly end up doing nothing but gc. [I] found that there are many, many BigDecimal and String objects created and then thrown away. Many of the BigDecimal object appear to have the same value. Many of the String objects are used as arguments to the BigDecimal constructor and may not be necessary.
It appears that the caching that we added is ineffective in our situation because the cache key includes the student identification and our problem shows when many different students are getting their grades at the same time.
My current plan is to create a BigDecimal factory to delegate creation and management of the BigDecimal objects to a single implementation that can then be optimized. That implementation would take care of caching common BigDecimal objects so that there can be a singleton BigDecimal object for a particular value and so that the best way to pass arguments to the BigDecimal constructor can be identified and used everywhere.
I also suspect that scaling adjustments required to use percentages could be factored out to a later stage so BigDecimal objects can be used less frequently.
From David Haines @ UMICH:
We've upgraded to a new infrastructure and the load test we are using doesn't find that the database [at] issue. Performance now collapses because of garbage collection. The app servers quickly end up doing nothing but gc. [I] found that there are many, many BigDecimal and String objects created and then thrown away. Many of the BigDecimal object appear to have the same value. Many of the String objects are used as arguments to the BigDecimal constructor and may not be necessary.
It appears that the caching that we added is ineffective in our situation because the cache key includes the student identification and our problem shows when many different students are getting their grades at the same time.
My current plan is to create a BigDecimal factory to delegate creation and management of the BigDecimal objects to a single implementation that can then be optimized. That implementation would take care of caching common BigDecimal objects so that there can be a singleton BigDecimal object for a particular value and so that the best way to pass arguments to the BigDecimal constructor can be identified and used everywhere.
I also suspect that scaling adjustments required to use percentages could be factored out to a later stage so BigDecimal objects can be used less frequently.