On Mon, 30 Aug 2010 08:51:34 -0700, Andrei <funactivities_at_gmail.com>
wrote:
> I have a Squid box that caches for about 300 users. This is my first
> Squid installation. Some sites take longer to fetch in the browser,
> but once opened the sites load fairly quickly. For example, if I type
> bbc.com it would take about 3-4 seconds of waiting and staring at the
> blank browser page and then the page/site loads fairly quickly, almost
> instantaneously. It seems like there is a delay somewhere but I can't
> quite figure out where/what would cause this.
>
I've outlines a few little tweaks below. Most of them are just for easing
future upgrades.
Only thing in your settings are likely to be related to such slowness is
the NAT interception ("transparent" flag on http_port).
It could be looping
The browser itself could be the cause of that behaviour. IE6 and Firefox
1.x in particular were known for doing exactly that on web pages with many
objects. The more modern browsers handle it better but can still do that on
Web2.0 pages which self-generate via javascript after fully downloading.
DNS failure is another alternative source for big delays. Use the Squid
info cachemgr page (or command line: "squidclient mgr:info") to check the
DNS service times are in the low milliseconds. If there is a problem check
the individual DNS servers Squid is contacting.
> This is my config file:
>
> acl all src all
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8
> acl localnet src static.ip.address.obfuscated/255.255.255.255
No need for /255.255.255.255. Squid assumes its there for any single or
sequential range of IPs.
> acl localnet src 172.16.0.0/255.255.248.0
That would be 172.16.0.0/12 methinks.
> acl SSL_ports port 443 # https
> acl SSL_ports port 563 # snews
> acl SSL_ports port 873 # rsync
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl Safe_ports port 631 # cups
> acl Safe_ports port 873 # rsync
> acl Safe_ports port 901 # SWAT
> acl purge method PURGE
> acl CONNECT method CONNECT
> http_access allow manager localhost
> http_access deny manager
> http_access allow purge localhost
> http_access deny purge
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost
> acl dsl1 src static.ip.address.obfuscated/255.255.255.255
> http_access allow dsl1
> http_access deny all
> icp_access allow localnet
> icp_access deny all
> http_port 3128 transparent
> hierarchy_stoplist cgi-bin ?
> access_log /var/log/squid/access.log squid
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern (Release|Package(.gz)*)$ 0 20% 2880
The Debian guys report a bug in this. The word should be "Packages" with
an "s".
> refresh_pattern . 0 20% 4320
> acl shoutcast rep_header X-HTTP09-First-Line ^ICY\s[0-9]
> upgrade_http0.9 deny shoutcast
> acl apache rep_header Server ^Apache
> broken_vary_encoding allow apache
> extension_methods REPORT MERGE MKACTIVITY CHECKOUT
> cache_mgr myname_at_domain.com
> httpd_suppress_version_string on
> httpd_accel_no_pmtu_disc off
Why? something broken on your network?
Also, this is a setting for reverse-proxies. I don't think it's actually
having any affect for you.
NP: Path-MTU discovery is the lifeblood of working high-speed IP
connectivity. Please track down and report to the relevant network admin
every instance of MTU brokenness you encounter. As of April this year 5% of
the Internet is inaccessible to end users due to these problems.
> hosts_file /etc/hosts
> coredump_dir /var/spool/squid
> cache_dir ufs /var/spool/squid 2000 32 512
> cache_store_log none
> cache_mem 256 MB
> maximum_object_size 1024 KB
> maximum_object_size_in_memory 64 KB
> cache_replacement_policy lru
> memory_replacement_policy lru
Received on Tue Aug 31 2010 - 00:24:15 MDT
This archive was generated by hypermail 2.2.0 : Tue Aug 31 2010 - 12:00:03 MDT