Re: DFS Performance issues

On Wed, Dec 21, 2011 at 4:13 AM, Franck Schmidlin
<[email protected]> wrote:
> Hi,
>
> I'm hitting what seems to be a poor performance issue reading files held on a DFS file share.
> The files are not particularly big, but we are currently getting a throughput of about 3.6Kb/s for files 20kb to 4673kb in size.
> Opening the files directly (as opposed to programmatically through jcifs) doesn't show any performance issue.
>
> My code is using jcifs.smb.SmbFile to open and read a file from the DFS share, is not doing anything particularly clever and is running without performance issues on other (non DFS) sites.
> To run on this site I've first had to upgrade from version 1.2.13 to 1.3.17 to get rid of a 'The network name cannot be found' error.
> I have not yet re-tested on other sites with the latest libraries to confirm the performance.
>
> So now, I am a bit at a loss as to how to investigate this.
>
> Assuming this is a jcifs/dfs issue (I'm investigating other possibilities), are there specific questions I could ask of the network owners?
>
> All I know so far is:
>
>> The DFS file shares are on a file server cluster.
>> The files are copied with all ACLs and managed out of a file server cluster on server-01 and from here can reside on any of 4 nodes (eg. server-01b, server-01a etc.).  > Share level changes are managed by file server administrators on the cluster but we have access to the data shares from a server server-04.
>> However, by using the DFS share below it should be irrelevant to the system where the actual file server cluster is or which server is managing the shares.

Hi Franck,

I somewhat doubt that this is related to DFS as much as it is the
servers the cluster is referring JCIFS to. It's probably something to
do with buffer sizes. To really understand what is happening you would
need to get a packet capture. Anything else would just be a waste of
time I think. You want to look at the reads frame by frame with
WireShark and study the timing of frames. In particular you want to
see if there are a lot of reads with not a lot of data. In this case
you could try to play with buffer sizes or apply the large_read_andx
patch in the patches directory. Or if there are just delays between
frames, it's probably some networking layer issue. Or maybe it is
something to do with DFS like a DNS lookup delay before JCIFS even
starts reading the file. Whatever the case, you need to study a
capture.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/