Re: [squid-users] Performance tips for accelerator setup

From: Dusten Splan <dsplan_at_myyearbook.com>
Date: Fri, 15 Jan 2010 09:18:31 -0500

One suggestion that I can make is changing your
memory_replacement_policy and cache_replacement_policy to heap LRU.
You should graph your iops on your disk so that you can see if you are
having issues there and need more disk.

Dusten Splan

On Fri, Jan 15, 2010 at 07:18, Markus Meyer <markus.meyer_at_koeln.de> wrote:
> Hi folks,
>
> we're using Squid in an accelerator setup for some time now and it ran
> very smoothly. But now we're getting into some performance trouble. But
> before buying new iron I want to try to squeeze some more performance
> out of our current setup. So if you have any hints on doing this please
> share them.
>
> Here the facts:
>
> - Version: 2.7.STABLE7-2
> - triple sibling peers with two parents
> - using acl urlpath_regex since data are partially different on parents
> - max Traffic: 30 MBit/s Outgoing - 8 MBit/s ingoing
> - max 800 req/s
> - 2x Xeon Dualcore 2 GHz
> - 4x 146 GB disks
> - max CPU Usage:
>  Total: 24%
>  Wait: 16%
>  User: 6%
>  System: 2%
>
> Configuration:
> I post only the important parts(hopefully...)
>
> cache_peer server1 parent 80 0 no-query no-digest originserver
> round-robin name=s1
> cache_peer server2 parent 80 0 no-query no-digest originserver
> round-robin name=s2
> # Siblings exchange cache digest
> cache_peer image10 sibling 80 0 proxy-only name=img10
> cache_peer image45 sibling 80 0 proxy-only name=img45
> # we have 16GB and use 8 as cache
> cache_mem 8192 MB
> # Mean Object Size is ca. 28 KB so we use 50 KB
> maximum_object_size_in_memory 51200 bytes
> memory_replacement_policy lru
> cache_replacement_policy lru
> store_dir_select_algorithm least-load
> collapsed_forwarding on
> # since our content changes very fast we rebuild the digest every ten
> minutes
> digest_rebuild_period 10 minutes
> digest_rewrite_period 10 minutes
> # ca. 80 GB per Disk on Reiser-FS
> cache_dir aufs /web/cache/1 81920 290 256
> cache_dir aufs /web/cache/2 81920 290 256
> cache_dir aufs /web/cache/3 81920 290 256
> cache_dir aufs /web/cache/4 81920 290 256
>
>
>
> Since we cache only tons of small pictures I was thinking about
> implementing COSS. But it's hard to find useful information about it. So
> if this is a real alternative here, can you please point me to some
> documents which help with implementing this. I know about [1] but I
> don't know if this is still valid for 2.7 and it's not easy to wrap my
> head around it.
>
>
> [1] http://wiki.squid-cache.org/Features/CyclicObjectStorageSystem
>
>
>
> Cheers, Markus
>
Received on Fri Jan 15 2010 - 14:18:46 MST

This archive was generated by hypermail 2.2.0 : Fri Jan 15 2010 - 12:00:03 MST