Performance Tuning Tools for Salesforce are Comparatively Limited


The tools available to performance tune Salesforce are more limited because the platform operates a Software-as-a-Service multi-tenant architecture.

Consider these typical responses to address poor performance of a traditionally hosted web site where you own or have control over the servers and hosting infrastructure:

  1. Deploy more web servers to distribute the front end load with load balancing

  2. Federate or partition the backend database to distribute the data query load

  3. Increase the number of CPUs or cores in the servers

  4. Increase the amount of RAM in the servers

  5. Add more hard drives, or faster hard drives, or faster IO adapters

  6. Increase the internet connectivity bandwidth

With Salesforce you have none of those options.   None

Toolbox 178177044_d9697d3810_o 700x400

So to avoid your Salesforce instance performing poorly a different approach has to be taken.

I see an all-to-common pattern where complexity is added to Salesforce with gay abandon for the first year or two followed by external expertise being needed to address serious performance issues.

Here are my suggestions to avoid ending up in a performance pitfall with all too few tools in the chest to work with:

  1. Architect with performance in mind from beginning recognising Salesforce is a hosted platform with deliberately applied governor limits to throttle performance;

  2. Follow a Test-Driven-Design methodology where test classes are designed to ensure performance at realistic production loads (not just to achieve 75% of code coverage!);

  3. Develop and peer review custom code with performance optimisation in mind to make sure there are no obvious performance flaws like SOQL queries in loops or inefficient use of collections;

  4. Add no more than a single trigger per object entity;

  5. Use custom External ID fields where appropriate as these are automatically indexed;

  6. Request Salesforce to add 1-column or 2-column custom indexes;

  7. Minimise the amount of data stored in view state when writing custom Visualforce pages (especially mobile pages);

  8. Avoid data skew where one user owns too many records or one parent record has too many children;

  9. Operate the most open data security model permissible as sharing rules add complexity and load;

  10. Integrate using the Bulk API where possible;

In summary, performance in Salesforce implementations which involve large volumes of data and significant customisation is a challenge, there are less tools to utilise, so performance must be considered early in design and continuously during development.

Other good resources include:

Comments are closed.