When we’ve moved optimized_sum_accounst function into production, I’ve expected the advantages to be visible more or less immediately. I knew how many times the original sum_accounts function was executed, and was hoping to see a drop in the number of executions at least two times. Which didn’t happen.
When I started to examine the application log and the statistical tables, I’ve realized, that the optimized function didn’t do much good, because it was still called way too many times. And I’ve also realized, that it would be impossible to make more changes in the right direction “invisibly”, because this is just the way existing methods are structured.
From my analysis of the unfortunate execution of sum_accounts (as well as optimized_sum_accounts) I knew that the biggest consumer for them both is Installments Controller and the corresponding controllers in other applications. Which was no surprise – I run execution statistics for our new portal (the project we are working on) daily, and I knew for a longest time, that Installments Controller has the most average db calls per invocation, and should have being reworked. unfortunately, we’ve being postponing it for quite a while, since we had to deliver new features.
I am telling this long story for the sole purpose of making it clear, why I was so excited today, when we finally deployed a new API, which utilizes my function. I knew it would be one of the biggest improvements I’ve made so far, and it was!
The average number of db calls for Installments Controller fall from 130 to 3! And the database execution time decreased from average 0.7 sec to 0.018 sec! Moreover, the difference between the “best” and the “worst” db execution used to be about 400 times, and now it’s about 20 times (which is still a lot, and I need to figure out, why, but much better!)
And guess what? In contrast to oec balances, this method is pretty much isolated, meaning, that this is more or less the only method which should be called from any installment controller, it just populates the whole screen. Which means, it should be easy to replace the current model methods in all applications with our new one!
I am going to work on this 🙂