Re: [squid-users] Squid-2, Squid-3, roadmap
Mark, thanks for raising these questions, we at Last.FM are facing the same issues as Yahoo! is wrt squid-2/-3. In answer to your final question in the list, I've tested -3 on a number of servers over a number of time-periods during the past few months. Unfortunately, the missing features found within -2, combined with sluggish overall response times and higher server load make it impossible for me to move over to it for our production squid cluster. -Tony -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Forwarding HTTP and HTTPS Traffic to an Upstream Proxy using Cache_Peer on separate ports
On Wed, 20 Feb 2008 19:57:45 - "Ric Lonsdale" <[EMAIL PROTECTED]> wrote: > However, the Finjan appliance listens on port 8080 for standard HTTP > traffic, but listens on 8443 for HTTPS (SSL) traffic, and squid > returns the following error with this setup. > > FATAL: ERROR: cache_peer 10.198.1.2 specified twice > cache_peer 10.198.1.2 parent 8080 7 no-query > cache_peer 10.198.1.2 parent 8443 7 no-query > acl httptraffic proto HTTP > acl httpstraffic proto HTTPS > http_access allow httptraffic > http_access allow httpstraffic > cache_peer_access 10.198.1.2 allow httptraffic > cache_peer_access 10.198.1.2 allow SSL_ports > never_direct allow all > > Is it possible to change the squid.conf settings to send HTTP and > HTTPS requests to the same upstream Finjan appliance, but on separate > ports? You'll be wanting to do the following: cache_peer 10.198.1.2 parent 8080 7 no-query name=finjanhttp cache_peer 10.198.1.2 parent 8443 7 no-query name=finjanhttps cache_peer_access finjanhttp allow httptraffic cache_peer_access finjanhttps allow httpstraffic hth Tony
Re: [squid-users] don´t cache some site
no_cache is deprecated. Use "cache deny " instead. -Tony On Mon, 28 Jan 2008 20:06:40 -0300 "Emiliano Vazquez" <[EMAIL PROTECTED]> wrote: > Hi, you need to use no_cache > > > Example: > ### > acl XXX dstdomain site.com > no_cache deny XXX > > > > > I hope it helps. > > Emiliano Vazquez > > > > > - Original Message - > From: "Wilson A. Galafassi Jr." <[EMAIL PROTECTED]> > To: > Sent: Monday, January 28, 2008 4:53 PM > Subject: [squid-users] don´t cache some site > > > Hello to all. > > What i have to configure in squid.conf to squid don´t cache some > sites? Thanks > Wilson > >
Re: [squid-users] wccp transparent proxy; returned spoofed packets are dropped!
Adrian Chadd wrote: Didn't someone point out a few weeks ago that Cisco only support wccp redirection on the same interface as clients? the ASA is probably (quite rightly, its a firewall!) dropping the packets coming in from the DMZ as they're spoofed from another interface it knows about. You may be short of luck; you may have to put the proxy on INSIDE. See if that works. I'd offer better advice but I don't have an ASA to actually do testing on.. Actually, it depends on the firewall configuration mode... if it's in transparent mode, you're s.o.l, as the max number of interfaces == 3 (including the management interface). If it's in routed mode, you stand a better chance, and can enable communication between the interfaces. The logging buffer will reveal all though. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] wccp transparent proxy; returned spoofed packets are dropped!
Daniel Rose wrote: SQUID (linux kernel 2.6.18.xxx) Sends a spoofed ACK 'from' WWWHOST to CLIENT. The spoofed ACK never arrives at the CLIENT. CLIENT just sends 3 SYNs and times out. I assume it's dropped by the firewall, but I can't get 'debug ip packet' or similar commands to work on the ASA 5520 to verify this, but it's pretty clear since it never arrives on the client (I used wireshark). Have you tried turning up the logging level and seeing what the asa is doing? My money is on it dropping your packets. Adjust logging to "errors" if you're getting to much log data. # conf t (config)# logging asdm warnings # sh logging asdm -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] 2.7 vs 3.0
Jason wrote: I'm about to build a cache for a production environment. Which do I want, 2.7 or 3.0? If you have time for a detailed answer, what are the differences? BTW, this will be an intercepting/transparent proxy via iptables. Jason You want 2.6STABLE17 right now, and 2.7 when it is released. =] 3.0 isn't really ready for a production environment yet. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
Amos Jeffries wrote: Did you move to 2.6 in the process? I found that carp is accepted in 2.5 but marked experimental and before many bugs fixes that went into 2.6. Try adding debug_options ALL,1, 39,5 to squid.conf and see what pops into cache.log I've been running 2.6 for a while; and currently testing 2.HEAD & 3.0STABLE1 on two machines. I've dropped a bugzilla for this, along with a patch to modify the functionality to include http_port within the carp hashing code. It enables a squid config option of 'carp_hash_port on/off': http://www.squid-cache.org/bugs/show_bug.cgi?id=2153 Log output previously looked like: 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 and 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:58| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:58| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:58| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:59| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:59| carpSelectParent: selected 10.0.20.2 and now looks like: 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:82 combined_hash 1266692258 score 1208401297 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:81 combined_hash 1239382347 score 1182348140 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:83 combined_hash 223054348 score 212789777 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:84 combined_hash 251909667 score 240317225 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:81 combined_hash 223054348 score 212789777 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:82 combined_hash 251909667 score 240317225 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:83 combined_hash 281703136 score 268739651 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:84 combined_hash 2862529730 score 2730801121 and 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.2:83 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.2:84 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.1:84 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.1:82 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.1:84 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.2:81 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.1:83 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.2:82 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.1:84 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.2:81 -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
On Tue, 18 Dec 2007 13:53:42 +1300 (NZDT) "Amos Jeffries" <[EMAIL PROTECTED]> wrote: > > IIRC Squid3.0 introduces weighted-round-robin for this purpose. > Otherwise there is CARP in 2.6. So, I've implemented CARP, but I'm seeing some odd behavior... Given the following config lines: ###Userserve cache_peer 10.0.20.1 parent 81 0 no-query originserver no-digest no-netdb-exchange name=userserve1-81 carp weight=1 cache_peer_domain userserve1-81 userserve.last.fm cache_peer 10.0.20.1 parent 82 0 no-query originserver no-digest no-netdb-exchange name=userserve1-82 carp weight=1 cache_peer_domain userserve1-82 userserve.last.fm cache_peer 10.0.20.1 parent 83 0 no-query originserver no-digest no-netdb-exchange name=userserve1-83 carp weight=1 cache_peer_domain userserve1-83 userserve.last.fm cache_peer 10.0.20.1 parent 84 0 no-query originserver no-digest no-netdb-exchange name=userserve1-84 carp weight=1 cache_peer_domain userserve1-84 userserve.last.fm cache_peer 10.0.20.2 parent 81 0 no-query originserver no-digest no-netdb-exchange name=userserve2-81 carp weight=1 cache_peer_domain userserve2-81 userserve.last.fm cache_peer 10.0.20.2 parent 82 0 no-query originserver no-digest no-netdb-exchange name=userserve2-82 carp weight=1 cache_peer_domain userserve2-82 userserve.last.fm cache_peer 10.0.20.2 parent 83 0 no-query originserver no-digest no-netdb-exchange name=userserve2-83 carp weight=1 cache_peer_domain userserve2-83 userserve.last.fm cache_peer 10.0.20.2 parent 84 0 no-query originserver no-digest no-netdb-exchange name=userserve2-84 carp weight=1 cache_peer_domain userserve2-84 userserve.last.fm ###Userserve Ends I had expected to get an equal number of connections spread across each cache_peer instance (we run one perlbal instance per core on each of the machines). What I'm seeing though, is that squid is only connecting to two of the above, and in both cases, the first occurrence of each: [EMAIL PROTECTED] ~]# sort /userservestats | uniq -c 25244 CARP/userserve1-81 25949 CARP/userserve2-81 Does squid, or rather the squid CARP code have something in it which allows it to only use one port per IP address? Thanks! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
Amos Jeffries wrote: No, its just the most modern and one thats shown some promise in recent benchmarking earlier this year by a large-scale user. Thier exact results are buried back in the mailing list somewhere. There are other algorithms, with different properties that suite differing siutaions. I'll take a look at CARP, thanks =] The config manual seems to suggest otherwise: "cache_peer 172.16.1.123 sibling 3129 5500 weight=2" Or am I assuming too much here? I could be getting the wrong end of the stick; but it seemed like using a similar cache_peer entries to the above, but with a couple having the weight=100 didn't seem to change the way squid was choosing the cache_peer to use. I'm not sure which config manual you got that from. The Official Authoritative one does not include that text. http://www.squid-cache.org/Versions/v2/2.6/cfgman/cache_peer.html http://www.squid-cache.org/Versions/v3/3.0/cfgman/cache_peer.html ViSolve.. heh Thanks again Amos! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
Amos Jeffries wrote: Hi Guys, Wanted to double check I hadn't screwed up my config lines before dropping a bug report Good choice. :-) round-robin == round-robin: each server trued in sequence until all have bee tried then repeats. No weighting there. IIRC Squid3.0 introduces weighted-round-robin for this purpose. Otherwise there is CARP in 2.6. Amos Hey Amos, Hmmm, so the only way for weighting cache_peers in 2.6 is with CARP? The config manual seems to suggest otherwise: "cache_peer 172.16.1.123 sibling 3129 5500 weight=2" Or am I assuming too much here? I could be getting the wrong end of the stick; but it seemed like using a similar cache_peer entries to the above, but with a couple having the weight=100 didn't seem to change the way squid was choosing the cache_peer to use. Thanks! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
[squid-users] cache_peer weighting
Hi Guys, Wanted to double check I hadn't screwed up my config lines before dropping a bug report I've got some of my parent's configured with weight's, as we're trying out some performance optimizing code on perlbal... thing is, setting a weight in squid doesn't seem to make a difference to the number of requests that squid sends back to the parent. This is Squid-2.6STABLE17. [EMAIL PROTECTED] ~]# grep perlbal1-80 /squidperlbal | wc -l 2 [EMAIL PROTECTED] ~]# grep perlbal2-80 /squidperlbal | wc -l 248 [EMAIL PROTECTED] ~]# grep -v perlbal[12]-80 /squidperlbal | wc -l 750 --I expected at least the inverse of the above, as unless my understanding of squid weighting is completely incorrect, a weight of 100 should mean that peer is being used for 100 times more connections than the weight=1 (default weight) peers, no? Squid is configured with the following: ###ws.audioscrobbler.com & mainsite cache_peer 10.0.0.14 parent 80 0 no-query originserver no-digest no-netdb-exchange name=saruman2-80 round-robin cache_peer_access saruman2-80 allow mainsite cache_peer 10.0.0.14 parent 80 0 no-query originserver no-digest no-netdb-exchange name=saruman2-81 round-robin cache_peer_access saruman2-81 allow mainsite cache_peer 10.0.0.35 parent 80 0 no-query originserver no-digest no-netdb-exchange name=perlbal1-80 round-robin weight=100 cache_peer_access perlbal1-80 allow mainsite cache_peer 10.0.0.35 parent 81 0 no-query originserver no-digest no-netdb-exchange name=perlbal1-81 round-robin cache_peer_access perlbal1-81 allow mainsite cache_peer 10.0.0.114 parent 80 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-80 round-robin weight=100 cache_peer_access perlbal2-80 allow mainsite cache_peer 10.0.0.114 parent 81 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-81 round-robin cache_peer_access perlbal2-81 allow mainsite cache_peer 10.0.0.114 parent 82 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-82 round-robin cache_peer_access perlbal2-82 allow mainsite cache_peer 10.0.0.114 parent 83 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-83 round-robin cache_peer_access perlbal2-83 allow mainsite ###ws.audioscrobbler.com & mainsite Ends I also tried removing round-robin, in case that was screwing up the config, however, i found that this merely means all requests go to saruman2-80. Thanks! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
[squid-users] storeUpdateCopy errors
Running Squid-2.HEAD, I'm seeing lots of 'storeUpdatecopy: Error at ### (-1)' in the cache.log. I'm not sure if it has anything to do with the ctx errors I'm also seeing: 2007/12/17 18:37:39| ctx: enter level 0: 'http://ws.audioscrobbler.com/1.0/user/goldiesogay/profile.xml?widget_id=59b43a5fbbd8fb5e5a1b94ac9de7f2d9' 2007/12/17 18:37:39| storeSetPublicKey: unable to determine vary_id for 'http://ws.audioscrobbler.com/1.0/user/goldiesogay/profile.xml?widget_id=59b43a5fbbd8fb5e5a1b94ac9de7f2d9' 2007/12/17 18:38:00| ctx: exit level 0 2007/12/17 18:38:00| storeUpdateCopy: Error at 324 (-1) Adrian thinks this is to do with the object re-validation Henrik's put into 2.HEAD; has anyone else seen something like this? -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] combine two connection
Alexandre Correa wrote: No !! you can do custom tcp_outgoing acls .. using source address.. but not join links !! There's no reason you can't do bonding at the iface level to do load balancing across two network uplinks. This won't work, however, if you're using something dial-up oriented -- ppoe/ppoa/etc. -tony -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] ReiserFS
[EMAIL PROTECTED] wrote: I have read that reiserFS would give better performance as compared to ext3 and xfs. With what is going on with the developer of this FS is it still a good idea to use this FS? What are you talking about? It's not like he killed his wife or something.. oh...wait. On a more serious note, ReiserFS security updates and bug fixes will still be released, but namesys is putting its development time into Reiser4 now. See http://www.namesys.com for more details. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] question about filesystems and directories for cache.
Chris Robertson wrote: First of all, thanks for sharing the write-up. There are a number of high-load squid installations (Wikipedia, and Flikr are two of the largest I know of), but not much information on what tweaks to make in the interest of performance. No problem. =] I encountered the same problem when trying to figure out how to get more performance so I figured once I'd cracked it, the least I could do was document it for the other people having the same issue (and to give myself a reference for later). After perusing your posting, I'm wondering if you would run a "squidclient -p 80 mgr:info |grep method". I'm making the assumption that your squid is listening on port 80, so please change the argument to -p if needed. Your configuration options included "--enable-poll", but with a 2.6 kernel and 2.6 sources, I would be surprised if you are not actually using epoll. It might be a superfluous compile option. [EMAIL PROTECTED] ~]# squidclient -p 8081 mgr:info |grep method IO loop method: poll Cache digests are not the only method of sharing between peers. ICP is an alternative and I have read that multicast works well for scaling beyond a handful of peers. I can't seem to find the posting now that I want to reference it. I'd trust your experience over my memory of someone else's posting, but I thought I would raise the possibility. I was under the impression that when utilizing cache peering, it worked better if the squids had a digest of what was on X squid server, before asking for it. I could be wrong on that though - Adrian, care to comment on this one? It's now redundant in my situation though, as every peering mechanism is slower than going back to parent in our use case. I'm surprised you had to specify your hosts file in your squid.conf. /etc/hosts is the default. There are a couple of bugs in squid that seem to cause issues if you don't actually specify the hosts file within the squid conf... worst case, it's an extra line of config to parse on startup. Lastly, I'd be wary of specifying dns_nameservers as a squid.conf option. Squid will use the servers specified in /etc/resolv.conf if this option is not specified. Now you have to maintain name servers in two locations. Same goes here; DNS lookups were taking 200-1000ms without specifying dns_nameservers in the config (the nameservers specified there are the same ones within /etc/resolv.conf), now they're sub 1ms. There isn't much chance of us re-ip-ing internally, so it's a pretty safe config option for us. I definitely agree that it could cause problems for people using public DNS resolution though. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] problem with squid 2.6
Try running squid in debug mode: squid -X Also, check your cache.log and see if anything relevant is in there. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] question about filesystems and directories for cache.
Quoting Adrian Chadd <[EMAIL PROTECTED]>: > On Sat, Nov 24, 2007, Alexandre Correa wrote: > > reiserfs 4 is much better than ext3 ... > > [citation needed] > > I know reiserfs vs ext2|3 benchmarks in the past showed reiserfs did a little > better but both codebases have advanced over the last few years. > I'd love to see an actual up to date comparison. All the benchmarking I performed while testing ext3 vs xfs vs reiserfs for squid showed that reiserfs gave the best bang per buck for io intensive small file operations... That said, I too would like some definative numbers/graphs for comparison in different settings. Perhaps next time I rebuild one of my squid boxes, I'll run some benchmarks and document them. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London, N1 6DL Check out my music taste at http://www.last.fm/user/HawkeVIPER
Re: [squid-users] question about filesystems and directories for cache.
Matias Lopez Bergero wrote: Hello, I'm being reading the wiki and the mailing list to know, which is the best filesystem to use, for now I have chose ext3 based on comments on the list, also, I have passed the nodev,nosuid,noexec,noatime flags to fstab in order to get a security and faster performance. Hi Matias, I'd personally recommend against ext3, and point you towards reiserfs. ext3 is horribly slow for many small files being read/written at the same time. I'd also recommend maximizing your disk throughput, by splitting the raid, and having a cache-dir on each disk; though of course, you'll loose redundancy in the event of a disk failure. I wrote a howto that revolves around maximizing squid performance, take a look at it, you may find it helpful: http://blog.last.fm/2007/08/30/squid-optimization-guide -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Squid not responding
stephane lepain wrote: Hi Guys, Squid did not respond when I restarted my PC. I don't have any error message in /etc/squid/squid.out. It seems that squid is not even registering. Since I don't have an error message, I can't sort this out. I also tried a restart, stop and start but nothing would do. /etc/rc.d/init.d/ and then ./squid restart. Anyone has any thought on this? Have you tried running squid with the debug flag to see what it is doing? -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Squid on DualxQuad Core 8GB Rams - Optimization - Performance - Large Scale - IP Spoofing
Andrew Miehs wrote: > Hi Tony, Not that I am a SuperMicro fan any longer, but I suspect the reason that the Poweredge is quicker is because of the quicker disks - and if you are running a 64bit OS, because of the increased amount of memory. Agreed. I'm going to be trialling a 1950 with 10k rpm 146gb drives in it in a few weeks; same spec otherwise. Think it'll be interesting to see the performance difference between the two disk speeds. All machines are 64bit, and squid is a memory whore, so 8gb helps, a lot. Squid can only utilise one processor, so you would be better off with the Xeon 5148 if CPU was really the bottleneck. Indeed; my original plan was to run multiple squid instances on the same machine, but after further thought, it didn't make sense to do it that way. As it happened, the Low Voltage quad cores were the cheaper cpu. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Squid on DualxQuad Core 8GB Rams - Optimization - Performance - Large Scale - IP Spoofing
Adrian Chadd wrote: Out of curiousity, how many Squid servers do you have deployed out there? Adrian We've got 8 in total, currently. I'll preempt you asking for specs: 4 are: Supermicro 1u with Dual Core Xeon 5148 2.33Ghz, 4gb DDR2, 4 x 400gb 7200rpm disks in hardware raid 1+0. These guys proved to be too slow; they start hitting I/O overloads at around 100-150 requests/sec, so I got: Poweredge 1950s with one Quad Core Xeon L5310 1.6Ghz, 8gb FB-DIMM, 4 x 73gb 15krpm SAS drives in hardware raid 1+0. I haven't actually been able to hit the performance limits of these machines yet; I capped out at a kernel limit around 400 requests/sec. Interestingly, these guys only cost $200 more than the poor spec SM machines. The squid cluster is set up to only talk to origin servers, and they don't have a sibling relationship; I found that the 1-2 second overhead for query/fetch from siblings was impeeding performance... and screwing up my graphs with leaps to 2000msec from the usual 10msec response time. In front of the squids, we have lvs + perlbal, depending on the domain being accessed. I should also mention that they're in use as a reverse caching proxy. -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Squid on DualxQuad Core 8GB Rams - Optimization - Performance - Large Scale - IP Spoofing
Michel Santos wrote: but fortunatly true that caching performance is in first place a matter of fast hardware that you can see and not only read common bla-bla I add a well-known mrtg graph of the hit rate of a dual-opteron sitting in front of a 4MB/s ISP POP and I get pretty much more hits as you told at the beginning on larger POPs - so I do not know where you get your squid's 1000 req limit from ... must be from your P-III goody ;) That RRD you attached.. is that 1600 requests per MINUTE, or was something lost in translation? If it is indeed 1600, that seems awfully low, at ~26.667 requests per second. (I'm comparing these numbers to what I achieve with my squid installs -- ~3600 requests/min or 60/sec on average; but load tested up to 18000 requests/min or 300/sec stably). -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Squid on DualxQuad Core 8GB Rams - Optimization - Performance - Large Scale - IP Spoofing
Hi, You will need a 64-bit enabled squid to go higher than 2GB. Yea, I hope i'll be able to replace the CPUs How old are the 2950s? AFAIK, those produced in the last 3-4 years have all been 64bit capable; you should only need to reinstall with a 64bit distro. =] -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] Squid on DualxQuad Core 8GB Rams - Optimization - Performance - Large Scale - IP Spoofing
Personally, I'd consider using aufs over diskd. In my benchmark tests, it outperformed diskd for i/o speed time and time again. --Tony
Re: [squid-users] Squid marks alive siblings as dead.
Chris Robertson wrote: Tony Dodd wrote: Hey All, Been working on rolling out HTCP cache_peer relationships within my squid cluster, but I'm running into a 'small' issue. After starting squid with the cache_peers configured to use htcp, squid sends quite a few UDP packets to the siblings on the htcp port, however, it then marks them as dead. Ideas/help would be appreciated! Below are tcpdumps, and the config I'm utilizing. Cache8 tcpdump from squid startup on cache1 to cache8 being marked as dead: 00:52:41.512445 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 921 00:52:41.807481 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:41.807995 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 346 00:52:41.808106 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 354 00:52:41.808227 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 362 00:52:41.968961 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 322 00:52:42.023668 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.173640 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 299 00:52:42.277635 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.641855 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 485 00:52:42.790272 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:42.795551 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 350 00:52:42.898732 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 292 00:52:43.293162 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 296 00:52:43.627891 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 284 00:52:44.394020 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:44.675878 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 321 00:52:45.241068 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 940 00:52:47.834801 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 349 00:52:48.947938 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 302 00:52:49.048647 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 321 00:52:49.120675 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 567 00:52:49.324587 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 363 00:52:50.250438 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 370 00:52:51.396922 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 318 00:52:51.512461 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 935 00:52:51.927925 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 349 00:53:02.172733 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 771 Cache1 tcpdump from squid startup on cache1 to cache8 being marked as dead: 00:52:41.506998 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 921 00:52:41.802035 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:41.802574 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 346 00:52:41.802686 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 354 00:52:41.802807 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 362 00:52:41.963543 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 322 00:52:42.018232 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.168224 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 299 00:52:42.272199 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.636431 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 485 00:52:42.784852 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:42.790131 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 350 00:52:42.893315 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 292 00:52:43.287743 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 296 00:52:43.622474 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 284 00:52:44.388599 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:44.670459 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 321 00:52:45.235623 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 940 00:52:47.829382 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 349 00:52:48.942519 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 302 00:52:49.043228 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 321 00:52:49.115246 IP cach
Re: [squid-users] Squid marks alive siblings as dead.
Thanks for the suggestion, Mike. I tried adding: icp_query_timeout 5000 dead_peer_timeout 10 seconds To my configs, but this just resulted in it taking longer for the instance to mark the sibling as dead. I'm assuming, however, that icp_query_timeout does absolutely nothing for htcp queries? As a side-note, if I run the same neighbours as ICP, they work correctly; unfortunately, this isn't really a valid option for me, as pretty much everything we cache varies on headers. Thanks! Tony leongmzlist wrote: Try increasing the ICP/HTCP response time. The auto timeout detection doesn't work too well for me, and my peers are on the same switch. mike At 06:01 PM 10/11/2007, Tony Dodd wrote: Hey All, Been working on rolling out HTCP cache_peer relationships within my squid cluster, but I'm running into a 'small' issue. After starting squid with the cache_peers configured to use htcp, squid sends quite a few UDP packets to the siblings on the htcp port, however, it then marks them as dead. Ideas/help would be appreciated! Below are tcpdumps, and the config I'm utilizing. Cache8 tcpdump from squid startup on cache1 to cache8 being marked as dead: 00:52:41.512445 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 921 00:52:41.807481 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:41.807995 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 346 00:52:41.808106 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 354 00:52:41.808227 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 362 00:52:41.968961 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 322 00:52:42.023668 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.173640 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 299 00:52:42.277635 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.641855 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 485 00:52:42.790272 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:42.795551 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 350 00:52:42.898732 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 292 00:52:43.293162 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 296 00:52:43.627891 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 284 00:52:44.394020 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:44.675878 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 321 00:52:45.241068 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 940 00:52:47.834801 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 349 00:52:48.947938 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 302 00:52:49.048647 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 321 00:52:49.120675 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 567 00:52:49.324587 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 363 00:52:50.250438 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 370 00:52:51.396922 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 318 00:52:51.512461 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 935 00:52:51.927925 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 349 00:53:02.172733 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 771 Cache1 tcpdump from squid startup on cache1 to cache8 being marked as dead: 00:52:41.506998 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 921 00:52:41.802035 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:41.802574 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 346 00:52:41.802686 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 354 00:52:41.802807 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 362 00:52:41.963543 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 322 00:52:42.018232 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.168224 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 299 00:52:42.272199 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 789 00:52:42.636431 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 485 00:52:42.784852 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 366 00:52:42.790131 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 350 00:52:42.893315 IP cache1.int.last.fm.4827 > cache8.int.last.fm.4827: UDP, length 292 00:52:43.287743 IP cache1.int.last.fm.4827 > cac
[squid-users] Squid marks alive siblings as dead.
etdb-exchange name=userserve1-83 round-robin cache_peer_domain userserve1-83 userserve.last.fm cache_peer 10.0.20.1 parent 84 0 no-query originserver no-digest no-netdb-exchange name=userserve1-84 round-robin cache_peer_domain userserve1-84 userserve.last.fm cache_peer 10.0.20.2 parent 81 0 no-query originserver no-digest no-netdb-exchange name=userserve2-81 round-robin cache_peer_domain userserve2-81 userserve.last.fm cache_peer 10.0.20.2 parent 82 0 no-query originserver no-digest no-netdb-exchange name=userserve2-82 round-robin cache_peer_domain userserve2-82 userserve.last.fm cache_peer 10.0.20.2 parent 83 0 no-query originserver no-digest no-netdb-exchange name=userserve2-83 round-robin cache_peer_domain userserve2-83 userserve.last.fm cache_peer 10.0.20.2 parent 84 0 no-query originserver no-digest no-netdb-exchange name=userserve2-84 round-robin cache_peer_domain userserve2-84 userserve.last.fm ###Userserve Ends ###ws.audioscrobbler.com & mainsite cache_peer 10.0.0.35 parent 80 0 no-query originserver no-digest no-netdb-exchange name=perlbal1-80 round-robin cache_peer_access perlbal1-80 allow mainsite cache_peer 10.0.0.35 parent 81 0 no-query originserver no-digest no-netdb-exchange name=perlbal1-81 round-robin cache_peer_access perlbal1-81 allow mainsite cache_peer 10.0.0.114 parent 80 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-80 round-robin cache_peer_access perlbal2-80 allow mainsite cache_peer 10.0.0.114 parent 81 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-81 round-robin cache_peer_access perlbal2-81 allow mainsite cache_peer 10.0.0.114 parent 82 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-82 round-robin cache_peer_access perlbal2-82 allow mainsite cache_peer 10.0.0.114 parent 83 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-83 round-robin cache_peer_access perlbal2-83 allow mainsite ###ws.audioscrobbler.com & mainsite Ends snmp_port 3402 acl snmppublic snmp_community public snmp_access allow snmppublic snmp_incoming_address 0.0.0.0 snmp_outgoing_address 255.255.255.255 cache_peer 10.0.12.1 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.2 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.3 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.4 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.5 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.6 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.7 neighbour 8081 4827 round-robin htcp cache_peer 10.0.12.8 neighbour 8081 4827 round-robin htcp Thanks guys -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
