140 likes | 260 Vues
This presentation by Brian Davies at GridPP28 discusses essential areas for performance improvement in end-to-end systems. It covers various tuning strategies including File Transfer Service (FTS) adjustments, TCP window tuning, and the trade-offs of synchronous versus asynchronous calls. The talk emphasizes the importance of coordinating optimizations across different sites and the potential impact of network architecture on performance. Practical recommendations are provided for enhanced throughput such as jumbo frames, database optimizations, and understanding the interdependencies of performance enhancements.
E N D
End-to-End performance tuning Brian Davies Gridpp28 Manchester 2012
Areas of Improvements End-End performance tuning • FTS • # Streams • # Files • Tx Timeout • Preparing File Ratio • Copy Mechanism • G-U-C vs srmcp • Asynchronous Ptp • Access Method • Synchronous vs Asynchronous calls • Scheduled vs unscheduled connections. • Srm-less • Federated xrootd • Costs as well as benefits • TCP/ Window Tuning • Jumbo Frames • Some changes only see benefit in end site also make changes. • WN-WAN tuning • Tcp Window size • ‘Nat’ing • Xrootd configuration/optimisation.
Other areas of optimisation?? • Homogenous network • Mixing WN and Disk Servers can easily reduce network bandwidth • VM components • Splitting services • Databases • Type • Separate node • Internal operation • Cleansing • EG DPM requests DB • DNS Aliasing of multiple machines • Knowledge transfer End-End performance tuning
Who does optimisation and when is the benefit seen. • Some optimisations can be unilateral. • FTS tuning, database improvements etc. • Others have to be co-ordinated • Jumbo Frames • Some optimisation benefits seen straight away. • Others require end host to make changes before benefit is seen. • An “improvement” at one site may degrade another site. • TCP tuning at QMUL/RHUL End-End performance tuning
Differences between T1 and T2s? End-End performance tuning (Some) Current T1 issues will/are problems that a “large” T2 will face in X* years time. Problems a T2 are facing now may have been solved by (a) T1 Y* years ago. A site should/does not need try to re-solve a problem(s) that another site(s)/tier has solved in the past. *(Where X and Y are to be determined).
Manchester Network improvements • Transfers from Manc’ to T1s End-End performance tuning
Manchester network improvements • Reverse direction End-End performance tuning
Manchester Network improvements • Transfers from Manc’ to UK T2s End-End performance tuning
Manchester Network improvements • Transfers from Manc’ to Non UK T2s End-End performance tuning
Manchester Network improvements End-End performance tuning
Effect of streams on RALPPD-T1s • Failing transfers required number of threads per transfer to have to be reduced to 1 per file transfer.` • Deemed more important to receive data from CERN than getting good rate for other sites • Mitigated overall throughput by increasing number of concurrent transfers. • Individual file transfer speed reduced and latency increased. • Once underlining issue re-solved returned to previous settings. End-End performance tuning
Effect of streams on T1s-RALPPD #Streams reduced/Increased Effects transfers TO the site. Effects Some T1s more than others End-End performance tuning
Effect of streams on RALPPD-T1s No (known) changes in streams in reverse direction End-End performance tuning
Other areas of optimisation?? • “In the wiki” • But where? • Which wiki? • ???? End-End performance tuning