Why do these SMB/CIFS transaction repeat over and over?

The following trace was taken while accessing a database program over the wire. In troubleshooting slow performance I noticed that it seems like the same sequence is being repeated over and over. The following was repeated 23 times before it moved on. I know that SMB/CIFS is very chatty, but can some one explain why it is behaving this way? This program was written in DbaseIII and please don't tell me they need to change, this is the program they are going to use. Also, I have been searching high and low for tips on reading traces, if anyone has a good reference I would be greatful to be pointed in the right direction.

Who is Participating?

Could be that somebody else has the file locked already. If multiple people are running the same program at the same time, only one will be able to get exclusive use of it. If the file is locked while the program is running, then if it takes two minutes to run the program, nobody else can run it for two mintes. If it takes 20 minutes to run the program, then nobody else can run it for 20 minutes.

Is the MCAIMS.INI file dBASE III related ini file, or an application related any file? If it is application related you may want to see if there is away to put it on the remote PC and have the application access it locally.

It is a file that does reside on the file/databse server? What is in this file?

Offhand I would say that this is sometype of configuration file and either the application or DBaseIII needs to read it mutiple times in order to do the work required. You said that this was read 23 times, is there something in the application that is done 23 times? Do you have 23 tables that are being used by the application?

What is "Slow?" Is it taking hours when people feel it should take minutes or is it taking 10 seconds and they want it to take 2?

0

bb91915Author Commented: 2006-07-21

Yes, the ini file does reside on the file server that is located across a WAN link. This particular transaction is running at about 20 minutes versus 2 minutes locally. There are numerous tables contained within this database and I would bet that you are correct about it having to repeat numerous times because of the ini file. I will see exactly what the ini file contains first thing Monday morning. Knowing that this type of application was built for LAN use only, I have to show the customer why it runs so slow over a WAN link and thanks to you, I think I have the answer.

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

What is the speed of the WAN link? The 3 series of operation you show here only took about .2 seconds. If we round it up to .3, that is .1 second per "function. So 23 times would be 2.3 seconds. I don't think this is causing the problem. However running a datbase application over a WAN link will be slower than locally, even if the WAN link was a pair of T3's.

I would focus on the volume of data that is being passed over the WAN link, how busy the WAN link is, and the latency. You might be able to do things like increase the TCP windows size (assuming that this is TCP based).

Tweaking the DB query could cause less data to be returned, thus speeding up the response also.

0

bb91915Author Commented: 2006-07-22

giltjr,

The WAN link is a DS3 (44mbps) with a 9ms latency (one-way). We use a 65kb window size and the circuit utilization is well under 20% and running at full duplex. I am going to focus on the ini file and what it has the application doing and to find out exactly how many tables it is traversing to get the data. The amount of data changes on what query they are running and of course the more data it is getting the slower it will be. I will also see if the customer can tweak their queries as well. Thanks for the input.

Well I would say that you can get much better on the WAN link. The other question would be how DBaseIII is accessing the databases. It has been years since I have even heard that name. But, if it is accessing the databases as a file share on a remote system, that means NETBIOS type file sharing. Which is slow on any type of connection that has more than about 2-3 ms of latency. If it is using its own networking functions, like having the SQL execute on a remote server and just having the results returned, then you need to trace how that flow goes.

Look to see if the data returned is one long stream of data or a bunch of smaller stream. A bunch of smaller streams could cause performance issues no matter how fast the pipe is, if the smaller streams are done serially. This is because normally each stream is a unique TCP connection, which means connection setup and tear down for each stream.

0

bb91915Author Commented: 2006-07-24

This is all done in one session with a majority of the frames containing less than 100bytes of data. I also looked at the ini file and it only points to the the default path where the files are located, the location of the temp directory where all work is locally. So I guess the ini file idea did not pan out. Looking into the SMB NT Create AndX Request/Responses I found and I quote,
" A Create and X SMB tells a server to open a designated file and return a file handle. The request
includes flags to indicate the type of access required by the client. Another set of flags is used to
request an opportunistic lock (oplock). "Opportunistic" means the server is free to hold off on the
request unitl it can lock the file. If the client doesn't free the oplock, the only way to break it is to tear
down the entire session".
What I need do now is tear apart each frame and see if this is what is happening. Looking at it from a distance, this does seem to appear what is happening. I will let you know what I find.
Thanks,

Off hand it appears as if this is setup as though it was file sharing the database instead of a client/server model.

Is a full copy of dBASE III running on the client and accessing the server as a file server?

Or is it using ODBC to talk to the server as a database server?

0

bb91915Author Commented: 2006-07-24

Only the executable is located on the client, the remainder is located on the file server. As far as if they are using ODBC to talk to the server, I don't know at this point but I will try and find out. After digging into the traces a bit further, I can see that the client is requesting either an Exclusive or Batch Oplock and the server is responding with "No oplock granted". If I understand it correctly when the client is not authorized to place a lock on the file so it has to do the following over and over until it has all of the information:

Opening the command procedure.
Seeking to the next line in the file.
Reading the line from the file.
Closing the file.
Executing the command.

If Oplock is granted the client can go through the process without reestablishing this line of communication. I got the information from the following link:

I would have to say no to the file being locked by someone else, only one person was accessing it at the time and I know this because no one else knew that we put the files on the server, plus the fact that the file server is not granting an oplock on the file. I am not sure I understand your question about the ini file, but what I do know is when the application is launched, it reads the ini file to see where to go to get the files.

I will try and re-ask my question about the ini file. Is the ini file for the application? Or for dBASE III?

If for the application, then you might be able to put the file on the comptuer that is running the application.

If it is for dBASEIII then you may need to leave it where dBASEIII is running, however in this case it sounds like dBASEIII may be running on the users compute.

0

bb91915Author Commented: 2006-07-26

Yes and no. The ini file is for DBase III and only really points the client to the location of the database files. I believe the problem is with opportunistic locking, but will not know for sure until we enable it on the server if that is possible. I ran another capture where the server had oplock enable but the difference is, besides the oplocks, is that one server is a windows platform and the other is a paired down version of redhat, meaning it is part of a SAN solution where it basically acts as an appliance and is running a proprietrary system called DART. I do want to thank you for the help, you made me look where I wouldn't have looks before asking the question. Thanks.