Re: Peformance questions

Hi Philip,

It sounds like there's some kind of networking quirk like a socket
option that's wrong for the Android JVM. This almost certainly has
little or nothing to do with JCIFS. It's not a "performance" issue.
The methods that you reference are just sleeping. Although there could
easily be something timing out like a DFS referral that isn't
applicable because you're not in a domain environment in which case
you should disable DFS with jcifs.smb.client.dfs.disabled = false.
Otherwise, I'm not familiar with Android development so I have no idea
as to how to go about debugging such a thing.

Mike

On Sun, Feb 24, 2013 at 7:36 PM, Philip Warner <[email protected]> wrote:
> Hi,
>
> For brevity, the summary is I have two questions regarding saving a file to
> a windows (Samba) share:
>
> Q1: Can I reduce the number of times it calls peekKey()?
> Q2:  Is there any optimization that I can perform to reduce the DfsResolve()
> calls or cost?
>
>
> The background for these questions is below...
>
> I am quite new to jCIFS. I recently added it to my Android app (Book
> Catalogue) and was surprised at how long it took to write data to a network
> share via a WiFi link. I did some searches and found various references to
> setting buffer sizes as well as copying data, but these did not seem to help
> (or explain the slowness completely).
>
> For some numbers:
>
> - save locally (sdcard) approx 1 minute (80mb file)
> - save to network approx 5min 30sec (80mb file)
> - copy file from local to network (using ES File Explorer), approx 1 min 30
> (80mb file)
>
> My next step was to profile the app. In a 29 second profiling session (much
> longer risks crashing either Android or the app), I found:
>
> - 28,972ms total time
> - 4007 ms total CPU (so it's spending 85% of its time waiting)
> - of the total time, 53.7% (15571ms) is spent in SmbTransport.peekKey(). It
> was called a total of 337 times in the 29 seconds.
>
> I assume that the peekKey() time is waiting for an ACK of some kind.
>
> So the first question is:
>
> Q1: Can I reduce the number of times it calls peekKey()?
>
> Once I ignore the peekKey() related calls (Transport.readn(),
> PlainSocketInputStream.read() etc), the next biggest time is:
>
> - 7371ms in SmbFileOutputStream.writeDirect()
>
> This does not worry me overly; it spends approx 26% of the total time
> writing the file; if it was reduced to this only, then the total time would
> go from 5.5 min to less than 1.5 min, which is what I see from 'ES File
> Explorer' copying a file.
>
> The next one I see that is quite odd is:
>
> - 5734 ms in Dfs.resolve() called from SmbFile.send(), called 168 times in
> 29 seconds.
>
> It's no nig deal, but it does account for 78% of the time in SmbFile.send(),
> and does seem to actually ask the OS for name translation on each call
> (there are 168 calls to InetAddress.getAllByNameImpl()).
>
> Which leads to my second question:
>
> Q2:  Is there any optimization that I can perform to reduce the DfsResolve()
> calls or cost?
>
>
> I may of course be barking up the wrong tree here, this may be a simple
> unavoidable result of using SMB, but the initial stats (file copy time using
> a different app) leads me to believe otherwise.
>
> Any help would be greatly appreciated!
>
> Thanks.
>
>
>
>
>



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