Guest

Cisco 500 Series Content Engines

Understanding Content Engine Transaction Log Analysis

Document ID: 12563

Updated: Jan 31, 2006

   Print

Introduction

This document explains the codes that you see after issuing the show transaction-log entries 255 command on the Cisco Content Engine. These log codes are written in Squid Log Format, and each log can be parsed with any log file parsing tool used on Squid caching logs.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

Readers of this document should be knowledgeable of Squid Log Format. Unlike the common log format, Squid's native log format was designed with Content Engine statistics in mind. This format can be generated not only by Squid, but also by commercial Content Engines, such as ContentFlow, InfoLibria, and NetContent. For more information, refer to Squid Web Proxy Content leavingcisco.com.

Components Used

The information in this document is based on the software and hardware versions below.

  • all releases of Cisco Content Engine Software (formerly Cache Engine Software)

  • all versions of Cisco Content Engine (formerly Cache Engine Software)

Standard Log Codes

This section explains the standard log codes.

TCP_HIT

A valid copy of the requested object was in the Content Engine.

TCP_MISS

The requested object was not in the Content Engine.

TCP_REFRESH_HIT

The object was in the Content Engine, but it was stale (old). An If-Modified-Since request was made, and a 304 Not Modified reply was received.

TCP_REF_FAIL_HIT

The object was in the Content Engine, but it was stale. The request to validate the object failed, so the stale object was returned.

TCP_REFRESH_MISS

The object was in the Content Engine, but it was stale. An If-Modified-Since request was made, and the reply contained new content.

TCP_CLIENT_REFRESH

The client issued a request with the no-cache pragma.

TCP_IMS_HIT

The client issued an If-Modified-Since request, and the object was in the Content Engine and still fresh.

TCP_IMS_MISS

The client issued an If-Modified-Since request for a stale object.

TCP_SWAPFAIL

The object was believed to be in the Content Engine, but it could not be accessed.

TCP_DENIED

Access was denied for this request.

UDP_

This code refers to requests on the Internet Control Protocol (ICP) port (3130).

UDP_HIT

A valid copy of the requested object was in the Content Engine.

UDP_HIT_OBJ

A valid copy of the requested object was in the Content Engine, but the object data was small enough to be sent in the User Datagram Protocol (UDP) reply packet. It saves the Transmission Control Protocol (TCP) request.

UDP_MISS

The requested object was not in the Content Engine.

UDP_DENIED

Access was denied for this request.

UDP_INVALID

An invalid request was received.

UDP_RELOADING

The ICP request was refused because the Content Engine is busy reloading its metadata.

ERR_

This code refers to various types of errors for HTTP requests.

Hierarchy Data Codes

This section explains the hierarchy data codes.

DIRECT

The object has been requested from the origin server.

FIREWALL_IP_DIRECT

The object has been requested from the origin server because the origin host IP address is inside your firewall.

FIRST_PARENT_MISS

The object has been requested from the parent Content Engine with the fastest weighted round-trip time.

FIRST_UP_PARENT

The object has been requested from the first available parent in your list.

LOCAL_IP_DIRECT

The object has been requested from the origin server because the origin host IP address matched your local_ip list.

SIBLING_HIT

The object was requested from a sibling Content Engine, which replied with a UDP_HIT.

NO_DIRECT_FAIL

The object could not be requested because of firewall restrictions, and no parent Content Engines were available.

NO_PARENT_DIRECT

The object was requested from the origin server because no parent Content Engines exist for the URL.

PARENT_HIT

The object was requested from a parent Content Engine, which replied with a UDP_HIT.

SINGLE_PARENT

The object was requested from the only parent Content Engine appropriate for this URL.

SOURCE_FASTEST

The object was requested from the origin server because the source_ping reply arrived first.

PARENT_UDP_HIT_OBJ

The object was received in a UDP_HIT_OBJ reply from a parent Content Engine.

SIBLING_UDP_HIT_OBJ

The object was received in a UDP_HIT_OBJ reply from a sibling Content Engine.

PASSTHROUGH_PARENT

The neighbor or proxy defined in the passthrough_proxy config option was used.

SSL_PARENT_MISS

The neighbor or proxy defined in the ssl_proxy config option was used.

DEFAULT_PARENT

No ICP queries were sent to any parent Content Engines. This parent was chosen because it was marked as default in the config file.

ROUNDROBIN_PARENT

No ICP queries were received from any parent Content Engines. This parent was chosen because it was marked as default in the config file, and it had the lowest Round Robin use count.

CLOSEST_PARENT_MISS

This parent was selected because it included the lowest Round-Trip Time (RTT) measurement to the origin server. This only appears with a query_icmp on option set in the config file.

CLOSEST_DIRECT

The object was fetched directly from the origin server because this Content Engine measured a lower RTT than any of the parent Content Engines.

Related Information

Updated: Jan 31, 2006
Document ID: 12563