[jcifs] Performance Issue with jcifs and NetApp

Michael B Allen ioplex at gmail.com
Tue Jun 4 09:11:08 MDT 2013


Copying jcifs again.

What I see is:

36.6s: connect requests and responses are quick
66.6s: dir listing request response quick
96.6s: dir listing close request response quick

So the client is delaying 30 seconds in between each request in the
directory listing and possibly on startup. There is no other network
communication between these requests.

If you run with jcifs.util.loglevel=3 and attach the log, I think we would
see what is causing the delay. Again, don't use any other properties. If
you really want to know what's going on, we just have to go through each
diagnostic step. If you want it to just work, then you can use WINS or
disable DFS or whatever you need to make it work and move on. No one would
fault you for bailing out here.

Mike

PS: Incidentally something is pounding on your machine with SYN requests in
the port range 7801-7809. Every few seconds there is a burst of 10-20
requests.

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


On Tue, Jun 4, 2013 at 5:15 AM, Torsten Uhr <torsten.uhr at sql-ag.de> wrote:

> Hi Michael,****
>
> ** **
>
> using qualified DNS hostnames without any properties are running as slow
> as using short names. I have attached the TCP capture. Unfortunately I
> don’t what is ‚junk‘ and what‘s not.*Von:* Michael B Allen [mailto:
> ioplex at gmail.com]
>
> *Gesendet:* Montag, 3. Juni 2013 23:05
> *An:* Torsten Uhr; jcifs at samba.org
>
> *Betreff:* Re: [jcifs] Performance Issue with jcifs and NetApp****
>
> ** **
>
> Hi Uhr,****
>
> ** **
>
> I'm also sending to the mailing list for posterity (I would CC but gmail
> is slowly becoming an incomprehensible simplistic POS).****
>
> ** **
>
> I have analyzed your capture.****
>
> ** **
>
> It seems you are trying to use NetBIOS names and the lookups are failing
> (unless you specify a WINS server as you have discovered). NetBIOS names
> are the short one-label hostnames. Do not use NetBIOS names. NetBIOS is
> virtually all but dead. Even when people use short one-label names they are
> almost always still using DNS weather they realize it or not because the
> host resolver is using the builtin domain suffix search feature. But JCIFS
> does not have the capability to use a domain suffix search. If you use a
> one-label name, JCIFS will try to do NetBIOS and thus you'll get failure.
> So you should always use fully qualified DNS hostnames with JCIFS (and all
> other applications). That might be inconvenient but anything less is simply
> inaccurate and prone to failure. All real applications should use FQDNs.**
> **
>
> ** **
>
> You should not need to disable NTLMv2. If your NetApp server doesn't
> support NTLMv2, you really should look into updating it because eventually
> someone is going to disable NTLMv1.****
>
> ** **
>
> So take out all of the properties and just try to use a fully qualified
> DNS hostname in your SMB URL.****
>
> ** **
>
> Note that your capture also had a bit of other junk in it. If you send me
> another capture for some reason, it would be better if you could identify
> the junk and filter out those ports.****
>
> ** **
>
> Mike****
>
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/****
>
> ** **
>
> On Mon, Jun 3, 2013 at 6:28 AM, Torsten Uhr <torsten.uhr at sql-ag.de> wrote:
> ****
>
> Hi Michael,****
>
>  ****
>
> attached Your will find two TCP captures. The file ‚with_props.pcap.zip‘
> was created using the following jcifs properties:****
>
>  ****
>
> export JAVA_OPTS=-Djcifs.smb.lmCompatibility=2
> export JAVA_OPTS=-Djcifs.smb.client.useExtendedSecurity=false
> export JAVA_OPTS=-Djcifs.util.loglevel=3
> export JAVA_OPTS=-Djcifs.resolveOrder=DNS
> export JAVA_OPTS=-Djcifs.smb.client.dfs.disabled=true
>  ****
>
>  ****
>
> The file ‚without_props.zip‘ was created using the following jcifs
> properties:****
>
>  ****
>
> export JAVA_OPTS=-Djcifs.smb.lmCompatibility=2
> export JAVA_OPTS=-Djcifs.smb.client.useExtendedSecurity=false
> export JAVA_OPTS=-Djcifs.util.loglevel=3
> export JAVA_OPTS=-Djcifs.resolveOrder=LMHOSTS,WINS,DNS
> export JAVA_OPTS=-Djcifs.smb.client.soTimeout=35000****
>
>  ****
>
> Surprisingly the following configuration works as fast as expected!!****
>
>  ****
>
> export JAVA_OPTS=-Djcifs.smb.lmCompatibility=2
> export JAVA_OPTS=-Djcifs.smb.client.useExtendedSecurity=false
> export JAVA_OPTS=-Djcifs.util.loglevel=3
> export JAVA_OPTS=-Djcifs.netbios.wins=193.30.54.5
> export JAVA_OPTS=-Djcifs.smb.client.soTimeout=35000
> export JAVA_OPTS=-Djcifs.resolveOrder=DNS
> export JAVA_OPTS=-Djcifs.smb.client.dfs.disabled=true****
>
>  ****
>
> Correcty my if I wrong, but in the last test, if we set ‚
> jcifs.resolveOrder‘ to ‚DNS‘, why the property****
>
> ‚Djcifs.netbios.wins‘ is not ignored?****
>
>  ****
>
> With best regards****
>
>  ****
>
> Torsten Uhr****
>
> Leiter Entwicklung TransConnect®****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20130604/37ff880a/attachment-0001.html>


More information about the jCIFS mailing list