FroNtier Stress Tests Status report

1. FroNtier Stress TestsStatus report Luis Ramos LCG3D Meeting - August 17, 2006

2. Agenda • Objectives • Test Plan • Hw/Sw Setup • Test Cases - Results • Future Work • Conclusions FroNtier Stress Tests - 2/22

3. Objectives • Develop a benchmark for Frontier servers • DB schema independent • Build a tool that identifies performance bottlenecks of a given setup • Performance analysis of the complete sw stack • CORAL / Frontier plugin • Frontier Client • Squid • Frontier Servlet FroNtier Stress Tests - 3/22

4. Test Plan • How fast are the individual components? • Database • Application Server • Cache Server • Network • Explore performance impact of: • Different data (content, size, storage type, compression) • Different complexity database schemas • Different caching policies • How do DB throughput, network bandwidth, payload size, # of clients or server CPU correlate? FroNtier Stress Tests - 4/22

5. Metrics and Parameters • Metrics: • Individual and total throughput • Server errors • CPU consumption/load (clients, frontier server, squid server) • Memory usage and disk space needs • Network bandwidth usage • Parameters: • # of client nodes • # of test clients • Payload sizes • Database structure and content • Caching policy FroNtier Stress Tests - 5/22

6. FroNtier Test Setup FroNtier Stress Tests - 6/22

7. FroNtier Test Setup • Hardware setup: • 1 server running Frontier & Squid: • Dual Intel Xeon CPU 2.80GHz • 2Gb RAM • HD 150Gb • Fast Ethernet (100Mbps) • 1 Backend Oracle Database 10gR2 (cooldev) • Software Setup: • FroNtier v3.1 (need to check keep_alive feature in v3.2) • Frontier Squid v1.0rc4 FroNtier Stress Tests - 7/22

8. Client Setup • Hardware: • Dedicated lxplus nodes • Dual Pentium III 1GHz • 500Mb RAM • HD 6Gb • Fast Ethernet (100Mbps) • Software: • CORAL_1_5_1 with FrontierClient v2.4.7 (hacked to print some metrics) • C++ CORAL/FrontierPlugin test • Queries the server • Gathers results • Outputs measures • Python controller script • Starts a number of clients in several client nodes • Gathers measures • Generates structured data for plotting FroNtier Stress Tests - 8/22

9. Test Cases developed • Data Types analysis • Payload Sizes analysis • Network analysis • Throughput analysis • Includes Database, FroNtier and Squid analysis FroNtier Stress Tests - 9/22

10. Data Types analysis • CORAL static mapping • If DB schema is not created with CORAL: • User may define a different mapping FroNtier Stress Tests - 10/22

11. Payload Compression • Std::string(100) in C++ >> VARCHAR2(100) in DB filled with random numbers • Network payload size in % of user data size: (for different compression levels) FroNtier Stress Tests - 11/22

12. Payload Size • Client side payload size evolution • (HTTP) XML ascii size • (FrontierClient) some bytes down to BLOB base64 • (FrontierClient) 33% down to BIN size • (FrontierClient) up to uncompressed BIN size • (CORAL/FrontierPlugin) down to user C++ data types • With std:strings, user data is ~ the same as DB size FroNtier Stress Tests - 12/22

13. Network Analysis • Test tool that checks network performance between multiple given client nodes and a single server… • Generates TCP/IP between clients and server • Each client shows a throughput and a CPU% • Done using the netcat utility FroNtier Stress Tests - 13/22

14. Throughput analysisFrontier Server • Up to 150 clients running against a single server (direct FroNtier server access, no Squid involved) FroNtier Stress Tests - 14/22

15. Throughput analysisServer error rate Depending on the size of the payload, up to 80 clients can be served from one FroNtier node (no caching) Frontier v3.2 keepalive feature may reduce drastically the error rates FroNtier Stress Tests - 15/22

16. Throughput analysisNetwork, Squid and Frontier • TCP/IP vs Frontier Server vs Squid Cache Hits FroNtier Stress Tests - 16/22

17. Throughput AnalysisCompression level • Zipping performance (single client) • Zip5 throughput is lower because: • CPU time is higher (both on server and client) • Network is not the bottleneck (can be in other scenarios) FroNtier Stress Tests - 17/22

18. Throughput AnalysisCPU% and load average • How CPU% correlates with server total throughput payload = 30kB FroNtier Stress Tests - 18/22

19. Throughput Analysis FroNtierPlugin vs OraclePlugin • CORAL FrontierPlugin vs OraclePlugin (same CORAL code, different connect string) Single client: To do: plot multi client results FroNtier Stress Tests - 19/22

20. Future work • Run multi client throughput tests changing: • DB data type, structure and contents • Access method (Oracle vs Frontier) • Frontier configuration (compression level and caching) • Frontier server error rate analysis • Easily identify the limits of a given setup • Squid caching • Influence of partial caching of the queries • Tests from outside CERN • Run throughput tests from outside to measure the influence of a poorer network connection FroNtier Stress Tests - 20/22

21. Conclusions • Some values already collected • Test scripts developed • Next step: turn scripts easily reusable by others • Real world data needed! • “real” data and a estimate of the ratio between cached and uncached accesses would allow to: • make much more precise statements about compression and achievable rates • Who can provide these estimate/measurement to us? • Further results and analysis • 3D workshop in September FroNtier Stress Tests - 21/22

22. Questions? Ideas? FroNtier Stress Tests - 22/22