How do you create a raw disk for the cache if all your disks have mounted file systems?
How do disk I/O errors affect the cache and what does Traffic Server do when a cache disk fails?
If a client disconnects during the time that Traffic Server is downloading a large object, is any of the object saved in the cache?
In Squid- and Netscape-format log files, what do the cache result codes mean?
What is recorded by the cqtx field in a custom log file?
Does Traffic Server refresh entries in its host database after a certain period of time if they have not been used?
Can you improve the look of your custom response pages by using images, animated .gifs, and Java applets?
Can Traffic Server run in forward proxy and reverse proxy modes at the same time?
How do I interpret the Via: header code?
Create a large file on filesystem (with dd(1)) and mount it as loopback device. This is accomplished with losetup(8) on Linux, lofiadm(1m) on Solaris and Illumos, and mdconfig(8) on FreeBSD.
If a disk drive fails five successive I/O operations, then Traffic Server considers the drive inaccessible and removes the entire disk from the cache. Normal cache operations continue for all other Traffic Server disk drives.
When a client disconnects during an HTTP operation, Traffic Server can continue to download the object from the origin server, using the background fill feature. It will continue downloading based on the proxy.config.http.background_fill_active_timeout and proxy.config.http.background_fill_completed_threshold settings.
This is described in detail in the Logging Cache Results documentation.
In forward proxy mode, the cqtx field records the complete client request in the log file (for example, GET http://www.company.com HTTP/1.0).
In reverse proxy mode, the cqtx field records the hostname or IP address of the origin server because Traffic Server first remaps the request as per map rules in the remap.config file.
By default, the Traffic Server host database observes the time-to-live (ttl) values set by name servers. You can reconfigure Traffic Server to ignore the ttl set by name servers and use a specific Traffic Server setting instead. Alternatively, you can configure Traffic Server to compare the ttl value set by the name server with the ttl value set by Traffic Server, and then use either the lower or the higher value.
Refer to proxy.config.hostdb.ttl_mode for more info.
No, because Traffic Server can only respond to clients with a single text or HTML document. As a workaround, however, you can provide references on your custom response pages to images, animated .gifs, Java applets, or objects other than text which are located on a web server. Add links in the body_factory template files in the same way you would for any image in an HTML document (i.e., with the full URL in the SRC attribute).
Yes. When you enable reverse proxy mode, Traffic Server remaps incoming requests according to the map rules in remap.config. All other requests that do not match a map rule are served in forward proxy mode.
If you want to run in reverse proxy only mode (wherein Traffic Server does not serve requests that fail to match a map rule), then you must set the configuration variable proxy.config.url_remap.remap_required to 1 in records.config.
Please refer to the Forward Proxy documentation.
The Via header string can be decoded with the Via Decoder Ring.
The Via header is an optional HTTP header added by Traffic Server and other HTTP proxies. If a request goes through multiple proxies, each one appends its Via header content to the end of the existing Via header. Via header content is for general information and diagnostic use only and should not be used as a programmatic interface to Traffic Server. The header is cached by each intermediary with the object as received from its downstream node. Thus, the last node in the list to report a cache hit is the end of the transaction for that specific request. Nodes reported earlier were from a previous transaction.
Traffic Server currently does not handle Expect: request headers according to the HTTP/1.1 spec.
Traffic Server updates the throughput statistic after it has transferred an entire object. For larger files, the byte count increases sharply at the end of a transfer. The complete number of bytes transferred is attributed to the last 10-second interval, although it can take several minutes to transfer the object. This inaccuracy is more noticeable with a light load. A heavier load yields a more accurate statistic.
If the Traffic Server bin directory is not in your path, then prepend the Traffic Control commands with ./ (for example, ./traffic_ctl -h).
As part of the initial system preparation, you must synchronize the clocks on all nodes in your cluster. Minor time differences do not cause problems, but differences of more than a few minutes can affect Traffic Server operation.
You should run a clock synchronization daemon such as xntpd. To obtain the latest version of xntpd, go to http://www.eecis.udel.edu/~ntp/.
This document resulted from a POST operation and has expired from the cache. You can repost the form data to recreate the document by pressing the Reload button.
This is a Web browser issue and not a problem specific to (or caused by) Traffic Server. Because Web browsers maintain a separate local cache in memory and/or disk on the client system, messages about documents that have expired from cache refer to the browser's local cache and not to the Traffic Server cache. There is no Traffic Server message or condition that can cause such messages to appear in a web browser.
Check if the server can resolve DNS lookups by issuing the nslookup command (for example, nslookup www.myhost.com).
Check if the resolv.conf(5) file contains valid IP addresses for your DNS servers.
On some systems, if the resolv.conf(5) file is unreadable or has no name server entry, then the operating system uses localhost as a name server. Traffic Server, however, does not use this convention. If you want to use localhost as a name server, then you must add a name server entry for 127.0.0.1 or 0.0.0.0 in the resolv.conf(5) file.
Check that the Traffic Server user account has permission to read the resolv.conf(5) file. If it does not, then change the file permissions to rw-r--r-- (644).
A requested object was larger than the maximum size allowed in the Traffic Server cache, so Traffic Server provided proxy service for the oversized object but did not cache it. To set the object size limit for the cache, modify the proxy.config.cache.max_doc_size variable in the records.config file. If you do not want to limit the size of objects in the cache, then set the document size to 0 (zero).
These error messages indicate that a browser is sending HTTP requests to one of the Traffic Server cluster ports, either rsport (default port 8088) or mcport (default port 8089). Traffic Server discards these requests. This error does not cause any Traffic Server problems. The misconfigured browser must be reconfigured to use the correct proxy port. Traffic Server clusters should ideally be configured to use a separate network interface and cluster on a private subnet, so that client machines have no access to the cluster ports.
Traffic Server only writes event log files when there is information to record. If Traffic Server is idle, then it's possible that no log files exist.
Make sure you're looking in the correct directory. By default, Traffic Server creates log files in the logs directory. This can be modified by changing proxy.config.log.logfile_dir in records.config.
Check that the log directory has read/write permissions for the Traffic Server user account. If the log directory does not have the correct permissions, then the traffic_server process will be unable to open or create log files.
Check that logging is enabled by checking the value of the proxy.config.log.logging_enabled variable in records.config.
Check that a log format is enabled. In records.config, select the standard or custom format by editing variables in the Logging Config section.
By default, Traffic Server supports 8000 network connections. Half of this number is allocated for client connections and the remaining half is for origin server connections. A connection throttle event occurs when either client or origin server connections reach 90% of half the configured total limit (3600 by default). When a connection throttle event occurs, Traffic Server continues processing all existing connections but will not accept new client connection requests until the connection count falls below the limit.
Too many client requests (enough to exceed your configured maximum connections) all reach Traffic Server at the same time. Such events are typically transient and require no corrective action if your connection limits are already configured appropriately for your Traffic Server and origin resources.
Client requests are arriving at a rate faster than that which Traffic Server can service them. This may indicate network problems between Traffic Server and origin servers or that Traffic Server may require more memory, CPU, cache disks, or other resources to handle the client load.
If necessary, you can adjust the maximum number of connections supported by Traffic Server by editing proxy.config.net.connections_throttle in records.config.
Do not increase the connection throttle limit unless the system has adequate memory to handle the client connections required. A system with limited RAM might need a throttle limit lower than the default value. Do not set this variable below the minimum value of 100.
Under heavy load, the Linux kernel can run out of RAM. This low memory condition can cause slow performance and a variety of other system problems. In fact, RAM exhaustion can occur even if the system has plenty of free swap space.
kernel: eth0: can't fill rx buffer (force 0)!
To avoid memory exhaustion, add more RAM to the system or reduce the load on Traffic Server.
<config_dir> is the location of the config files to be validated.
By default, Traffic Server will timeout after 30 seconds when contacting origin servers. If you cannot avoid such timeouts by otherwise addressing the performance on your origin servers, you may adjust the origin connection timeout in Traffic Server by changing proxy.config.http.connect_attempts_timeout in records.config to a larger value.