I am testing the vfs_proxy fork of Samba 4 (maintained by Sam Liddicott a.k.a. Amin Azez): http://repo.or.cz/w/Samba/vfs_proxy.git I am conducting this test using the following servers: Hostname: lpt-112 OS: Windows XP Professional SP3 LAN1 IP: 192.168.220.43/24 Hostname: smbpc Samba version: vfs_proxy fork of Samba 4 (retrieved from GIT on July 7, 2008) OS: CentOS Linux 4 i386 eth0 IP: 192.168.220.86/24 eth1 IP: 192.168.227.20/24 Hostname: smbps Samba version: vfs_proxy fork of Samba 4 (retrieved from GIT on July 7, 2008) OS: CentOS Linux 4 i386 eth0 IP: 192.168.220.85/24 eth1 IP: 192.168.227.10/24 Hostname: fs Samba version: samba-3.0.25b-1.el4_6.4 for CentOS 4 OS: CentOS Linux 4 i386 eth0 IP: 192.168.220.72/24 lpt-112 is intended to simulate a Windows client at a branch office. smbpc is intended to simulate a proxy at a branch office. smbps is intended to simulate a proxy at a main office. fs is intended to simulate a file server at a main office. lpt-112 communicates with smbpc and smbps over the 192.168.220.0/24 network. smbpc communicates with smbps over the 192.168.227.0/24 network. smbps communicates with fs other over the 192.168.220.0/24 network. I used netem on the eth1 interfaces of both smbpc and smbps to simulate a 250ms latency delay between the hosts (125ms each way): tc qdisc add dev eth1 root netem delay 125ms The share \\smbpc\proxy uses the VFS proxy module to connect to \\smbps\proxy (192.168.227.10), which uses the proxy module to connect to \\fs\testuser1 (192.168.220.72). The share \\smbpc\cifs uses the VFS cifs module to connect to \\smbps\cifs (192.168.227.10), which uses the proxy module to connect to \\fs\testuser1 (192.168.220.72). (I set this up to compare performance. I assume the cifs module should not be performing any WAN optimizations.) I am using this 926kB Excel workbook for this test: http://warrantypartsdirect.dell.com/AMER/program/OptiPlex_Part_Guide.xls If I open the workbook on \\smbpc\proxy (192.168.220.86) from lpt-112 using Excel 2003, the workbook opens in about 75 seconds. If I open the workbook on \\smbpc\cifs (192.168.220.86) from lpt-112 using Excel 2003, the workbook opens in about 90 seconds. The times vary if I repeat the tests, but the general tendency is that the share using the proxy module doesn't perform substantially better than the cifs module (and often it performs worse). This 926kB Excel workbook is an example, but proxy doesn't seem to improve performance for any for any Excel, Word, or PDF document I try to open, save, upload, etc. I've experimented with different values for proxy:cache-readahead and proxy:cache-readaheadblock, but none of the values seem to substantially improve performance. I will attach the smb.conf files of each server and the smbd output at debug level 3 which was generated when I conducted the \\smbpc\proxy test.
Created attachment 3394 [details] smb.conf on smbpc
Created attachment 3395 [details] smb.conf on smbps
Created attachment 3396 [details] Debug (-d 3) output on smbpc
Created attachment 3397 [details] Debug (-d 3) output on smbps
I made an error in this paragraph: "The share \\smbpc\cifs uses the VFS cifs module to connect to \\smbps\cifs (192.168.227.10), which uses the *proxy* module to connect to \\fs\testuser1 (192.168.220.72). (I set this up to compare performance. I assume the cifs module should not be performing any WAN optimizations.)" I intended to write: "The share \\smbpc\cifs uses the VFS cifs module to connect to \\smbps\cifs (192.168.227.10), which uses the *cifs* module to connect to \\fs\testuser1 (192.168.220.72). (I set this up to compare performance. I assume the cifs module should not be performing any WAN optimizations.)"
Andrew, please assign this bug to me. The lack of performance at high latency is because of the current read-ahead model. Read-ahead is designed to keep the pipe full of data. Currently, it works by the client proxy requesting data in advance, however the client doesn't know how well the read-request will compress (and if it is using the cache to compress against this can easily be >100:1) and so it doesn't know how many "uncompressed bytes" to read-ahead by to keep the pipeline full. For un-cached data that will zlib compress, you can counter this by dividing the read-ahead size by the compression ratio, as long as this is small; e.g. if you compress at 50%, then double the read-ahead. If you are getting very high rates of compression (with zlib, or on a warm cache) then the read-ahead becomes too high, and the server will drop the connection, thinking that it has an abusive client with hundreds of outstanding read requests. Clearly we need a new read-ahead model which keeps the pipe full at higher compression ratios. I'm working on this.
Sam, Thanks for looking into this. I will try experimenting with very high values for read-ahead and see if it improves performance. Do you still want that tcptrace/xplot graph you asked me for on IRC? (In reply to comment #6) > Andrew, please assign this bug to me. > The lack of performance at high latency is because of the current read-ahead > model. > Read-ahead is designed to keep the pipe full of data. > Currently, it works by the client proxy requesting data in advance, however the > client doesn't know how well the read-request will compress (and if it is using > the cache to compress against this can easily be >100:1) and so it doesn't know > how many "uncompressed bytes" to read-ahead by to keep the pipeline full. > For un-cached data that will zlib compress, you can counter this by dividing > the read-ahead size by the compression ratio, as long as this is small; e.g. if > you compress at 50%, then double the read-ahead. > If you are getting very high rates of compression (with zlib, or on a warm > cache) then the read-ahead becomes too high, and the server will drop the > connection, thinking that it has an abusive client with hundreds of outstanding > read requests. > Clearly we need a new read-ahead model which keeps the pipe full at higher > compression ratios. I'm working on this.
Is this still an issue?
I imagine it is still an issue. I'm just finishing re-basing against the new merged samba master, then I can git-push
I'm still stuck on obtaining a measure of connection capacity.
I now have a solution to filling the pipe during read-ahead without knowing the capacity of the pipe. Work is in progress on this.
Sam, are you still working on this?
Is there still anyone working on this "vfs_proxy" fork? Otherwise I close this bug reports with "WONTFIX" soon since we as mainstream project aren't responsible for it.
Well, there hasn't been posted any comments about the actual state of this s4 vfs_proxy fork. I will close the related bugs since the project seems dead (got no response after two posts).