Performance & Scalability Improvements in Perforce
•Download as PPTX, PDF•
1 like•3,213 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Performance & Scalability Improvements in Perforce
Similar to Performance & Scalability Improvements in Perforce (20)
More from Perforce
More from Perforce (20)
Recently uploaded
Recently uploaded (20)
Performance & Scalability Improvements in Perforce
- 1. # 1 Michael Shields Server Performance Engineer
- 2. # 2 Developed and supported software since 1977, specializing in server optimization for software products including Perforce, Sybase and Ingres. Hobbies include on 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 //<depot-path>/...@<change> --- 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 //<depot-path>/...@<change> --- /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 //<depot-path>/...@<change> --- 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 //<depot-path>/...@<change> --- 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. # 37 Shared Archive High-bandwidth Network Clients Clients Clients Clients Corporate Network
- 38. # 38 Shared Archive High-bandwidth Network Clients Clients Clients Clients Corporate Network Depot Master Workspace Server Workspace Server Depot Standby Workspace Server
- 39. # 39 Shared Archive High-bandwidth Network Clients Clients Clients Clients Server Clustering Corporate Network Depot Master Workspace Workspace Server Depot Standby Workspace Server Router Clustering Router
- 40. # 40 Shared Archive High-bandwidth Network Clients Clients Clients Clients Server Clustering Corporate Network Depot Master Depot Standby Workspace Workspace Server Workspace Server Low-Latency Network Router Clustering Router
- 41. # 41 Shared Archive High-bandwidth Network Clients Clients Clients Clients Server Clustering Corporate Network Depot Master Depot Standby Workspace Workspace Server Workspace Server Low-Latency Network Router Clustering Router High-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 you’re not already • Edge/Commit Servers • Deploy edge servers across latency • Clustering • Scale to even larger number of users
- 52. # 52
- 53. # 53 Michael Shields mshields@perforce.com @p4mshields
Editor's Notes
- Writers in part of the btree don’t affect readers of other parts.
- All data is from the active portion of the simulation: all roles have warmed up and are running their tasks (and none have finished).
- All data is from the active portion of the simulation: all roles have warmed up and are running their tasks (and none have finished).