53
# 1 Michael Shields Server Performance Engineer Performance and Scalability Improvements in Perforce

Performance & Scalability Improvements in Perforce

Embed Size (px)

DESCRIPTION

Recent releases of Perforce include improvements targeting performance and scalability. The edge/commit server architecture and lockless reads are two such improvements. This presentation will detail the effect of these improvements as measured in concurrency simulations and production deployments. Some of the server internals implemented to achieve these gains in performance and scalability will also be discussed.

Citation preview

  • 1. #1Michael ShieldsServer Performance Engineer

2. #2Developed and supported software since 1977, specializing inserver optimization for software products including Perforce,Sybase and Ingres. Hobbies includeon the human psyche. 3. #3 Lockless Reads Edge/Commit Servers Clustering 4. #4 5. #5 Goal: Efficiently utilize machine resources Particularly CPU cores Reduce likelihood blocked on metadata locks Lockless Reads != Dirty Reads Returned data is consistent btree and layers above ensure consistency e.g. maxCommitChange, client entity locks 6. #6 Example: p4 sync ///...@--- db.counters--- locks read/write 0/0 rows get+pos+scan put+del 1+0+0 0+0--- db.have--- locks read/write 0/3 rows get+pos+scan put+del 0+1+1 201+0--- db.rev--- locks read/write 0/0 rows get+pos+scan put+del 0+1+202 0+0--- db.working--- locks read/write 0/0 rows get+pos+scan put+del 0+1+1 0+0 7. #7 Example: p4 sync ///...@--- /write /0 rows +pos+scan put+del +0+0 0+0--- db.have--- locks read/write 0/3 rows get+pos+scan put+del 0+1+1 201+0--- /write /0 rows get+ + put+del 0+ + 0+0--- db.working--- locks read/write 0/0 rows get+pos+scan put+del 0+1+1 0+0 Lockless scan of db.rev (uses maxCommitChange) 8. #8 Example: p4 sync ///...@--- db.counters--- locks read/write 0/0 rows get+pos+scan put+del 1+0+0 0+0--- /write /3 rows get+ + put+del 0+ + 201+0--- db.rev--- locks read/write 0/0 rows get+pos+scan put+del 0+1+202 0+0--- /write /0 rows get+ + put+del 0+ + 0+0 Lockless scan of db.rev (uses maxCommitChange) Lockless scan of db.have (uses client entity lock) 9. #9 Example: p4 sync ///...@--- db.counters--- locks read/write 0/0 rows get+pos+scan put+del 1+0+0 0+0--- read/ 0/ rows get+pos+scan +del 0+1+1 +0--- db.rev--- locks read/write 0/0 rows get+pos+scan put+del 0+1+202 0+0--- db.working--- locks read/write 0/0 rows get+pos+scan put+del 0+1+1 0+0 Lockless scan of db.rev (uses maxCommitChange) Lockless scan of db.have (uses client entity lock) db.have update exclusive lock easier to acquire 10. #10 db.peeking=2 Significant concurrency improvements Shared locks not taken for some large reads, e.g. integrate db.peeking=3 Lockless db.rev scan Instead of db.revhx and db.revdx scans with shared locks Can require more resources Not all commands and arguments can be lockless 11. #11 btree layer implementation (Patent Pending) Structural changes requiring checkpoint replay Maximum table size is now 64 zettabytes Additional potential invalidation of process-level caches Data scans can tolerate writes Additional complexities 12. #12 Executes commands typical of a developer sync, fstat, edit, change, submit, integrate, resolve, etc. Concurrent execution of many developer roles Random paths, files per task, and delays Shorter average delay simulates many more users 256@15sec might approximate 10,000@10min 512@15sec ~20,000@10min, YMMV 13. #13 14. #14 15. #15 16. #16 17. #17 18. #18 19. #19 20. #20 21. #21 22. #22 23. #23 EA VMware Not track=1 track=1 required for best analysis 24. #24 25. #25 26. #26 27. #27 28. #28 29. #29 Goal: Improve remote user experience Client commands handled by local edge Helps enable larger remote presence Network load to Commit Server likely reduced Network latency to Commit Server less of an impact acb simulation 128 developer roles, average delay of 15 seconds 128@15sec might approximate 5,000@10min 30. #30 31. #31 32. #32 33. #33 34. #34 35. #35 36. #36 Goals Improve scalability Automated failover Leverages Edge/Commit infrastructure Workspace server/depot master (and depot standby!) Shared archive an integral component Users connect to broker acting as a router Forwards to selected workspace server 37. #37SharedArchiveHigh-bandwidth NetworkClientsClientsClientsClientsCorporate Network 38. #38SharedArchiveHigh-bandwidth NetworkClientsClientsClientsClientsCorporate NetworkDepotMasterWorkspaceServerWorkspaceServerDepotStandby WorkspaceServer 39. #39SharedArchiveHigh-bandwidth NetworkClientsClientsClientsClientsServer ClusteringCorporate NetworkDepotMasterWorkspaceWorkspaceServerDepotStandby WorkspaceServerRouterClusteringRouter 40. #40SharedArchiveHigh-bandwidth NetworkClientsClientsClientsClientsServer ClusteringCorporate NetworkDepotMasterDepotStandbyWorkspaceWorkspaceServerWorkspaceServerLow-Latency NetworkRouterClusteringRouter 41. #41SharedArchiveHigh-bandwidth NetworkClientsClientsClientsClientsServer ClusteringCorporate NetworkDepotMasterDepotStandbyWorkspaceWorkspaceServerWorkspaceServerLow-Latency NetworkRouterClusteringRouterHigh-bandwidth Network 42. #42 acb simulation Average delay reduced to five seconds (from 15) 512@5sec might approximate 60,000@10min Simulation stressed 2x workspace servers: 2x more developers Only 14% longer run time when stressed 43. #43 44. #44 45. #45 46. #46 Doubling workspace servers again Cheated by deploying two on each machine For large deployments, one per machine is best practice Average delay further reduced to three seconds 512@3sec might approximate 100,000@10min 100,000 simulated developer roles! 47. #47 48. #48 49. #49 50. #50 51. #51 Lockless Reads Get there now if youre not already Edge/Commit Servers Deploy edge servers across latency Clustering Scale to even larger number of users 52. #52 53. #53Michael [email protected]@p4mshields