<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 2:25 PM, Daniel Coletti <span dir="ltr"><<a href="mailto:dcoletti@xtech.com.ar" target="_blank">dcoletti@xtech.com.ar</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">2013/8/16 Juli <span>Mallett</span> <span dir="ltr"><<a href="mailto:juli@clockworksquid.com" target="_blank"><span>juli</span>@<span>clockworksquid</span>.com</a>></span><br>
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
Hi Daniel,<div><br></div><div>With a lower-latency link like a WAN rather than the Internet, I would expect to see more packets sent between WANProxy instances; WANProxy makes no effort to buffer up data before sending it. Using a slower link, you'll naturally have more buffering occurring and fewer packets sent. There's some things that we could do and should do to avoid sending out gratuitous small packets, and I have some changes to do that, but I haven't tested them enough to check them in yet.</div>
<div><br></div><div>I'm not sure if I understand the difference you're seeing in terms of data reduction / deduplication / compression. Which is giving the greater savings in terms of data transferred, the LAN or the Internet? </div>
</div></blockquote><div><br></div></div><div>The LAN, definitely. the savings are enormous. In a 168Mb file transfer the first time there's 172Mb of traffic between <span>WANProxy</span> instances, the second time it doesn't even reach 2Mb. of data transferring.<br>
</div><div>Transfer time follows a similar pattern, 14 seconds the first download, 4.2 seconds the second one.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div> And what kind of download time are you seeing to the client on each configuration?</div></div></blockquote><div> </div></div><div>The transfer time evaluation is tricky using Internet because the link speed is not constant, well the link is but the links between the routers I jump to reach to the ending point might not. That's why I took a closer look in terms of data/<span>pkts</span> transfer.</div>
<div>Nevertheless the transfer time difference between first and second file transfer is not substantial.</div><div><br></div><div>I dug a bit deeper and I found that what seems to be causing the problem is not the Internet o MTU, but http-proxy I use behind the WANProxy "server". </div>
<div>If I change the setup from this:</div><div class="im"><div>WPclient->(gateway)->//internet//->WPserver+squid->//internet//->webserver<br></div></div><div>to this:</div><div>WPclient->(gateway)->//internet//->WPserver->webserver<br>
</div><div><br></div><div>and download the very same file, it worked like a charm. the second time the file downloaded a LOT faster.</div><div>This time instead of being at some server on the internet I put it in a local webserver that lives in the same server as the ending point of WANProxy.</div>
<div>But I can't figure out why this is causing problems, and huge ones.</div><div><br></div><div>downloading the same file twice using the first setup takes 10 to 20% less than the first time, when using the second setup the file is downloaded 60 to 70% faster at the second time.</div>
<div><br></div><div>If I use the ending http-proxy locally (that is by connecting via ssh to the server and using the local http proxy to download this very same file from the internet) the transfering is very fast. The internet connection of this server is a lot faster that the one I have at the gateway of my LAN.</div>
<div><br></div><div>Could it be that the communication between WANProxy end point with a http proxy creates too many packets between them, and this problem gets somehow translated to the WAProxy starting point "the client"?</div>
<div><br></div><div>I hope I explained myself, if not I'll try to send some "drawings" to explain the problem better. Please excuse my english.</div></div></div></div></blockquote><div><br></div><div>That's very helpful, thank you. If you have packet captures that might be helpful. I would /guess/ that it's possible that your remote proxy server is reencoding the data being downloaded, that is that it's using the chunked encoding and chunking the data differently, or using a deflate encoding (so it's compressing the data) but chunking the data differently, so the data ends up being completely different. Does that make sense or seem at all plausible? Having an HTTP-aware protocol module would help this, but I'm not sure it's even your issue.</div>
<div><br></div><div>Juli. </div></div></div></div>