Introduction

Cloud-based Application Testing

A Salesforce implementation is different from other CRM online applications. It is a cloud-based application. You are dealing with an application whose data and executables reside on a vendor platform. In other words, performance monitoring and analysis for you as a client is primarily about client machine rendering and network speed.

But there are times when you need to increase the growth of your system. That can mean increased user traffic, growing data volumes, or increase in transactions per second to support your growing customer base. This article addresses the Salesforce challenge using LoadRunner TruClient to conduct performance tests.

Since Salesforce is a cloud-based application managed by its vendor, much of the performance issues are charged to the vendor. The reason is that all Salesforce customers share its services like tenants in an apartment building. The database services, application and security services are shared. This means the customers should only be directly concerned with the application customization performance. But even that is in the shared environment which impacts other Salesforce customers.

Salesforce Application Testing

When you make changes or customize your implementation of Salesforce as a customer, consider the following information at the Salesforce Help site. You should read the following:

Strategic Summary

Your business use of Salesforce enables you to access and manipulate data on somebody else’s computer site. Your data is securely stored and processed on the Salesforce vendor site. You interact with the data via a browser window through a specific and unique URL. The vendor ensures you that the core system and its functions operate within normal parameters. They also monitor the system to make performance adjustments when required.

If you encounter performance issues, they are available to respond. However, you may desire to conduct performance tests to examine issues of your own, but you must gain approval from the vendor and conduct tests within their guidelines.

Normally my approach to performance testing of an application is to look for bottlenecks. So, I test with five areas of bottlenecks in mind. The five areas of bottlenecks are Client machine issues, network issues, web service issues, application service issues, and database issues. With Salesforce, the first two areas of potential bottlenecks are important to a Salesforce customer. What remains is handled by the Salesforce vendor. Therefore, you as the customer should be focused on page load time and network latency. You could have client machine issues or network-related issues. If you have a good network engineer staff, then what remains is the client machines in use in your organization.

Customer performance testing of Salesforce applications should primarily be focused on the time a page is received on a client machine and rendered in a browser. Customer users may periodically complain that their computers are responding slower than usual for a Salesforce business create, update, delete, or query function. Some research is necessary at the customer site to determine if the bottleneck is a computer-related issue or network-related issue. Otherwise, the issue should be forwarded to the Salesforce vendor for resolution.

Once a Salesforce customer determines a need to measure performance, performance monitoring should be the first level of action. Determine in the Salesforce production system if network latency or client machine processing is on the increase. If you cannot pinpoint where the performance degradation is, then the Salesforce vendor must still be involved. They can approve of you conducting performance tests in the Salesforce sandbox environment, or they can disapprove. Customer performance testing must be done in a way that it does not impact other Salesforce customer traffic on the vendor servers in the Salesforce cloud.

The strategy for creating the necessary traffic is simple. Start with baseline testing where the number of virtual users is 1 to 50. Let the results be your data to compare to with previous results and new results of higher concurrent user tests. Whether the testing type is load, stress, or longevity keep the comparison to the same type of test.

The strategy for measuring and analyzing Salesforce performance at a customer site is two-fold. Performance Monitoring should be implemented during the development unit test and postproduction stages. Through repetition a proactive strategy is in place to detect if performance is degrading or improving. Performance testing is a strategy that can be implemented in preproduction as part of regression testing to ensure no unexpected performance degradation is promoted to production. The focus should primarily be on object or process Salesforce customization.

Please note that there is a phase in Agile called Spring Hardening. This phase should not only require full business functional testing but would require a full load test targeting all business functions. A business function that did not require changes during the current sprint must not be excluded. Performance regression is possible just like functional regression.

Performance Monitoring & Testing Using Automation Tools

There are many application performance monitoring tools on the market that are useful. But favorites are New Relic, SiteScope, Prometheus, AppDynamics, and Dynatrace. And there are several performance test automation tools available, such as, LoadRunner, JMeter, and IBM Rational. However, I am going to focus a significant part of this article on using the LoadRunner TruClient tool for testing and monitoring.

It is important to know what to measure. In other words, what KPIs or Key Performance Indicators should be identified and monitored during monitoring and testing Salesforce applications?

Performance testing and monitoring is about measuring. The Salesforce Applications are built upon web technologies and are accessible via internet browsers. You might be tempted to use metrics or KPIs that are common to web application testing, such as page response time and time to first byte. That may help you, but you should use metrics that consider the Salesforce architecture.

When you measure user experience in Salesforce, the measurement or KPI should be something called Experienced Page Time (EPT).

EPT is designed to consider Salesforce Lightning pages. Lightning pages can communicate with the Salesforce backend. Network chattiness can create a disconnect between a page before it is fully rendered. EPT measures when the page is rendered.

More details about how to view EPT in the browser with the Lightning Usage App and Event Monitoring, see the Measure Performance for Your Salesforce Org document.

There are also Server-side metrics to consider even though they are normally monitored by Salesforce vendor staff.

We can look at EPT easily because it is measured from the client’s perspective. The Salesforce vendor hosts a vigorous infrastructure. You can gain insight into how Salesforce is performing on the server side during a test run with what is called Shield Event Monitoring.

There are many metrics/KPIs that are enabled with Shield Event Monitoring. Go to this link on Event Monitoring to get more detail. Some examples follow:

RUN_TIME: What was the total amount of time for the transaction?
CPU_TIME: How much time is spent in the application tier?
DB_CPU_TIME: How much time is spent in the database tier?
DB_TOTAL_TIME: How much time does it take to make a database call?

Event Monitoring is a tool that Salesforce provides to help keep your data secure. You can see the granular details that your users perform. These user activities are events. You can view information about individual events or track event trends identify abnormal behavior and protect your company’s data.

Here are some events available for tracking which include:

Login and log out
URI (web clicks)
Visualforce page loads
API calls
Apex executions
Report exports

Network Virtualization

Network Virtualization in LoadRunner (NV) helps you to understand how can slow networks affect your application’s performance. It also shows you what you can do to optimize your application to improve client and server performance for a better customer experience. This product is built inside of the TruClient editor window. Granted before we go any further, understand this. Some of the results you will find from network virtualization reporting is still a matter of what the Salesforce vendor has scheduled or wants to prioritize in their list of product improvements. In other words, NV will point out web components that are sent from Salesforce. These components may affect traffic throughput on the download side for client-side processing. You can determine if there are impacts, but you are powerless to make changes.

LoadRunner TruClient Script Development for Salesforce

One of the first concepts I teach when creating scripts is to be familiar with the target application. Normal web applications include authentication processing from a home page, menu processing, data manipulation, querying, and log out. Salesforce is similar but more object oriented. Return of data can be more than what appears on a screen which can mean more data transmission but less round trips to get data for rendering on a screen.

Back to application familiarity. Building Salesforce scripts should be divided into application connectivity, authentication processing, home page rendering, business process selection, object selection, and then object manipulation processing. Scripts should be designed to handle one or more selection and manipulation processes.

When you engage your Salesforce application edition, you are expected to supply an assigned URL, user account, password and maybe a token. The credentials supplied are based on the method used to launch Salesforce. For instance, if you are launching Salesforce from a browser, it may require only the URL, user account and password. But if you are using a testing tool to launch Salesforce for API testing, then it will require a token to pass OAuth authentication.

Authentication is an important part of the script development process. I like to couple authentication or Salesforce launching with the log out process. This creates a script that ensures you have the right code for launching and shutdown of Salesforce. Every new script has a starting point in development. From there the business and manipulation processes become the unique part of development.

Recording

My actual script development will include the following assuming the TruClient tool is already installed and configured.

Generate the script using the TruClient record method
Record the script for Salesforce connection, login, and log out
Execute the recorded script as-is
Check the results
Review the NV results

Normally scripts can be developed using a known sequence of HTTP requests that emulate the URL sequence necessary to connect, login, select an object, edit an object record, and then log out. But it also has a recording method that can be used to capture Salesforce resources behind the scenes. This may be easier than writing your own HTTP requests. I am not going to get into details about this approach here.

To see a live demonstration of the record and replay of a TruClient script that tests Salesforce connect, login, and log out go here. This video is intended to provide the demonstration of the script discussed in this article.

Recording Setup

In figure 1 you can see a snapshot of what LoadRunner TruClient looks like after record and playback. Only 8 steps are recorded to process Salesforce connect, login, and log out. From here business transactions in Salesforce can be recorded and inserted between the login and log out steps.

This record and playback approach is a good way to verify that TruClient is setup properly to record interaction with the target Salesforce application.

Figure 1

The playback output sample is shown in figure 2. You can see the timing on each step. And you can see the status of each step. I had no editing required to execute the script without error. Step 1 is the connection process. Step 2 through 5 represent the login process. And steps 6 through 7 represent the log out process.

If time is of the essence, then TruClient gets the work done with minimal effort. The only down-side with this approach is the script execution is slow in the LoadRunner Controller. But you can get redeemed by using LoadRunner’s Cloud execution tool instead of the controller. To get more detail about this option go to this link: LoadRunner Cloud. An alternative approach is to use LoadRunner’s conversion tool which converts a TruClient script into a VuGEN script. The VuGEN script version is the original script editor.

Figure 2

To create TruClient scripts you always start with launching LoadRunner VuGEN. Then there is a display for protocols. You will see a list of which there are several TruClient options and web options. I used the TruClient web protocol option for developing a script for testing Salesforce.

TruClient Test Results

In the previous display you saw the detail results. There is a button on the display that is labelled “View Summary”. Pressing that button provides you with a summary display as seen in figure 3. That summary includes a link for another report. The report is entitled “Open NV Insights Report”.

Figure 3

The “Open NV Insights Report” is a very useful report. It provides reporting like the Chrome browser Lighthouse feature and LoadRunner’s analysis report showing First to buffer information. You can read more about installing and setting up LoadRunner’s Network Virtualization tool.

TruClient Open NV Insights Report

The default initial display of the report is seen in figure 4. The key displays are

An overall average grade indicating the status of the analysis showing a grade A-F
2 timing indicating time spent in the network and overall duration
The left panel below the timing are buttons to display 7 other reports
The default report is the Recommendations report which is one of the 7
This report displays events assessed with the grades A-F

In performance projects I have conducted I have a reporting approach that divides the output into three categories: Observations, Recommendations, and Conclusions. When performance testing for Salesforce the two primary areas of potential bottlenecks for the customer are the client rendering and network traffic performance. The NV Insights reporting assist with those areas with the following reports:

HTTP Waterfall – graphic report concerning screen rendering
Resource Analysis – graphic reports concerned with page component sizes
Errors report – HTTP code and TCP timeout data
Endpoint Latencies – time reporting between IP addresses
General Waterfall – protocol time reporting between IP addresses
Summaries – time spent connecting to salesforce, rendering on the client, transmitting data, and waiting on responses
Recommendations – this detail provides technical actions to take for response time improvements

Figure 4

Wrap-up

To see more detail of the NV Insights report, view the tutorial.

TruClient is one LoadRunner tool easy for testing Salesforce. Of course, it is a commercial product that can cost significant money for a license. However, it also is available for no cost when you are testing 50 concurrent users or less. There are others that meet performance testing requirements for Salesforce applications. I will address other solutions in other articles. However, it is important to follow Salesforce guidelines regarding performance testing Salesforce applications. Avoid conducting tests that impose high traffic or stressful traffic on the application without first contacting the vendor. The design of the application supports community sharing of resources. Salesforce is cloud-based and thus shares its resources among its customers. You are not alone with your application.

I recommend sign-up on the Salesforce Trailhead site to assist you with becoming comfortable using your Salesforce environment. This site is intended to support you with questions you have, Salesforce knowledge, certification preparation, and track your progress with Salesforce learning topics. There is a similar site called the Salesforce Help. The Salesforce help site is a portal you can log cases, find clear documentation, explore known issues, and get quick access to Trailhead and the Trailblazer Community.

The combination of the sites is powerful for building Salesforce soft and technical skills.

Performance Testing Salesforce with LoadRunner TruClient