Re: Peformance questions

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.