Squid_ The Definitive Guide - Duane Wessels [209]
Syntax
high_page_fault_warning number
Default
high_page_fault_warning 0
Example
high_page_fault_warning 5
Related
high_response_time_warning, high_memory_warning
Name
high_memory_warning
Synopsis
If you provide a nonzero value for this directive, Squid periodically checks process size. A large process size can lead to page faults and a significant performance degradation. Squid uses either mstats( ), mallinfo( ), or sbrk( ) to get the process size. If it exceeds the given threshold, Squid prints a warning message in cache.log.
Syntax
high_memory_warning size-specification
Default
high_memory_warning 0
Example
high_memory_warning 400 MB
Related
high_response_time_warning, high_page_fault_warning
Name
ie_refresh
Synopsis
In Section 9.2, I explained that Internet Explorer versions prior to 5.5 SP1 have a bug that make it unable to force a validation of cached responses when using HTTP interception. This directive provides a partial workaround for the bug. When enabled, Squid pretends that the request contains a no-cache directive. Thus, Squid always forwards these requests on to the origin server or a neighbor.
Note this affects only requests that meet the following requirements:
The User-Agent header indicates Internet Explorer Version 3, 4, 5.0, or 5.01.
The If-Modified-Since header is present.
The request contains a partial URI because it was intercepted (see Chapter 9) or Squid is a surrogate (see Chapter 15).
Squid versions prior to 2.5.STABLE3 contain a bug related to this feature. Although Squid behaves as though the client's request contains a no-cache directive, it doesn't add that directive to the outgoing request. This is a problem if you have one or more neighbor caches. Because the request received by the neighbor doesn't contain a no-cache directive, it may decide to return a cache hit, rather than forward it on to the origin server.
Later versions include the no-cache directive so that such requests should always reach the origin server.
Syntax
ie_refresh on|off
Default
ie_refresh off
Example
ie_refresh on
Name
vary_ignore_expire
Synopsis
When certain HTTP/1.1 origin servers receive an HTTP/1.0 request (e.g., from Squid), and the response contains a Vary header, they also add an Expires header set to the current time. This is to prevent HTTP/1.0 caches, which may not understand the Vary header, from incorrectly reusing a cached response.
Squid understands and implements the Vary header but still sends the string "HTTP/1.0" in its requests. You'll need to enable this directive if you want to get cache hits from responses with Vary and with Expires equal to Date. This directive is somewhat dangerous because the origin server may have its own reasons (other than maintaining backward compatibility) for setting the Expires header.
Syntax
vary_ignore_expire on|off
Default
vary_ignore_expire off
Example
vary_ignore_expire on
Name
sleep_after_fork
Synopsis
Squid uses the fork( ) system call to spawn helper processes, such as redirectors, authenticators, and DNS resolvers. On some systems, a rapid sequence of fork( ) calls consumes all available real and virtual memory. Thus, a fork( ) call may fail with an "out of memory" error. Note that this isn't necessarily a fatal error. Squid continues running as long as at least 50% of helper processes are successfully started.
To alleviate this problem, you can instruct Squid to sleep for a small amount of time after each fork( ) call. This gives the recently forked process time to complete its exec( ) call and free up the memory.
Don't set this value too high, especially if you have a large number of helper processes. Squid doesn't service any client requests until all helpers have been started.
Syntax
sleep_after_fork microseconds
Default
sleep_after_fork