A while back I wrote about how I believed Salesforce application performance was an area that needed further investigation to help provide a set of best practices and guidelines to help people write better and more performant applications. One of the things I wanted to do following that post was to share a method that I have used to help me when I am checking the performance of an application, trying to improve it or fixing an exceeded governor limit - OODA. After hitting a performance issue yesterday it was very top of mind so I finally put virtual ink to paper.
To start - “Premature optimisation is the root of all evil”
I want to begin this by stating I try to improve performance of my applications wherever possible but do not attempt to prematurely optimise. I agree with those like who state that on the platform a certain amount of optimisation is needed inherently, for example bulkification of triggers and grouping of SOQL queries. What I try to avoid though is being overly obscure in my coding to provide a performance improvement when first writing the code. Readable and easy to understand code is unbelievably important and if you have the choice between doing something smart to remove a single query or having your code much easier to read, make your code easier to read. Again this is all an art because there is a lot of grey and very little black and white here, but hopefully you get the drift.
So what to do when you need to improve performance
Typically this happens when you discover a larger than expected data volume (adding a new country or business group to an org for example), something in the config side of things is having an impact (flow or process builder bulkification for example) or or you are just feeling the application is slower than you would like. Its at this point I break out the OODA method which I became aware of formally whilst learning about Metrics-Driven Development last year but had been using in practice without a name for a while. I was glad I found a name however because it looked a lot better on a slide.
My slide from London’s Calling
OODA is a miltary framework for making decisions (to massively undersell it) and stands for Observe, Orient, Decide and Act. I think it is a great way of working when trying to improve performance and especially when dealing with those lovely “too many queries” errors and governor limit exceptions. I like to use the framework to solve such a problem in the following way.
Observe
Take measurements, as many relevant ones as possible. When dealing with something like a blown governor limit you can use the System.Limits methods to take snapshot measurements and debug them (or save if you so wish to a record). You should take as many measurements as is sensible and as helps you identify the issue area. It is important as well that measurements are consistent, repeatable and under the same conditions - comparing apples and oranges will not help us later.
Orient
Now we have our measurements we need to think about what they mean in context. For example, why are we repeatedly running that query? Could this piece of code be avoided through an earlier check? Which area is having the biggest impact and why? Can we reduce the payload? Measurements only tell half the story, here we add the correct context from the business use case and well as looking at the lifecycle of the transaction. We have all come across strange use cases where it becomes clearer why a weird design decision was made.
Decide
Big questions:
- Do we fix/improve this? NO is a valid option here and you should be careful to spend time improving things for minor gains.
- Do we attempt an update or a rewrite?
- Can part of this be made asynchronous?
- Are we sure this is the right decision? Is there an alternative way or workaround?
If you are fixing a bug then you may not be able to make some of these decisions - they may already be made.
Act
Almost the easiest part - make the updates and remeaure and retest. Don’t just retest that you are not getting the error or that things are faster, retest that it still does what you expected.
Summary
In short OODA is a great way for helping make decisions when performance testing/profiling as well as bug fixing for governor limit exceptions. It helps me out whenever something like this crops up (such as yesterday for me) and provides a solid framework which can help you and your team go through nd make the right decisions.