Welcome to another Five Things podcast. Today’s topic is Performance, which is something Robert and I deal with a lot. In fact, I’d say it’s the number one reason we engage with customers.

We usually see performance falling into a few different categories – overall application speed, analytics speed, user adoption. So it can mean different things in different situations. But today we’re focusing on the most common performance definition – application speed. That’s how fast search results come back, how fast lists display, the time for a page to load.

Here are five things you need to know about achieving top performance.

1. It’s the data volume, stupid.
So you’ve just launched – which usually means you just loaded all your production data and flipped the switch. Users are logging in. And then you start to hear about performance issues. Searching is slow, lists are taking forever. All this stuff worked fine in development – what happened??

Believe it or not, those millions of records that you loaded right before go-live could be the culprit. When you are implementing CRM, it usually doesn’t make sense to load ALL of your production data. But it’s simply physics at work – scanning a larger pool of data will take longer to return results.

So the first piece of advice – anticipate this, plan for it, and test in advance as necessary. There’s no exact point at which performance slows down – generally when you are expecting to load high hundreds of thousands or millions of records you should budget time for performance tuning.

But having millions of records in the system isn’t itself going to be slowing you down. It’s how you use the data, how you get to it. Running a list that returns hundreds of thousands of records? How is that useful? It isn’t! Same with reports – running a report that gets you a list of a million records isn’t very useful. How about using summary reports with links to more detail? Check out the documented best practices for more tips in these areas.

And of course, if all that data isn’t really needed in CRM On Demand, then leave it out! We’ve had many customers that felt about their data the way my wife does about old clothes – you never know when it may come back in style, so hold on to it. Not a great strategy with old clothes and not a great strategy with your CRM data.

2. Principle of Least Privilege (or learning to live with less)
This is a pretty well established concept in IT – only give folks what they need to do their job. It’s also a good guideline for getting the best performance from CRM On Demand.

Whenever you run a search or a list, you are sifting through the pool of data that you have access to. So even though there may be millions of records in the system, you only have access to ten thousand of them. This is why we often see companies reporting very different performance results from different users. It’s important for admins to keep this in mind – the performance you see may be very different from the average user because you can see everything. Make sure to see it from a normal user perspective!

So the rule here is to use data access controls (books is one of our favorites) to create nice little pools of data. When they fish for a particular record, the system has a lot less data to scan through. The pools should just contain what a user needs. Any more than that and you may negatively impact their experience – and we know that leads to lower adoption.

3. Some fields are faster than others
\Alas, tis true that not all fields were created equal. Searching millions of records using any old custom field is sure to cause some pain. Searching lots of records using a super-charged Indexed field is a walk in the park.

Super charged? Well, maybe. At minimum, you can certainly expect that any of the custom fields with default labels containing “Indexed” are going to perform a whole lot better than their less endowed counterparts. In database lingo, an index is a data structure that improves the speed of data retrieval operations. These fields, or really database columns, have been arranged and ordered in way that maximizes performance.

Unlike custom built or other on premise applications, you can’t just decide which columns to index. This being Software as a Service, Oracle has provided these fields for you in advance and its up to you to put them to best use. Also, recognize that you won’t get any more indexed fields – at least not until Oracle adds them to the service as a whole. And this isn’t a trivial thing – indexes have a cost to memory and write speeds, and the more indexes you have, the less benefit each additional one provides.

So the net is, frequently searched fields or fields used in lists and reports should be indexed fields.

4. Keep those pages trim
We’ve talked mostly about things that affect searching, lists, and reporting. What about tabs and detail pages? Sometimes they can be mighty pernicious.

Pernicious? Well, I’m not sure about that, but there are certainly ways you can slow down a tab. CRM On Demand allows you to customize each tab – so you can load up the Account home page with lots of embedded reports and external content. Each of those is essentially another process, another download – another potential drag on performance. If a tab is loading slowly, first thing to do is start removing items. It’s likely that one or more is the culprit.

Similarly, your detail page may have a fancy embedded applet that looks great but drags down overall performance. So if you’ve got a dozen or more applets and most of them are calling external web pages (or even internal analytics), you’re likely to start seeing page load times increase.

Net is – keep those home pages and detail pages nice and trim. Your users will thank you for it.

5. All that other stuff
Believe it or not, sometimes the interweb just doesn’t work as advertised! And CRM On Demand, being a web based application, relies on the underlying health of your internet connection.

Think about all the connection points. Your corporate network, firewalls, service providers, backbones, etc. all the way to the Oracle data center in Austin, Tx. Somewhere along the way, things can go wrong. One way to identify this kind of problem is to try re-creating the performance issue from various locations – in the HQ, a field office, a home office. If the experience is very inconsistent, then there’s a good chance its a network issue.

I worked with one customer for weeks helping to troubleshoot performance problems. It seemed to be worst with a group in one of their field offices. Eventually we were able to run diagnostics across the network and found a problem at their service provider. They were able to fix it and performance improved immediately.

Yes, and don’t forget the browser itself. Check your browser settings against those recommended on My Oracle Support. This can make a big difference.

Episode Wrap-up
So those are your Five Things about Performance: It’s the Data Volume, Live with Less, Some Fields are Faster than Others, Keep those pages Trim, and All that other Stuff.

Keep those in mind and you’re on your way to a high performance, high adoption application.

Share and Enjoy:
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati
  1. Mike Lairson on 05 Apr 10 10:16 pm

    Great episode! Want to share one I run into quite a bit. I often build reports for my customers with some rolling date filters… Activities created in the last week, SRs less than a month old, etc. The reports look good and run great until the day after their data load. Turns out, when you import all of those legacy records, the Created Date is the date of the import. So guess how many activities were created in the last week? All of them! The good news is, this issue will resolve itself as the records age out of the date range for the reports. Let me know when you want to do a 5 things episode on report performance.

  2. [...] This post was mentioned on Twitter by Good CRM. Good CRM said: The Oracle CRM On Demand Podcast » Podcast 010: Five Things About …: And of course, if all that data isn't reall… http://bit.ly/dAOkxK [...]

  3. Mani on 27 Apr 10 11:41 am

    Great info!

    Case Insensitivity Check box in searches.
    This can seriously affects the search performance.
    Searching Location field with Case Insensitivity checked returns results in 139+ seconds. Same search returned the results in < 15 seconds.

    Searching on a non-indexed field resulted time outs. Remapped the search field to an Indexed Short Text field and the results returned in < 10 seconds.

    Web Applets with Charts and Pivots also resulted in performance issues. Users now have the option to minimize the RI applets and expand it only when it is needed.

    I would like to know Mike Lairson's view on Report performance issues.