Communities Performance and Scale Best Practices (for Customers) Frank Leahy, VP Performance Engineering, Community Cloud July 2020, v1.3 Forward-Looking Statements Statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements. Performance vs Scale ● Performance - the time it takes to load a single page in the desktop browser or on a mobile device ● Scale - the ability of a system to serve pages under increasing load while maintaining page-level performance Before you ship, you’ll want to be sure that your implementation is performant, and that it scales. Terminology ● Performance - the time it takes to load a single ● OOTB - Out of the Box, what’s available page in the desktop browser or on a mobile without doing any custom coding device ● Arrival Rate - aka Load. The RPM (requests ● Scale - the ability of a system to serve pages per minute) that will be required of the system. under increasing load while maintaining This is typically defined on a page by page page-level performance basis, e.g. arrival rate to the home page, to the search page, to the article page, to the cart ● Throughput - number of requests per unit time page, checkout page, etc. (requests per minute or requests per second) ● Sustained Load - the average load during the ● Response Time - time it takes the system to heaviest parts of the day, in RPM. respond. Depending on the context can also include the time to deliver the results over the ● Peak Load - the highest expected daily, users’ network connection, or render the page weekly, monthly, or seasonal load. in the browser or mobile phone. ● Org Shape - number of objects in the org, e.g. ● SLA - service level agreement number of customers, accounts, products, ○ Perf: “the page will load in under 3 seconds” carts, etc. ○ Scale: “we can handle 10,000 requests/minute” A Little Background on Communities Perf and Scale ● We have tuned all of the OOTB Community Components so that they have good performance, and so that they scale. ○ There are about 40 components, from Feeds, to KB Articles, Top Users, etc. ● But, as soon as you start customizing your Community -- whether it’s using non-Communities objects, or using APEX, or building custom Lightning components -- the OOTB performance and scale numbers no longer apply. ○ Because the custom code may not be performant Performance and Scale Best Practices ● Draw a full system diagram which includes all future features, systems (internal and external) and users (web, mobile, API, etc.) that will touch Salesforce 2. My Web 3. My App 1. eCommerce 4. Assist Channels API Salesforce B2B & B2C Service Console API 5. System to System Integration Performance and Scale Best Practices ● Estimate load levels for each part of the system. Examples... ○ State assumptions: 8 hour day. Sustained = avg during middle 3 hours. Peak = monthly promos. Sustained: 100 pv/sec Sustained: 200 API calls/sec Peak: 1000 pv/sec Peak: 400 API calls/sec SLA: < 3 seconds/page SLA: < 300ms/request Sustained: 10 order/min 2. My Web 3. My App Sustained: 5,000 agents taking 4 calls/hour Peak: 100 orders/min Peak: 10,000 agents taking 6 calls/hour SLA: < 10 seconds/order SLA: < 5 seconds/page 1. eCommerce 4. Assist Channels API Salesforce B2B & B2C Service Console Sustained: 2M API calls/day via Mulesoft (8 hour day) API Peak: 10M API calls/day with 50% in 2 hours SLA: < 500ms 5. System to System Integration Performance and Scale Best Practices ● Break down usage to the next level. Examples... My App Usage: My Web Page Usage: - Read /account 25% - Home 40% - Read /assets 25% - Search 8% - Read /users 25% - Product List 10% - Create any of above 10% - Product Detail 20% - Update any of above 15% - Create Case 2% 2. My Web 3. My App - View Case 3% Assist Channels Usage: - Other 17% (features go here) eCommerce Usage: 1. eCommerce 4. Assist (features go here) Channels API Salesforce B2B & B2C Service Console API Usage: API (/endpoints go here) 5. System to System Integration Performance & Scale Considerations ● Important Performance Factors ○ Size and shape of org (amount and type of data) ○ Number and types of users (CC vs CC+/PRM license type) ○ Data complexity (roles and sharing rules if any, custom objects, etc.) ○ Process complexity (e.g. complex apex calls made by customer code) ○ User flows (number of pages viewed per second, and resulting apex calls made by customer code) ○ Expected load levels (both sustained and peak) ● Important Performance Metrics ○ Transaction throughput (tps - transactions per second) ○ Response times (median, p95) ○ App and Db CPU % (median, p95) ● The two most important items are almost always Load and Db CPU Performance Best Practices - Overview ● Set up a performance and scale program at the start of the development cycle ○ Why? Because if you wait until you’re about to go live, it will probably be too late to fix. ○ Decide on performance, scale and SLA requirements ○ Create a test plan ○ Run tests hourly or daily, looking for changes in key metrics such as response times and throughput. ○ Understand and fix issues right away. ○ Do this from Day 1 Performance Best Practices - Page Level Testing ● We recommend you run page level tests regularly (preferably nightly) ○ Why: So you’re not surprised about your site’s front-end performance ○ How: Set up a test community and run performance tests nightly using a continuous deployment model ○ Customize: As you create custom components, add them to the page or pages where they will be used, and see how that impacts page load times ○ Watch: For changes in page load times as you add new features and components to your pages ○ CPO: Use Community Page Optimizer to look deeper into your component code Performance Best Practices - Regular Scale Testing ● We recommend you run low load scale tests regularly (preferably nightly) ○ Why: So you’re not surprised about your site’s back-end performance ○ How: Set up a test community and run low load (e.g. 5 concurrent users for 10 minutes) tests nightly using a continuous deployment model ○ Watch: For changes in key metrics such as response times and throughput. If something gets slower, you are able to look for the cause immediately rather than trying to find the issue near the release ○ Event Logs: use Event Logs to investigate deeper into which calls are the slowest on the back-end. Performance Best Practices - Scale Testing ● Estimate data size and shape ○ number of accounts, users, objects, feeds, groups, articles, topics, etc. ○ any complex relationships between objects ○ any complex role hierarchies and sharing rules ● Build a representative org on sandbox ● Estimate load ○ Use existing site data (if available) as a starting point ○ Build user personas (admin, browser, searcher, shopper, buyer, etc.) ○ Build a site map and fill out likely page flows for each persona ○ Estimate user arrival rates, login rates, which pages are being viewed, page views per session, etc. ● Write persona based load generation scripts using a tool like LoadRunner or JMeter ● Run the test nightly at a low-ish level (e.g. 5 concurrent users for 10 minutes), and watch for changes in