Moving Sharing to a Parallel Architecture
0 likes437 views
The document discusses how Salesforce moved sharing operations to a parallel architecture to improve performance and scalability. Sharing tables control access at the record level but were previously processed sequentially, limiting performance. Salesforce now enqueues sharing jobs in parallel batches which are processed asynchronously by multiple applications. This approach provides 4-5x faster performance for sharing operations like creating rules in production environments, and up to 15x faster in testing. The parallel architecture is being rolled out gradually and more optimizations are planned to support continued scalability.
Ad
More Related Content
What's hot (20)
Similar to Moving Sharing to a Parallel Architecture (20)
Ad
More from Salesforce Developers (20)
Ad
Recently uploaded (20)
Moving Sharing to a Parallel Architecture
- 1. Moving Sharing To a Parallel Architecture How We Made Sharing Operations Really Fast Seth White, Salesforce.com, Platform R&D @sethjwhite
- 2. Safe harbor Safe harbor 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.
- 4. Agenda Overview of record-level access The “big data” challenge Parallel sharing Performance results Demo
- 5. Sharing Tables Sharing tables control record-level access Acct ID Account Table Owner Acct Name Account Sharing Table Acct ID User/Group Row Cause A1 A2 Carol Hailey A1 A1 A1 A2 Acme General Inc. Carol Bob East Hailey Owner Manual Rule Owner
- 6. Sharing Operations Actions that update sharing tables ▪ Changing record owner ▪ Changing user’s role ▪ Adding/deleting/updating a sharing rule ▪ Changing organization-wide defaults
- 7. Sharing Features Things that make sharing operations complex ▪ Role hierarchy ▪ Implicit sharing • Access to account implies access to opportunity • Access to opportunity implies access to account ▪ Portal sharing Sharing operations are complex joins
- 8. The Sharing Challenge Data size doubles every year ▪ Shared records • Jan 2012 – 6.2 billion • Apr 2013 – 13.5 billion ▪ Sharing records • Apr 2013 – Total – 43 billion – Largest org – 728 million
- 9. Customers Are Getting Bigger 100 million accounts 2 million portal users 100,000 users 5000 roles 1,000,000,000+ records
- 10. What to do?
- 11. What to Do? Make operations asynchronous ▪ MQ framework ▪ Great for reliability Make use of parallelism ▪ …lots of parallelism ▪ Individual objects are largely independent
- 12. Account Parallelism Example Accounts are independent… Acct ID Account Table Owner Acct Name Account Sharing Table Acct ID User/Group Row Cause A1 A2 Carol Hailey A1 A1 A1 A2 Acme General Inc. Carol Bob East Hailey …so we can process them in parallel. Owner Manual Rule Owner
- 13. Message Queue Many features becoming asynchronous ▪ Reaching 160,000,000 messages per day ▪ 450 different types of messages ▪ Volume doubled between releases Messages stored in Oracle ▪ HA/DR Message processing is adaptive
- 14. The Way We Were Reques t Is Receive d POD ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4
- 15. The Way We Were POD ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4 Reques t Is Receive Do d Processin g
- 16. The Way We Were POD ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4 Reques t Is Receive Do d Processin g Respo nse Is sent
- 17. The Way We Were Not Using the Cluster POD ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4 Reques t Is Receive Do d Processin g Respo nse Is sent
- 20. Parallel Sharing Lifecycle POD Respo nse Is Sent ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4
- 23. Parallel Sharing Lifecycle POD Process Batch 1 ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4
- 24. Parallel Sharing Lifecycle POD Process Batch 2 ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4
- 25. Parallel Sharing Lifecycle POD Process Batch 3 ap p7 ap p8 Que ue ap p1 Ora cle RA C ap p6 ap p2 ap p3 ap p5 ap p4
- 26. Performance Results Create Sharing Rule Sequential Account 389 Opportunity 343 Custom Object 100 Parallel 85 71 24 Gain 4.5x 4.8x 4.1x all times are in seconds Production Settings
- 27. Overall Performance 4-5x faster (in production environments)
- 28. Performance Results Create Sharing Rule Sequential Account 389 Opportunity 343 Custom Object 100 Parallel 31 23 10 Gain 12.5x 14.9x 10x all times are in seconds Laboratory Settings
- 29. Overall Performance 10-15x faster (in laboratory environments)
- 30. Release Schedule Summer ’13 ▪ Pilot ▪ GA Winter ’14 ▪ Pilot ▪ GA
- 32. Conclusions Continuing platform investment Moving to a parallel/asynchronous architecture More sharing optimizations coming Path forward for scalability
- 33. Seth White Kapil Easwar Platform R&D, Salesforce. com Platform R&D, Salesforce.com