Service Cloud Design - Distinguish the key components that contribute to performance optimization within a design

...

This topic describes several components of Salesforce that can lead to performance issues and the ways to optimize them. It explains the measures that can be taken to minimize the impact. Performance fine tuning helps in getting quicker search results and better usage of the resources within an multi-tenant instance of Salesforce.

Query Performance

One of the major contributors for the performance issues within the Salesforce environment is the Query that is either written or generated. If there is a huge volume of data on the object where our query is targeting to get the data from, it ends up taking a huge amount of time to return the results leading to over-consumption of resources. In some scenarios Salesforce terminates these queries resulting in business impact.

  • Reports & Dashboards:
    • A report can take anywhere from a few seconds to several minutes to run. Occasionally, a report is so complex that it exceeds the timeout limit and fails. If the report is slow to load, it’s usually because it is:
      • Querying too many objects
      • Dealing with intricate lookups
      • Has too many fields
    • Try these tips to get your reports to run more efficiently.
      • When filtering, use the equals or not equal to operators instead of contains or does not contain. For example, use Account Owner equals John James, not Account Owner contains John. Choose AND rather than OR for filter logic
      • To narrow your report’s date range, use time frame filters. For example, use Last 30 Days instead of Current FY.
      • Set time frame filters by choosing a Date Field and Range to view. Only records for that time frame are shown.
      • Reduce the number of fields in the report by removing unnecessary columns or fields.
      • If you receive an error message saying that your activity report has too many results, filter on a picklist, text, or date field. Alternatively, rerun the report using a different activity data type such as “Activities with Accounts” or “Activities with Opportunities”.
      • Add time filters, scope filters, and filter criteria to the report to further narrow the results.
      • Performance of reports can be improved when they are customized to show data related to a division using division drop down list.
      • If large data volumes are expected, consider aggregating data at a parent level instead of relying on the relationship and roll-up summary fields to optimize performance.
      • Use indexed fields as report filters.
  • List Views
    • List view once configured will generate a query when someone who has access to it executes it.
    • It may involve execution of queries on Sharing tables (based on the access settings on Profile, OWD etc) which may further hinder the performance.
    • Tips to improve performance
      • List view results are truncated at 2000 records so any list view if created to return more than 2000 records needs to be optimized.
      • Using fields that are indexed as the list view filter parameters improves performance
      • Reducing the number of fields that are returned will help in performance improvement.
      • Try avoiding the display of formula fields
      • AND and EQUALS operators will have better performance compared to OR and CONTAINS.
      • Try using relative date value filters.
  • SOQL queries within Apex Code
    • Any SOQL query if not properly written may lead to performance issues.
    • Verify if the query is selective using Query Plan tool in the developer console. Performance of a query can be improved by adding selective filters. The performance of a SOQL will depend on the presence of a selective filter. If a SOQL query contains at least 1 selective filter, the query is said to be selective. If the SOQL query doesn’t contain a selective filter, the query is said to be un-selective and will require a full table scan which leads to performance issues when there is a huge volume of data in the underlying table. Go through Make SOQL Queries Selective for more information. To determine if a filter is selective, please follow these steps:
      • Determine if it has an index.
      • If the filter is on a standard field, it’ll have an index if it is a primary key (Id, Name, OwnerId), a foreign key (CreatedById, LastModifiedById, lookup, master-detail relationship), and an audit field (CreatedDate, SystemModstamp).
      • Custom fields will have an index if they have been marked as Unique or External Id
      • If the filter doesn’t have an index, it won’t be considered for optimization.
      • If the filter has an index, determine how many records it would return:
      • For a standard index, the threshold is 30 percent of the first million targeted records and 15 percent of all records after that first million. In addition, the selectivity threshold for a standard index maxes out at 1 million total targeted records, which you could reach only if you had more than 5.6 million total records.
      • For a custom index, the selectivity threshold is 10 percent of the first million targeted records and 5 percent all records after that first million. In addition, the selectivity threshold for a custom index maxes out at 333,333 targeted records, which you could reach only if you had more than 5.6 million records.
      • If the filter exceeds the threshold,it won’t be considered for optimization.
      • If the filter doesn’t exceed the threshold, this filter IS selective, and the query optimizer will consider it for optimization.
    • Consider using Sort Optimization in case your requirement does not allow you to add a selective filter and your underlying table has millions of records
    • The most simple and effective solution to optimize performance is to use SystemModStamp instead of LastModifiedDate to filter data. Refer SOQL Performance Tips: LastModifiedDate vs SystemModStamp
  • SOSL queries
    • If your SOSL search is too general, it will be slow and return too many results. Use the following clauses to define efficient text searches.
      • IN: Limits the types of fields to search, including email, name, or phone.
      • LIMIT: Defines the maximum number of rows to return.
      • OFFSET: Displays the search results on multiple pages.
      • RETURNING: It will search from that object and that fields which mentioned and return the result.
  • Other Considerations for Optimization
    • Skinny Table
      • Skinny tables can be used to improve the performance of read-only operations for reports, list views and queries when the underlying table contains millions of records.
      • You need to contact salesforce for creating or updating skinny tables
      • Skinny tables are kept in sync with their source tables when the source tables are modified.
      • It combines the fields from the table that contains standard fields and the table that has custom fields and helps in performance by avoiding joins.
      • Skinny tables can be created on custom objects, and on Account, Contact, Opportunity, Lead, and Case objects.
      • Skinny tables can contain the following field types: Checkbox, Date, Date and Time, Email, Number, Percent, Phone, Picklist (multi-select), Text, Text area, Text area (long) and URL
      • Skinny tables can contain a maximum of 100 columns.
      • Skinny tables can’t contain fields from other objects.
      • For Full sandboxes: Skinny tables are copied to your Full sandbox orgs. For other types of sandboxes: Skinny tables aren’t copied to your sandbox organizations. To have production skinny tables activated for sandbox types other than Full sandboxes, contact Salesforce Customer Support.
      • Skinny tables do not include soft-deleted rows (i.e., records in the Recycle Bin with isDeleted = true)
      • Any changes to the field at object level is not cascaded to the skinny table (on that object, if modified field is being used in skinny) as it is a separate table maintained internally within salesforce.
    • Indexes

      • Indexes will help in performance improvement of queries, reports and list views

      • With the help of Salesforce Support, custom indexes can be created on both Standard and custom fields.

      • The following fields are indexed by default:

        • Primary keys (Id, Name and Owner fields).
        • Foreign keys (lookup or master-detail relationship fields).
        • Audit dates (such as SystemModStamp).
        • Custom fields marked as External ID or Unique.

      • Custom indexes are not supported on multi-select picklists, text area (long), text area (rich), encrypted text fields and non-deterministic formula fields.

Data Performance

  • Data Tiering: Storing of records across multiple objects and retrieving them when there is a requirement.
  • Reducing Data: It is always a good strategy to
    • Archive data on a regular basis
    • Keep the recycle bin empty
    • Use selective queries to avoid table scans and get only relevant data for processing.
    • Use Bulk API to hard delete large number of records.
  • External Data Storage
    • External Objects
      • External objects are similar to custom objects, but external object record data is stored outside your Salesforce organization.
      • External objects are available with Salesforce Connect and Files Connect. Each external object is associated with an external data source definition in your Salesforce organization.
      • Salesforce Connect uses external data sources to access data that’s stored outside your Salesforce organization.
      • Salesforce Connect uses a protocol-specific adapter to connect to an external system and access its data that includes cross-org, OData 2.0, OData 4.0, Custom Adapter created via apex.
      • Files Connect uses external data sources to access third-party content systems.
      • Several Files Connect adapters like Google Drive, Box, Sharepoint Online, OneDrive for Business are available:
      • External data sources have associated external objects, which your users and the Lightning Platform use to interact with the external data and content.
      • By accessing record data on demand, external objects always reflect the current state of the external data. You don’t have to manage a copy of that data in Salesforce, so you’re not wasting storage and resources keeping data in sync.
    • Data can be stored in third party systems and retrieved using REST or SOAP API
    • Partner applications can be used by buying them in AppExchange. Some examples include xFilesPro etc.
    • Heroku Connect / Heroku External objects can be used to Syncs up data from Heroku Postgres database to Salesforce Objects. We can also expose Heroku data as Salesforce external objects. A typical use case is to Access data from a Heroku app (such as Event Management, public-facing mobile app etc.) and display/sync it with Salesforce.
    • Web Services/Mash-Up: Custom visualforce / apex code or lightning component to access data via web services, or UI mashups via Canvasand iFrame etc. A typical use case is to enable access to other systems such as degree planning, online coursework, registration/SIS from a portal style UI
    • Einstein Analytics (Wave): Embed structured and unstructured (chats/tweets) data insight, analytics and exploration capability for large datasets. A typical use case is to access to Salesforce and non-Salesforce data that runs into Millions of records such as system generated (IoT, Sensor data, Web Analytics)
  • Archiving
    • Relevant data is the key to successful CRM. The rest is history. Determine relevance by identifying how data is driving insights and behavior. The end result of this is that it reduces data volume and improves performance and may reduce cost.
    • Adopt a policy of archiving un-relevant data regularly when there are millions of records.
    • After identifying the un-relevant data, Salesforce batch/scheduled apex can be used.
    • Multiple Data archiving tools can be used as specified here
  • Sharing
    • In the case of a private sharing model, Salesforce creates sharing tables and the data security is managed using these tables. In instances when there is a skew lots of implicit calculations happen to result in performance issues.
    • Data when shared using the manual sharing or Sharing rules will be stored within the sharing tables. When there is a change in a sharing rule, it may lead to implicit calculations which may lead to performance. It is highly encouraged to be done during off peak hours.
    • The sharing calculations can be deferred during large data loads to avoid the issues during load.
    • Nesting of roles, groups and territories may further impact the performance so it is suggested to limit the nesting.
    • Not all objects need to have a private sharing model, so have a detailed analysis of requirements to get to a conclusion of whether private sharing model is required.
    • Make sure that a user is not owning more than 10000 records.

Visualforce Performance

  • View State
    • Salesforce allows Visualforce pages to have a maximum view state size of 135KB. The View State tab shows you which elements on your page are taking up that space. A smaller view state size generally means quicker load times. In order to avoid this error, minimize your pages’ view state.
    • Tips for reducing View State
      • If your view state is affected by a large component tree, try reducing the number of components your page depends on.
      • Avoid SOQL queries in your Apex controller getter methods.
      • use the private setter for elements where you are not updating value from the visualforce page.
      • Decrease collection items if they are not going to be used in the page.
      • define private if they are not used on the visualforce page.
      • If you notice that a large percentage of your view state comes from objects used in controllers or controller extensions, consider refining your SOQL calls to return only data that’s relevant to the Visualforce page.
      • The transient variables are not passed to view state and therefore not stored in View State.
  • HTTP Callouts within a page
    • Performing HTTP callouts Synchronously from within a visualforce pages may sometimes lead to performance issues if the service provider is taking a huge amount of time to respond. Sometimes this may also contribute to concurrent apex errors. Try using a continuation framework to get out of such situations.
  • Governor Limits needs to be kept in mind
    • Apex CPU time Limit Exeeded
      • Salesforce has a timeout limit for transactions based on CPU usage. If transactions consume too much CPU time, Salesforce will shut them down as a long-running transaction.
      • The Maximum CPU time on the salesforce servers - 10,000 milliseconds (Synchronous limit) 60,000 milliseconds(Asynchronous limit)
      • Check here to see what is included and not included as part of this limitation and best practices to follow
    • Too Many SOQL queries
      • Within a single call or context Salesforce allows 100 SOQL queries and when this is exceeded, we get Too Many SOQL Queries 101 error.
      • Avoid queries within loops, follow coding best practices and follow best practices for bulk requests.
      • This article provides details and best practices to get out of this situation
    • Too Many DML operations 10001

Lightning Performance

  • If you or your Users are experiencing slow page-loading times when using Lightning Experience, it may be related to one or more of the following issue types.

    • Geographical Issues
    • Device and Browser Related issues
    • Salesforce Org Configuration issues

  • Follow the steps outlined in this article to improve performance

References

...