wanproxy performance

Fri Dec 10 20:48:12 PST 2010

Hi Uttam,

Deflate (zlib) is fine for low entropy traffic but yields, as you suggest,
no improvement at the historical scale or between connections.

The xcodec damage is not too hard to correct now that I have enhanced the
infrastructure in the last week, but I may need to wait until the 17th or
thereabouts to make the change.  Hopefully the inconvenience is not great.

In trunk you can run with a codec of None and a compressor of zlib (see
wanproxy.conf in trunk) if you want to test zlib and the proxy
infrastructure for now.

(Forgive the terseness I am replying by phone on a touchscreen.)

Juli.
 On Dec 10, 2010 7:36 PM, "Uttam Singh" <us at iptvlabs.com> wrote:
> Hi Juli,
>
> Here are some additional test results:
>
> 1. I have repeated some tests in a flat network (no WAN) and the
> original reported problems still remain. This was done to eliminate
> any issues with NAT/Firewall etc. on WAN router.
>
> 2. The results in this flat network (switched ethernet) are consistent
> with the results seen in the WAN setup. Wanproxy-Trunk doesn't seem to
> work with anything. wanproxy-0.6.2 fares a little better with some
> tests. However, iperf (windows version 1.7.0) between 2 stations with
> wanproxy-0.6.2 as well as wanproxy-trunk fails everytime.
>
> 3. If I set ".._codec None" - tests complete successfully with both
> wanproxy-trunk and wanproxy-0.6.2. So the problems seem to be Xcodec
> related.
>
> I have also written a quick and dirty tcp-tunnel which essentially
> does wanproxy without compression. I am thinking of plugging in zlib
> to get some baseline results. I noticed that you have started
> integrating zlib in wanproxy-trunk. Can you please share your thoughts
> on how much better Xcodec performance is as compared to zlib?
>
> My thoughts are that zlib performance improvements will be marginal in
> TCP WAN traffic scenario as compared to a history based compression
> algorithm (which is what I think Xcodec is).
>
> thanks,
>
> -Uttam
>
> On Sun, Dec 5, 2010 at 11:57 AM, Mallett, Juli <juli at clockworksquid.com>
wrote:
>> Hi Uttam,
>>
>> I must have unintentionally broken something recently, thanks for your
>> feedback, I'll look in to that and come back to your problem.  Thanks
>> for your patience.
>>
>> Thanks,
>> Juli.
>>
>> On Sun, Dec 5, 2010 at 09:39, Uttam Singh <us at iptvlabs.com> wrote:
>>> Hi Juli
>>>
>>> Thanks for your help so far.
>>>
>>> wanproxy from svn/trunk seems to be broken. Please see other details
below.
>>>
>>> A real WAN connection is being used in my tests. I have a VDSL2
>>> 100Mb/100Mb connection between client and server site. I am modifying
>>> DSL settings to force WAN connection speed at 5Mb/5Mb for these tests.
>>>
>>> I have checked out and built wanproxy from svn/trunk and file
>>> transfers (upload or, download) don't work now. I did a gmake clean
>>> and a top level build of everything under wanproxy.
>>>
>>> I see file transfer start but it hangs pretty much after first dozen
>>> packets are sent between the 2 proxies. If I revert back to the 0.6.2
>>> wanproxy build, without changing any other variable, things work like
>>> before.
>>>
>>> Tack Results:
>>>
>>> 1. sample test file (~10MB binary file)
>>>
>>> %tack -TQc ~/test1.bin
>>> 1291591407.945118 [/codec_timer] INFO: 169 timer samples.
>>> 1291591407.945336 [/codec_timer] INFO: 4804377 total runtime.
>>> 1291591407.945406 [/codec_timer] INFO: 28428 mean microseconds/call.
>>>
>>> 2. sample text file (~10MB text file)
>>>
>>> %tack -TQc ~/test1.txt
>>> 1291592129.859450 [/codec_timer] INFO: 159 timer samples.
>>> 1291592129.859670 [/codec_timer] INFO: 1353549 total runtime.
>>> 1291592129.859812 [/codec_timer] INFO: 8512 mean microseconds/call.
>>>
>>> Please let me know if you need any debug output from wanproxy.
>>>
>>> thanks,
>>>
>>> -Uttam
>>>
>>> On Sat, Dec 4, 2010 at 10:00 PM, Mallett, Juli <juli at clockworksquid.com>
wrote:
>>>> Hi Uttam,
>>>>
>>>> To do your WAN simulation, are you using dummynet on the systems in
>>>> question, or are you simulating those links separately (or using real
>>>> links)?
>>>>
>>>> I suspect that the problem is either one of the performance
>>>> pessimizations that I recently fixed in Subversion or something in
>>>> network configuration.
>>>>
>>>> Just to be sure, can you do one or both of these:
>>>>
>>>> (1) Build 'tack' in programs/tack and run 'tack -TQc file.bin' where
>>>> file.bin is the file you're transferring.  This will give some idea of
>>>> how fast the XCodec is on that file.
>>>> (2) Rebuild WANProxy on both systems from Subversion.
>>>>
>>>> To build from Subversion do:
>>>> sudo pkg_add -r subversion (if you don't already have it installed)
>>>> svn co http://wanproxy.org/svn/trunk wanproxy-src
>>>> cd wanproxy-src/programs/wanproxy
>>>> gmake NDEBUG=1
>>>>
>>>> I did a few tests on a netbook that I have with a similar CPU and it
>>>> looks like it should be able to handle as much as 100Mbps for some
>>>> kinds of data.  I'm very surprised by the poor performance you note,
>>>> so I am wondering if it's a problem with latency simulation or similar
>>>> (for instance, putting the latency between the client and the client
>>>> wanproxy rather than just between the two wanproxy boxes.)
>>>>
>>>> Hopefully we can work this out quickly!
>>>>
>>>> Thanks,
>>>> Juli.
>>>>
>>>> On Sat, Dec 4, 2010 at 07:11, Uttam Singh <us at iptvlabs.com> wrote:
>>>>> Hi Juli
>>>>>
>>>>> Thanks for your prompt response
>>>>>
>>>>> I see your point, my performance results may be system bound.
>>>>>
>>>>> My Wanproxy systems have the following specs:
>>>>>
>>>>> - 1.6GHz dual-core Atom
>>>>> - 2GB 533MHz DDR2 memory
>>>>> - FreeBSD 8.0 Stable dedicated for wanproxy
>>>>> - each system is running build wanproxy-0.6.2 downloaded from
>>>>> http://wanproxy.org/releases/wanproxy-0.6.2.tar.gz
>>>>>
>>>>> - In my tests I am trying to get best results possible, I am doing
>>>>> multiple transfers in succession (i.e. upload multiple times and then
>>>>> download multiple times)
>>>>>
>>>>> I changed my WAN settings to 5Mbps symmetrical (up/down).
>>>>>
>>>>> Now I get following results while transferring same file multiple
times:
>>>>>
>>>>> No Wan Proxy:
>>>>>  - Up: 4Mbps
>>>>>  - Down: 4Mbps
>>>>>
>>>>> Wan Proxy:
>>>>>  - Up: 3.23Mbps
>>>>>  - Down: 2.71Mbps
>>>>>
>>>>> So compression may be adding to the latency here. Maybe given the
>>>>> system spec, this is only meaningful for slow links (1Mbps or, less).
>>>>> Though I don't quite understand why the CPU usage stats are so low.
>>>>> Also, there is still a material performance difference between upload
>>>>> and download - which is an anomaly.
>>>>>
>>>>> Please see other comments inline >>
>>>>>
>>>>> On Fri, Dec 3, 2010 at 9:53 PM, Mallett, Juli <juli at clockworksquid.com>
wrote:
>>>>>> Hi Uttam,
>>>>>>
>>>>>> Can you give me some information on the systems that you are running
>>>>>> WANProxy on?  You should see deduplication in each direction,
although
>>>>>> they are, right now, independent — that is, if you upload a file and
>>>>>> then download it, you won't get the benefit.  This is a short-term
>>>>>> shortcoming that did not used to exist, but is necessary during a
>>>>>> transitional period in which I am working on improving support for
>>>>>> many-clients, many-servers models of use, as opposed to the old
>>>>>> one-client one-server model.  I think that your test involves
multiple
>>>>>> downloads of the same file, so you should see performance
improvements
>>>>>> on download.
>>>>>>
>>>>>> I have a few more questions (and will flesh out the one I started
this
>>>>>> message with):
>>>>>>
>>>>>> 1) Are you using a Subversion-built version or an old release?
>>>>>
>>>>>
>>>>>>> 0.6.2 tar release
>>>>>
>>>>>
>>>>>> 2) Are the systems WANProxy is running on very fast?  I'm wondering
if
>>>>>> 2Mbps is as fast as the build of WANProxy you are using can run — it
>>>>>> seems unlikely since that is quite slow, but I want to be sure.  I've
>>>>>> made a lot of performance improvements lately, so if you're running a
>>>>>> Subversion build this should definitely not be the problem unless you
>>>>>> are running on systems with very slow RAM or CPU.
>>>>>
>>>>>
>>>>>>> 1.6GHz dual-core Atom with 2GB 533Mhz RAM. Wanproxy systems are
dedicated and not running much of anything else.
>>>>>>> While doing the file transfers I see Wanproxy top out at 5 - 8% CPU
(while CPU is 90+% idle)
>>>>>
>>>>>
>>>>>> 3) Are you in fact doing multiple downloads and multiple uploads for
>>>>>> your tests of the same file, or are you doing an upload and then a
>>>>>> download and then another upload or...what?
>>>>>>
>>>>>
>>>>>>> Multiple uploads of the same file and then multiple downloads of the
same file.
>>>>>
>>>>>> I hope that we can resolve your performance issues!
>>>>>>
>>>>>> Thanks,
>>>>>> Juli.
>>>>>>
>>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/attachments/20101210/9b9c944f/attachment-0005.htm>