The Dark Art of CPU Benchmarking

Benchmarking in Salesforce is an important skill to learn, especially since Salesforce introduced the CPU timeout of ten seconds in the Winter ’14 release. If your code is inefficient, you may start to see exceptions thrown if processing the logic takes longer than the allotted ten seconds (sixty seconds when running asynchronously). Furthermore, other packages running in your Salesforce instance directly impacts all code and declarative functionality – unlike most Salesforce limits, the CPU timeout limit is not unique per namespace. (Also – benchmarking can be fun!)

I was a co-presenter on the topic of CPU benchmarking with Dan Appleman at this year’s Dreamforce conference. Missed the presentation? It was recorded! Check it out below:

The sample code used in the presentation can be found on GitHub at https://github.com/jsbulldog89/df16-benchmarking. For more information on CPU benchmarking, I encourage you to reference Chapter 3 in Advanced Apex, or search for CPU benchmarking on SearchTheForce.

— Robert

Salesforce TrailheaDX Campfire Story

In June, I had the opportunity to attend Salesforce’s TrailheaDX conference. In one of the sessions, I gave a quick 5 minute “campfire” story. Here it is, in written form!

Attending Dreamforce this year? Join me on Tuesday, October 4th as a I teach you about the Dark Art of CPU Benchmarking with Dan Appleman. Look out for a recap post here shortly thereafter!

TrailheaDX Campfire Story

Not so very long ago, I worked on a managed package that had thousands of unit tests. Thousands! To care about ensuring that *all* code is functioning properly in such a large product is pretty cool, right?

Well, there was a problem. A few, actually.

If you wanted to run these unit tests in one of the development orgs, go get a cup of coffee. Actually, you might as well go get an entire pot because they were taking over an hour to run! How could they be taking so long?

The team set out on a discovery and realized that updating the Apex Test Execution options and unchecking the “Disable Parallel Apex Testing” setting brought the time down from over an hour to 15-20 minutes. We found a solution – what a relief!

However, our journey was not yet done. Imagine you’re out walking in the sweltering hot forest – your water is almost gone, there are several blisters on your feet – and you spot your final destination out in the distance. So you keep walking, getting ecstatic that this will be all over soon… but you’ve been fooled. While your final destination may appear to be close, you soon realize there are several more hills to climb and fallen trees and rocks to maneuver around.

When running the tests asynchronously, many tests would fail due to row locking issues. It was never the same ones, and simply ignoring the failures was not an option because it wasn’t sufficient to say “oh, well they just failed because of row locking, but we know the actual unit test does really work.” So now we had to figure out which ones failed and select those to re-run again. And sometimes some of those would fail, and we’d have to re-run the ones that failed a second time.

One day, a developer stumbled upon the Salesforce Winter ‘16 release notes and made an interesting discovery. If you run unit tests through the Developer Console instead of from the Apex Test Execution page, there’s an option to re-run the failed unit tests! This means that you don’t need to manually re-run the classes that failed. Even better, you can select to run only specific test methods within a given test class instead of running the entire class.

This was great news. Developers everywhere rejoiced. While running so many tests asynchronously still causes row locking issues, we had better tools to enable us to confirm they all worked as expected.

So, what can we learn from this? First and foremost, read the Salesforce Release Notes – you never know what gems you may find. But don’t worry about remembering everything (because you won’t). You can always go back and re-read them later when it is more relevant for you – Salesforce doesn’t remove previous release notes. And even better, you can navigate the Salesforce Developer Documentation by release version as well!

Switchin’ It Up

It’s time for some changes.

Wait – don’t worry! Not all changes are bad. In fact, I like to think this is a good change.

Buying my first house and getting engaged wasn’t enough adventure for one year. This past May, I accepted a senior software developer role at Full Circle Insights and decided to leave my position at NimbleUser, where I’d been working for the past four years. Among many other reasons, I am quite excited to be working in the same time zone as all of my coworkers once again. I’m happy for the new opportunity and thrilled that I get to continue contributing as a Salesforce developer.

So, how does change relate to this blog? Well, it’s time for a rebranding. Along with my new position, I am also itching to become more involved in the Salesforce community. One of the easiest ways to connect is to share my expertise, and I think this blog is a good place to start.

Over the next few weeks, I’ll be transitioning the web site to highlight only Salesforce and technology-related blog posts on the home page. There will be a separate page that will be a hodgepodge of all posts, personal and professional. Instead of posting every three or four months, I’m hoping this change will also motivate me to start blogging on a more regular and consistent schedule.

Let’s begin the new journey!

— Robert