Re: Preposition HTTP Content

paul_murphy · ‎05-09-2011

Hello all,

Can anyone tell me if the WAAS modules used in 2811s have a homogenous cache - in that if a file is prepositioned using the WAAS services manager via CIFS it will be recognised as the same file and offered from the cache if subsequently accessed using HTTP?

I guess my question is "can I preposition content that is to be accessed via http using the manager"?

Thanks,

Paul

Michael Korenbaum · ‎05-10-2011

Paul,

Yes, if you preposition files via CIFS and then access them via HTTP you will receive a DRE cache hit. Traffic accelerated via the CIFS AO utilizes DRE as well. The file will be cached in the CIFS object cache, but also the byte level DRE cache.

Regards,

Mike Korenbaum

Cisco Data Center PDI Help Desk

http://www.cisco.com/go/pdihelpdesk

paul_murphy · ‎05-10-2011

Thanks Mike,

Perhaps my approach isn't right. As a test, I downloaded as 128MB file to a local server. Then I used preposition to push this file out to a WAAS module at a remote site.

Then from a device at the remote site, I tried a download of the same file from the same origin server (the WAAS module sits in between). I didn't get a hit on DRE - the connection showed 00.0% optimised.

From the same device, if I copy the file using CIFS from the server it was prepositioned from, I get a 99.x% hit on the DRE and CIFS cache.

So the preposition is definitely working for CIFS, but I don't get a hit with http.

In another test, if from the remote device I do a wget of a file from an origin server, then repeat the process, I get 99.x% optimised - which shows the DRE caching is working otherwise - from non-prepositioned sources.

Is there another step I need to take to get prepositioned content recognised when using http?

Cheers,

Paul

Michael Korenbaum · ‎05-17-2011

Paul,

This should populate the DRE cache when you do the preposition job. When you did the download was it HTTP or HTTPS? Is it possible when you did the download with HTTP that DRE cache was over written by other data, or is this a controlled test environment?

What version of WAAS are you using?

Regards,

Mike

paul_murphy · ‎05-17-2011

It isn't a controlled environment, but it is a small site with minimal activity - ie the cache disk is 41% utilised.

I used exactly the same link to download the file initially as I did to test the cache, so didn't switch to https. Also, I tested the CIFS transfer after the http transfer and the content came from the cache - so it definitely didn't get overwritten.

Thinking about it, DRE must rely on a peer WAAS device having observed the same data already? Ie A WAAS device nearest the origin server checks the incoming data and tells the "distant" WAAS device to not transfer but reconstruct from the DRE database if the data has been seen already?

Is perhaps my problem that I am missing prepositioning to another WAAS across the WAN from the distant WAAS in the direction of the incoming traffic?

Cheers,

Paul

Michael Korenbaum · ‎05-17-2011

Paul,

When you do the preposition and then do the HTTP download does this traffic traverse the same two WAEs? Or do you have multiple WAEs at the branch or server side?

Yes, the way you described a DRE cache hit is accurate. Both WAEs (client and server side) have to have seen this data before to have built their synchronized DRE cache . So, when the client requests file X, the server side WAE will encode the data and send DRE signatures representative of the data in file X over the WAN, the client side WAE will decode the DRE signatures and send the data on to the client. If the client WAE does not have a match for the DRE signature the server side WAE sent, then it will inform the server side WAE it doesn't have a match for this signature (DRE NACK) and to send the data.

Below is a sample show stat con output from my client side WAE of a HTTP download of a file I previously prepositioned in my lab, you will see there was 99% DRE hit, and in the DRE details 0 DRE NACKs (meaning the DRE cache between the two peer WAEs are in sync).

pdi-574-rtp#sh stat con closed conn-id 280083

Connection Id: 280083

Peer Id: 00:21:5e:75:a6:5c

Connection Type: EXTERNAL CLIENT

Start Time: Tue May 17 20:34:01 2011

End Time: Tue May 17 20:36:14 2011

Source IP Address: 14.110.3.117

Source Port Number: 59706

Destination IP Address: 14.110.3.98

Destination Port Number: 80

Application Name: Web

Classifier Name: HTTP

Map Name: basic

Directed Mode: FALSE

Preposition Flow: FALSE

Policy Details:

Configured: TCP_OPTIMIZE + DRE + LZ

Derived: TCP_OPTIMIZE + DRE + LZ

Peer: TCP_OPTIMIZE + DRE + LZ

Negotiated: TCP_OPTIMIZE + DRE + LZ

Applied: TCP_OPTIMIZE + DRE + LZ

Accelerator Details:

Configured: HTTP

Derived: HTTP

Applied: HTTP

Hist: HTTP

Original Optimized

-------------------- --------------------

Bytes Read: 616 111039

Bytes Written: 24451412 6287

Total Reduction Ratio: 99.520%

HTTP : 280083

Time Statistics were Last Reset/Cleared: Tue May 17

20:34:01 2011

Total Bytes Read: 616

24451412

Total Bytes Written: 616

24451412

Total Bytes Buffered: 0

0

Total Internal Bytes Read: 4

Total Internal Bytes Written: 4

Bit Flags for I/O state: 0

Internal object pointer: 139700008

Fast connections: 0

DRE : 280083

Conn-ID: 280083 14.110.3.117:59706 -- 14.110.3.98:80 Peer No: 2 Status: Closed

------------------------------------------------------------------------------

Open at 05/17/2011 20:34:01, Close at 05/17/2011 20:36:14, Duration: 133 secs

Encode:

Overall: msg: 2, in: 620 B, out: 477 B, ratio: 23.06%

DRE: msg: 1, in: 0 B, out: 9 B, ratio: 0.00%

DRE Bypass: msg: 1, in: 620 B

LZ: msg: 1, in: 684 B, out: 468 B, ratio: 31.58%

LZ Bypass: msg: 1, in: 0 B

Avg latency: 0.143 ms Delayed msg: 0

Encode th-put: 2109 KB/s

Message size distribution:

0-1K=100% 1K-5K=0% 5K-15K=0% 15K-25K=0% 25K-40K=0% >40K=0%

Decode:

Overall: msg: 382, in: 104 KB, out: 23878 KB, ratio: 99.56%

DRE: msg: 382, in: 214 KB, out: 23878 KB, ratio: 99.10%

DRE Bypass: msg: 1, in: 248 B

LZ: msg: 80, in: 69748 B, out: 178 KB, ratio: 61.83%

LZ Bypass: msg: 302, in: 37369 B

Avg latency: 0.721 ms

Decode th-put: 86685 KB/s

Message size distribution:

0-1K=0% 1K-5K=1% 5K-15K=4% 15K-25K=10% 25K-40K=14% >40K=68%

Connection details:

Chunks: encoded 0, decoded 3627, anchor(forced) 0(0)

Total number of processed messges: 384

num_used_block per msg: 0.492188

Ack: msg 382, size 1950 B

Encode bypass due to:

skipped frame header: messages: 1, size: 620 B

Nacks: total 0 ----------------------------------------------------------------------> Non-zero and incrementing indicates DRE cache out of sync

R-tx: total 0

Encode LZ latency: 0.069 ms per msg

Decode LZ latency: 0.011 ms per msg

Aggregation encode: Retransmissions: 0

level 0: chunks: 0 hits: 0 miss: 0

level 1: chunks: 0 hits: 0 miss: 0

level 2: chunks: 0 hits: 0 miss: 0

level 3: chunks: 0 hits: 0 miss: 0

Aggregation decode: Collisions: 0

level 0: chunks: 0 hits: 91689 miss: 0

level 1: chunks: 0 hits: 0 miss: 0

level 2: chunks: 0 hits: 0 miss: 0

level 3: chunks: 0 hits: 0 miss: 0

Aggregation stack memory usage: Sender: 0 B Receiver: 0 B

Noise filter: Chunks: 0, Bytes: 0 B

paul_murphy · ‎05-18-2011

"When you do the preposition and then do the HTTP download does this traffic traverse the same two WAEs? Or do you have multiple WAEs at the branch or server side?"

I think this is the right question, I am testing again making sure the pairs in the path both definitely get the prepositioned content. My preposition task is "0.00" complete after two hours for a device that is on a 10Gb link from the server, so I suspect something is going wrong