WANProxy performance test

[Juli Mallett]

On Thu, Mar 13, 2024 at 2:49 AM, Ahmed Al -Ghafri <al-ghafri at hotmail.com>wrote:
>  Dear Juli,
>
> I have made a test to touch the performance of WANProxy in virtual
> environment; I use WANem to emulate 128 Kbps  and I noticed the following:
>
> -       The caching technique seems to have a significant issue where it
> doesn’t save the bits for long enough time; I tried to download X file
> first time then directly download X for the second time and the caching
> worked well. But when I download Y file after the first X download and then
> try to download X again WANProxy goes to bring the file without using the
> cache (the cached X bits no longer present).
>
I'm sure this isn't true because right now the cache doesn't expire.  Can
you provide more information about the client and server you were using, as
well as the file you were testing with?  I can promise you the "cached
bits" were still present :)  But with some protocols, there are other
issues to consider, like whether the protocol uses compression that might
change from one request to another, since WANProxy doesn't decompress e.g.
HTTP message bodies.
> -       Also I tried to download excel file for the second time with
> little changes in some cells value in the excel sheet, WANProxy doesn’t
> show a significant optimization and it downloaded the file without
> consideration in the cached bits or at least most of file bits had been
> re-downloaded , as it looks like?
>
Again, file type matters a lot here.  Is this a modern Excel file, i.e. an
xlsx file?  If so, those are just zipped directories, and while there's
only a small change to the innermost file, WANProxy doesn't do any
type-aware optimizations, as would be needed in this case, e.g. to unzip
the files first and then deduplicate.  So you'd only get optimization if
the ZIP files were exactly the same.
What I ended up for WANProxy is that it does caching for short time and not
> “true” bit-level caching. Hope this was configuration related issue and can
> be fixed.
>

I *think* it was the nature of the test that was probably the issue here,
as the configurations for WANProxy look correct at a glance and your
network diagram does, too.  We'll figure it out :)
Thanks,
Juli.
> Here are the configurations (after help from WANProxy developer):
>
> Clinet:
>
> =======
>
> create codec codec0
>
> set codec0.codec XCodec
>
> activate codec0
>
>
>
> create interface if0
>
> set if0.family IPv4
>
> set if0.host "192.168.4.1"   #ip of interface connected to client and
> used to reach server
>
> set if0.port "80"   #port number which WANProxy listen to (you can select
> any port but use the same port when connect from client)
>
> activate if0
>
> create peer peer0
>
> set peer0.family IPv4
>
> set peer0.host "192.168.1.2"  #ip of WANProxy server which set up in
> WANProxy server configuration
>
> set peer0.port "3301" #port of WANProxy server which set up in WANProxy
> server configuration
>
> activate peer0
>
> create proxy proxy0
>
> set proxy0.interface if0
>
> set proxy0.interface_codec None  #for WANProxy  client this set as None
>
> set proxy0.peer peer0
>
> set proxy0.peer_codec codec0  #for WANProxy  client this set as codec0
>
> activate proxy0
>
>
>
> Server:
>
> =======
>
> create codec codec0
>
> set codec0.codec XCodec
>
> activate codec0
>
>
>
> create interface if0
>
> set if0.family IPv4
>
> set if0.host "192.168.1.2" #Ip of WANProxy interface connected to the
> server machine
>
> set if0.port "3301" #port  explained in client
>
> activate if0
>
>
>
> create peer peer0
>
> set peer0.family IPv4
>
> set peer0.host "192.168.1.1" #ip address of the server machine
>
> set peer0.port "80"   #port number of the server machine
>
> activate peer0
>
>
>
> create proxy proxy0
>
> set proxy0.interface if0
>
> set proxy0.interface_codec codec0  #for WANProxy server   this set as
> codec0
>
> set proxy0.peer peer0
>
> set proxy0.peer_codec None  #for WANProxy server   this set as None
>
> activate proxy0
>
>
>
> The network diagram is here:
>
> http://s18.postimg.org/w7wa1qibd/WANP_png.jpg
>
> _______________________________________________
> wanproxy mailing list
> wanproxy at lists.wanproxy.org
> https://wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://wanproxy.org/pipermail/wanproxy-wanproxy.org/attachments/20140313/848655d2/attachment-0002.htm>