320 likes | 451 Vues
This study assesses the filesystem performance of Squid across various operating systems, filesystems, and storage schemes using the Web Polygraph benchmarking tool. Key operating systems examined include Linux, FreeBSD, NetBSD, OpenBSD, and Solaris, while different filesystems like ext2fs and XFS are analyzed. The benchmark aims to establish reliable performance metrics for optimal Squid configuration using consistent workloads. Findings suggest that FreeBSD with softupdates and diskd, and Linux with ext2fs and aufs, deliver the best performance outcomes.
E N D
Comparing Squid FilesystemPerformance with Web Polygraph Duane Wessels wessels@squid-cache.org O’Reilly Open Source Convention July 24, 2002
Motivation • Squid performance depends greatly on the filesystem. • Want to compare different operating systems, filesystems, filesystem options, and Squid storage schemes. • Need a good benchmark with minimal input parameters.
Squid Filesystem Options • OSes: Linux, Free/Net/OpenBSD, Solaris, ... • Filesystems: UFS, ext2fs, ext3fs, xfs, reiserfs. • Filesystem Options: noatime, softdep, async. • Squid Storage Schemes: ufs, aufs, diskd. • Other parameters we won’t discuss.
Web Polygraph • Powerful, flexible benchmarking tool for HTTP intermediaries. • PolyMix-4: standardized workload for client-side caching proxies. • DUT: Device Under Test – Squid in this case.
Best Effort Workloads • N agents submit requests as fast as the DUT allows. • Each agent is always “busy.” • Many benchmarks work this way because it is easy to implement. • The DUT response time can affect throughput. • Easy to make mistakes. • Difficult to trust results. • Number of agents becomes an arbitrary input parameter. • Difficult to compare different devices
Constant Mean Throughput Workloads • Agents submit requests at a constant mean rate. • Agents spend some time being idle. • Results are more believable. • Test may fail after running for a long time. • Hard to find the ideal, peak throughput. • Throughput is an input parameter.
Constant Response Time Workloads • Offered load varies depending on measured response time. • Otherwise just like constant throughput • Tests are less likely to fail halfway through. • Removes throughput as an input parameter. • Selecting the response time window is tricky. • Sometimes observe response time spikes. • Requires a constant/predictable hit ratio. • Cannot compare to a no-caching workload
The “rptmstat” Workload • Response time window: 1.4 – 1.5 seconds. • Load delta: 1%. • “down” sample rate: 1000 transactions. • “up” sample rate: 2000 transactions. • Workload goal: fill the cache twice. • Adjusts “populous factor” – the number of active agents.
Sample rptmstat Console Output 398.25| i-rptmstat 2715719 89.02 1446 60.38 0 822 fyi: rptmstatDn: 1.47sec rptm requires no load adjustment fyi: rptmstatUp: 1.41sec rptm requires no load adjustment fyi: rptmstatDn: 1.67sec rptm changes load by -1.00% fyi: rptmstatDn: 1.40sec rptm requires no load adjustment fyi: rptmstatUp: 1.54sec rptm requires no load adjustment fyi: rptmstatDn: 1.26sec rptm requires no load adjustment fyi: rptmstatDn: 1.51sec rptm changes load by -1.00% fyi: rptmstatUp: 1.39sec rptm changes load by +1.00% fyi: rptmstatDn: 1.52sec rptm changes load by -1.00%
The Squid Filesystem Tests • Five different operating systems. • Identical hardware. • Identical Squid source code. • Nearly identical Squid configuration. • Different filesystems, options, storage schemes.
Hardware for Squid • IBM Netfinity 4000R. • 500 MHz Pentium 3. • 1GB RAM. • 3 x 18GB SCSI disk (one external). • Integrated Intel 10/100 NIC.
Squid Configuration • Squid 2.4.STABLE5. • 3 x 7500 MB cache_dir (L1=16, L2=256). • Logging disabled. • Default cache_mem (8MB).
The Linux Box • Linux 2.4.9-13, with SGI XFS_1.0.2 patches • 8192 file descriptors • ./configure –with-aio-threads=32 • Xfsprogs 1.3.13 • Reiserfsprogs 3.x.0j
The NetBSD Box • NetBSD 1.5.3_RC1 • MAXFILES=8192 • NMBCLUSTERS=32768
The OpenBSD Box • OpenBSD 3.0 • MAXFILES=8192 • Only 4096 per process however • Not an issue – usage is well below this limit • NMBCLUSTERS=32768
The FreeBSD Box • FreeBSD 4.5-STABLE • MAXFILES=8192 • NMBCLUSTERS=32768
The Solaris Box • Solaris 5.8 for Intel (generic 108592-09) • /etc/system: • rlim_fd_max=8192 • /etc/nsswitch.conf: • hosts: dns files • /etc/nscd.conf: • enable-cache hosts no • newfs –b 4096 –i 6144 … • tunefs –o space …
Validating rptmstat • Can rptmstat predict PolyMix-4 performance? • Start with mean throughput during last ¼ of rptmstat run. • Increase or decrease throughput in 10% increments. • Always use the same fill rate, however.
Conclusions • For Squid, the best performing filesystems are: • FreeBSD: softupdates and diskd storage scheme • Linux: ext2fs and aufs storage scheme • The rptmstat workload does not accurately predict PolyMix-4 peak throughput. • rptmstat is a more difficult workload because DHR is always 60% • rptmstat predicts modified PolyMix-4 performance within 10%.
More Information • Squid: www.squid-cache.org • Web Polygraph: www.web-polygraph.org • Duane Wessels: wessels@squid-cache.org