WA 调试关键信息列表,X-PvInfo代码详解
发布: 2008-3-31 17:18 | 作者: metoo | 来源: 应用交付网络专业站点
WA 调试关键信息列表
在调试WA的时候，一个重要的信息观察请求和回应是否通过了WA就是X-PvInfo的Header。所有通过WA处理的服务器返回信息WA都会插入一个X-PvInfo的Header在返回信息中。一个X-PvInfo的header如下：
X-PvInfo: [S10101.C5025.PL.A15957.RA0.G3F6B.U896F2B1E]
这个Code是使用“.”符号进行分割，每一个段都用一个字母作为开头。
S Code
这个Code标识回应数据包是被Proxy或者是从WA Cache进行返回。以及为什么请求被Proxy到后台服务器。
S0 = 回应是由一个未知的源返回的。
表明WA不能确定返回内容是Cache的或者是Proxy的。
S11101=回应是从WA的HotCache，也就是TMM里面的RamCache返回的。
这个是最快的一种响应。
S10101 = 回应是从WA 的SmartCache中返回
这个是第二快的一种响应。
S10102 = 回应是从WA的硬盘缓存中返回的
这个是第三快的一种响应。
S10201 = 请求被Proxy到后台服务器，因为是一个新的请求
对该对象的请求不在当前的Cache系统内，对于该对象的回应将被WA Cache用于将来的请求。
S10202 = 请求被Proxy到后台服务器，因为WA的本地缓存已经过期
在图形界面中可以配置每个对象可以在WA上缓存多长的时间。如果这个对象在WA上保存的时间已经超出了定义的时间，WA就会把请求转发到后台的服务器做一个刷新的动作，刷新后返回的内容将被缓存，用于将来的请求。
S10203 =请求被Proxy到后台，因为在策略配置中的定义
如果在WA 该对象的策略中，定义了”Always Proxy”，则这个请求将会直接转发到后台服务器，并且返回的内容不会被保存在Cache中。
S10204 = 请求被转发到后台，因为在请求中的要求
WA 当前不支持一些厂商自定义的HTTP methods（比如OPTIONS）和一些Web Service Methods(SOAP)，结构就是这些请求都会被转发到后台服务器。另外，在WA的Policy定义中可以配置WA忽略掉请求中的“no-Cache”Header。或者遵从请求中的”no-Cache” header。强制WA将请求Proxy给后台服务器。返回的内容将不会保存在Cache中。
S10205 = 请求被转发到后台因为已经缓存的内容被invalidate了
在WA上的缓存的内容可以通过图形界面被手工的invalidate。或者是匹配一个invalidation的规则，或者是通过ESI协议通知WA进行invalidate。因为这是一个对当前可Cache内容的invalidate，返回的内容将被缓存在Cache，用于将来的请求。
S10206 =请求被转发到后台因为返回内容需要在原始Web服务器上进行认证
在一些情况下，内容被NTLM保护，在图形界面的“Responses Cached”设置中，可以指定是否对NTLM 保护的内容进行缓存。
S10301 = 响应被Proxy因为对象被认为尺寸过大
非常大的多媒体对象是不能被进一步优化的。他们都是非常大的文件，并且已经压缩过或者太大以至于不能Cache。可以在WA上配置可以认识这些文件并且Bypass这些内容。默认情况下，这个功能在pvsystem.conf配置文件中关闭了这个功能。
C Code
第二个部分是C code。这个是WA上的Policy号。当一个WA上存在多个Application的时候，这个Code用于鉴别WA使用了那一个Policy。C code也表明了在硬盘缓存中的目录名。
A Code
第三个部分是A code。标识了在一个Application中使用了那一条具体的policy中的node。在WA的Policy配置界面中，当你把鼠标移动到Policy中某一个具体的node上面的时候，就会在右侧弹出一个小窗口，表明当前node节点的号码。因此，A code可以帮助确定请求是否命中了您所配置的策略。这个在如果您发现你所定义的策略没有发生作用的时候可以非常有效的确定问题点。A code也是在硬盘缓存中目录名的一部分。
R code
第四个部分是R code。主要用来标识WA是否使用了Response match。A0表示WA没有启用response match。Response match启用的主要原因是请求的URL路径中的文件扩展名和响应的MIME类型不匹配的情况（文件扩展名的定义在/config/wa/globalfragment.conf文件中定义），通常情况下最容易发生在用户请求一个jsp之类的动态页面，但返回的内容是一个图片的时候。
G Code
The fifth field is the G code. This value is an Application Sign number. The G code, when converted from hexadecimal to decimal, is part of the path where cached objects are stored on disk. The Application Sign is changed when edits to a policy result in a substantial enough change (generally content variation related changes) that revalidation of existing cached objects is difficult. Changing to a new Application Sign changes to a new cache subdirectory as well, so it is similar to wiping out the disk cache and starting fresh, except that disk space is not freed and must be garbage collected by the hds_pruner process.
U Code
第六个部分是U code，这是一个16进制的缓存ID号，U code也是对象在磁盘缓存中的路径之一。
怎样在磁盘缓存中根据X-PvInfo code找到一个特定的对象
How to find cached objects using the X-PvInfo code
在上例中，X-PvInfo code 是
[S10101.C5025.PL.A15957.RA0.G3F6B.U896F2B1E],则这个对象在磁盘缓存的路径中是：
/var/wa/hds/cache/5025.5028/15957.16235/_1e/_896f2b.piv
5025 is the organization number and 5028 is the release platform number. The header does not give you the release platform number, but by looking in the cache directory and doing ls -lrt, you can usually see which one has a more recent timestamp.
15957 is the application node ID matched. 16235 is the application sign number converted to decimal (Windows Calculator in View->Scientific mode is useful for this).
The cache ID is an 8 digit hex number. The last two hex digits provide the parent directory and the first six hex digits are used for the cached object filename. The parent directory and cached object filenames are prepended with an underscore (_).
The cached object disk location will be the same across all the accelerators in the management UI since they all have the same application configuration.
在调试WA的时候，一个重要的信息观察请求和回应是否通过了WA就是X-PvInfo的Header。所有通过WA处理的服务器返回信息WA都会插入一个X-PvInfo的Header在返回信息中。一个X-PvInfo的header如下：
X-PvInfo: [S10101.C5025.PL.A15957.RA0.G3F6B.U896F2B1E]
这个Code是使用“.”符号进行分割，每一个段都用一个字母作为开头。
S Code
这个Code标识回应数据包是被Proxy或者是从WA Cache进行返回。以及为什么请求被Proxy到后台服务器。
S0 = 回应是由一个未知的源返回的。
表明WA不能确定返回内容是Cache的或者是Proxy的。
S11101=回应是从WA的HotCache，也就是TMM里面的RamCache返回的。
这个是最快的一种响应。
S10101 = 回应是从WA 的SmartCache中返回
这个是第二快的一种响应。
S10102 = 回应是从WA的硬盘缓存中返回的
这个是第三快的一种响应。
S10201 = 请求被Proxy到后台服务器，因为是一个新的请求
对该对象的请求不在当前的Cache系统内，对于该对象的回应将被WA Cache用于将来的请求。
S10202 = 请求被Proxy到后台服务器，因为WA的本地缓存已经过期
在图形界面中可以配置每个对象可以在WA上缓存多长的时间。如果这个对象在WA上保存的时间已经超出了定义的时间，WA就会把请求转发到后台的服务器做一个刷新的动作，刷新后返回的内容将被缓存，用于将来的请求。
S10203 =请求被Proxy到后台，因为在策略配置中的定义
如果在WA 该对象的策略中，定义了”Always Proxy”，则这个请求将会直接转发到后台服务器，并且返回的内容不会被保存在Cache中。
S10204 = 请求被转发到后台，因为在请求中的要求
WA 当前不支持一些厂商自定义的HTTP methods（比如OPTIONS）和一些Web Service Methods(SOAP)，结构就是这些请求都会被转发到后台服务器。另外，在WA的Policy定义中可以配置WA忽略掉请求中的“no-Cache”Header。或者遵从请求中的”no-Cache” header。强制WA将请求Proxy给后台服务器。返回的内容将不会保存在Cache中。
S10205 = 请求被转发到后台因为已经缓存的内容被invalidate了
在WA上的缓存的内容可以通过图形界面被手工的invalidate。或者是匹配一个invalidation的规则，或者是通过ESI协议通知WA进行invalidate。因为这是一个对当前可Cache内容的invalidate，返回的内容将被缓存在Cache，用于将来的请求。
S10206 =请求被转发到后台因为返回内容需要在原始Web服务器上进行认证
在一些情况下，内容被NTLM保护，在图形界面的“Responses Cached”设置中，可以指定是否对NTLM 保护的内容进行缓存。
S10301 = 响应被Proxy因为对象被认为尺寸过大
非常大的多媒体对象是不能被进一步优化的。他们都是非常大的文件，并且已经压缩过或者太大以至于不能Cache。可以在WA上配置可以认识这些文件并且Bypass这些内容。默认情况下，这个功能在pvsystem.conf配置文件中关闭了这个功能。
C Code
第二个部分是C code。这个是WA上的Policy号。当一个WA上存在多个Application的时候，这个Code用于鉴别WA使用了那一个Policy。C code也表明了在硬盘缓存中的目录名。
A Code
第三个部分是A code。标识了在一个Application中使用了那一条具体的policy中的node。在WA的Policy配置界面中，当你把鼠标移动到Policy中某一个具体的node上面的时候，就会在右侧弹出一个小窗口，表明当前node节点的号码。因此，A code可以帮助确定请求是否命中了您所配置的策略。这个在如果您发现你所定义的策略没有发生作用的时候可以非常有效的确定问题点。A code也是在硬盘缓存中目录名的一部分。
R code
第四个部分是R code。主要用来标识WA是否使用了Response match。A0表示WA没有启用response match。Response match启用的主要原因是请求的URL路径中的文件扩展名和响应的MIME类型不匹配的情况（文件扩展名的定义在/config/wa/globalfragment.conf文件中定义），通常情况下最容易发生在用户请求一个jsp之类的动态页面，但返回的内容是一个图片的时候。
G Code
The fifth field is the G code. This value is an Application Sign number. The G code, when converted from hexadecimal to decimal, is part of the path where cached objects are stored on disk. The Application Sign is changed when edits to a policy result in a substantial enough change (generally content variation related changes) that revalidation of existing cached objects is difficult. Changing to a new Application Sign changes to a new cache subdirectory as well, so it is similar to wiping out the disk cache and starting fresh, except that disk space is not freed and must be garbage collected by the hds_pruner process.
U Code
第六个部分是U code，这是一个16进制的缓存ID号，U code也是对象在磁盘缓存中的路径之一。
怎样在磁盘缓存中根据X-PvInfo code找到一个特定的对象
How to find cached objects using the X-PvInfo code
在上例中，X-PvInfo code 是
[S10101.C5025.PL.A15957.RA0.G3F6B.U896F2B1E],则这个对象在磁盘缓存的路径中是：
/var/wa/hds/cache/5025.5028/15957.16235/_1e/_896f2b.piv
5025 is the organization number and 5028 is the release platform number. The header does not give you the release platform number, but by looking in the cache directory and doing ls -lrt, you can usually see which one has a more recent timestamp.
15957 is the application node ID matched. 16235 is the application sign number converted to decimal (Windows Calculator in View->Scientific mode is useful for this).
The cache ID is an 8 digit hex number. The last two hex digits provide the parent directory and the first six hex digits are used for the cached object filename. The parent directory and cached object filenames are prepended with an underscore (_).
The cached object disk location will be the same across all the accelerators in the management UI since they all have the same application configuration.
[S10413.C0.A0.R0.G0].[OT/plaintext.OG/documents]