[jcifs] Peformance questions

[Michael B Allen]

On Sun, Mar 3, 2013 at 11:41 PM, Philip Warner <pjw at rhyme.com.au> wrote:
> On 4/03/2013 12:58 PM, Michael B Allen wrote:
>>
>> > My suspicion is that because DFS is enabled, and because DFS is not present, it is retrying for every block it sends. Hence the 400%
>> > slowdown when DFS is enabled.
>>
>> I doubt very much that is happening.  But if you can produce a capture that shows a problem I'll fix it (eventually).
>>
>
>> > Or it could just the the OS-level calls are really slow.
>>
>> Jcifs does not call any OS specific functions. It is 100% java.
>>
>
>
> I did ask before if you thought tcpdump would be up to the task, and if so, if you had any suggested command etc. It's been a long
> time since I played with it.
>
> That said, I just did a quick profile again with DFS enabled. And in the time I ran the profile it did:
>
> - 87 calls to SmbFileOutputStream.write()
> - 87 calls to Dfs.resolve()
> - 87 calls to Dfs.getTrustedDomains()
> - 87 calls to UniAddress.getByName()
> - 87 calls to UniAddress.getAllByName()
> - 87 calls to java/net/InetAddress.getAllByName()
> - 87 calls to java/net/InetAddress.lookupHostByName()
> - 87 calls to libcore/io/ForwardingOs.getaddrinfo
>
> which at least demonstrates that caching is not happening and that OS-level calls are happening for every write (I did not mean
> OS-specific calls, I did say OS-level calls in the original, and there is a subtle difference).
>
> The reason I think caching is not happening is because it does all the work to setup DFS and fails on every write() call so caches a
> 'null' value.
>
> I agree I can not prove that network access is is happening without a protocol dump, but I think this is pretty clear evidence that
> basic level DFS-related code is being called for every single write().
>
> The fact it goes from 85% idle to 20% idle when DFS is disabled at least suggests that some extra (probably network) IO is happening.

Yes, that is obvious. Like I said before, the socket connect is
probably timing out. The client probably doesn't have access to a DC
for some reason. There might be a logical change that I could make to
dodge that scenario. The client should not stall if it can't
communicate with a DC. But fixing that is not going to happen anytime
soon. It's not an easy change.

And in your case, without any way to lookup DFS roots, DFS support
will be useless anyway. So you might as well just disable DFS and move
on.

Mike

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