Why is the traffic so different between the ProxySG and Internal Server in a reverse proxy environment?


Article ID: 167624


Updated On:


ProxySG Software - SGOS


There is a problem between the ProxySG and internal server in a reverse proxy environment where the traffic between them is large and the server load is heavy, but in the same network the load of another internal server is low and traffic between the ProxySG and this server is low also.


There are many causes for this problem. Complete the following steps to determine whether a difference between the Last-modified time in the 200OK responses is causing the ProxySG to not cache the object, making the traffic between the ProxySG and the internal web server larger than it should be.

  1. Start a packet capture on the ProxySG.
  2. Try to access the internal Web server and press Ctrl+F5 to refresh the Web page.
  3. Stop the packet capture on the ProxySG.
  4. Open the pcap and find the http request to that web server.
  5. Follow the TCP stream.
  6. Analyze each http get and 200OK response for this Webpage.
  7. Because you pressed Ctrl+F5, the get requests should contain 'Pragma:no-cache' like this:

GET /CMS5_G20306002Resource?info=30419619;res=13106113899671245766770 HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)
Host: finance.xxx.com
Pragma: no-cache        -------->this is a force refresh requst, Ctrl+F5
Connection: Keep-Alive
X-BlueCoat-Via: 17951E30520A1113

  1. Check the Last-Modified value in 200OK response sent by Web server.
    HTTP/1.1 200 OK
    Date: Wed, 02 Nov 2011 05:57:12 GMT
    Server: Apache
    Last-Modified: Tue, 20 Dec 2011 01:57:12 GMT   ---------->OCS send the object again and set the last-modified time tag.
    X-Powered-By: Servlet/2.4 JSP/2.0
    Keep-Alive: timeout=5, max=9936
    Connection: Keep-Alive
    Transfer-Encoding: chunked
  2. If you can find a Last-Modified time in 200OK response that is not the same or similar to other 200OK responses, and this time is near your request send out time, then this problem is related to the Last-Modified time setting in Web Server.
    If the object you requested is a real time object and should not be cached, then this time setting is OK.
    If the object you requested is not a real time object and can be cached, then this time setting should be changed to match the time of the other objects you requested.
  3. To resolve the issue, change the Last-Modified time setting in OCS to match the Last-modified time setting on the ProxySG.