Slow Client Performance due to DNS Query
(Last modified: 20Jan1999)
This document (2929988) is provided subject to the disclaimer at the end of this document.
Issue
ISSUE: This problem is seen as slow performance at the client. The slowness is usually random and does not last longer then the current operation. The problem has been seen during login, during a file open, during a map or ndir command, and during printing of the first print job of the day.
CONFIGURATION: This particular problem will only occur when both the Novell client and the MicroSoft client are installed on an NT or Win95 workstation. This document focuses on the Win95 workstation. The environment is set up as follows:
- Novell intraNetWare Client for Win95, v 2.20 or before.
- Microsoft client for Microsoft networks.
- NT server set up as a WINS server.
PROBLEM IDENTIFICATION: The problem can be identified by taking a trace of the slow performance. The trace will indicate that normal packet exchange between the client and the NW server will be interrupted while a name resolution to the NT server runs. The name resolution is performed by a DNS packet using NETBIOS and will take from 3 or 4 sec. to a minute. The name resolution will be looking for a NW server name on an NT server. NOTE: This is best seen on a sniffer trace, since it gives a little more detail about the DNS packet. After a period of time the query fails and then the initial packet exchange continues between the client and the NW server.
This name resolution process may occur multiple times over the course of a given operation. This is especially true if you have the problem at logon, since many different operations can be happening during a logon.
TROUBLESHOOTING: There have been several causes identified so far. Some are normal and legitimate, some are not. The following lists troubleshooting steps that can be taken to resolve the problem.
1. Disable client based anti-virus software. Anti-virus software can dynamically grab a file-open request to do a virus scan on the file. One customer was running F-PROT v 2.15 from Command Systems Inc.. When dynamic file checking was disabled the DNS name queries were no longer sent out. If running Norton anti-virus get the latest patch set for the product.
2. MPR makes a call to our provider piece (novellnp.dll). An API is being called, that was never documented by MS and therefore never written into our provider code. Since the call fails, the DNS query is executed in search of the server. There is a version of novellnp.dll available from a client escalation engineer to allow you to check for this condition. At present we can only test for the condition, a fix has not been written.
3. If the Win95 desktop has links to a file server, a file, directory, or print queue, where the same has been deleted or moved - the link becomes invalid. This will cause the DNS query and slow performance. Since the first provider being ask does not know about the file, etc. it can only return a failure condition. And since there is no way of knowing if the file, etc. exsists on the other network, Windows is forced to check both lans. Clean up invalid links, or remove one of the clients.
4. The MS provider being placed first in the provider order list will also cause the problem. The DNS queries will always take longer than an IP or IPX packet. The MicroSoft client is using the DNS packet to handle name resolution. Because of this, if the MS provider gets the request first it will always do the DNS query, slowing performance significantly. If the NetWare provider is first in line to be serviced, and if the request is for a valid NW server, the DNS queries will never take place. Windows NT provides utilities to allow you to set the provider order. In Win95 get a utility from a client escalation engineer to set the order.
5. THIS IS THE MAJOR CAUSE OF THIS PROBLEM:
There is a registry field, which, if it becomes populated with a NetWare Server name, the DNS queries are guarenteed. Using regedit go to the field HKey_Local_Machine / System / CurrentControlSet / Services / VxD / VCache / Lookup / ServerNameCache. Now choose the key "Key0000." Double click to see the data in this key. It will be displayed in ASCII text. If the text contains a NetWare Server name then look at the key "Data0000." The code 0020 means MicroSoft server, and the code 0030 means NetWare server. If the data indicates MS server (0020) then delete Key0000 as a workaround.
One explaination for how the key gets the wrong data is this: during boot up and login the preferred server name is sent out both clients, MS & NW. Normally, NetWare replies to the sap very quickly. If instead, the MS client gets a response back from a DNS server before the NetWare server responds, Windows assumes the response is from an SMB server (MS), and places the NW server name into the key, and the 0020 code into the data field.
To get around this problem, MicroSoft is writing a patched VCACHE.VXD module that will limit the length of the key0000 field to 0. This will prevent this key from being written to at all. They've choosen this approach because if the field is simply deleted, it will be recreated upon boot up next time, and the wrong data sometimes ends up back in the key.
The Microsoft document discussing this problem can be found at
http://support.microsoft.com/support/kb/articles/q194/8/27.asp?FR=0
There is also a patch available from Microsoft. See the Microsoft site for details
6. Another registry key that can cause a problem is HKey_Users / Default / Network / Recent. If this field has a server name that is no longer on the network the DNS queries will be sent out. Delete the key.
7. Disabling netbios name resolution in the registry has been found to work in some instances. To disable NetBIOS name resolution, change the string value "EnableDNS" in the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP from 1 to 0.
Other Things to Look at When Troubleshooting:
8. Is WINS configured to "Enable WINS Resolution?"
9. Are profiles enabled?
10. Is Remote Access (RAS) install?
11. Does the dos command map, or ndir cause the problem?
document
| Document Title: | Slow Client Performance due to DNS Query |
| Document ID: | 2929988 |
| Creation Date: | 16Sep1997 |
| Modified Date: | 20Jan1999 |
| Revision: | 14 |
| Novell Product Class: | Groupware NetWare Novell BorderManager Services |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.