我们有一个连接到Server 2003机器的16个使用率很高的Windows 98电脑的networking。 这些机器在高峰使用时间（每天1：30-2：30pm）时，在networking上打开/运行文件时会经历很长时间的延迟，有时会持续一分钟。 当可执行文件正在等待打开时，用户只会得到一个黑色的DOS屏幕，通常它会在<1秒内popup。 这特别令人烦恼，因为Server 2003性能计数器不会显示长时间的高负载 – 大多数统计数据甚至不会超过5％。
当这16个客户端连接到一个运行Linux的6岁DL380时，我们有一些缓慢，但没有延迟。 我们最近过渡到Active Directory，并升级了文件服务器。 文件服务器具有双核四核处理器，4倍的内存，更多的磁盘，更快的驱动器（15K对10K）等等，所以似乎没有任何意义，它不能再处理并发处理。
由于我们使用Win98，有什么设置，我们应该改变2003年优化磁盘读/写？ 所有的文件操作都是平面文件，所有的写操作都是由一个用户完成的（多个用户一次不能访问同一个数据库）。 关于如何跟踪这个问题的任何其他想法…我们在过去一个月没有运气。
注意：不幸的是，我们不能再升级到Win98以外的两年，我们正在等待旧版软件被重写，而这个关键软件只能在Win98上运行，因为使用了硬件中断。
当所有其他的失败，扔在它的networking嗅探器。 在客户端计算机正在等待的时候，看看networking上发生了什么，也许你会看到实际上正在等待的东西。
顺便说一句，你在networking上使用WINS吗？ 这也可能是一个NetBIOS名称parsing问题。 Windows 98 / NT客户端喜欢使用它来代替DNS，而不使用WINS，它将尝试使用广播查询来parsing名称，这在networking高峰使用时间可能是一个真正的痛苦。
我同意这很可能是SMB签名/身份validation和/或Netbios名称parsing。 Netbios名称parsing可以用NbtStat来testing。
如果certificate不是这种情况，那么我会禁用服务器上的OpLocks。 除了破坏访问文件，它似乎也会导致访问问题。 我还没有看到禁用它会导致一个问题，但如果它使事情变得更糟，这种改变可以逆转。
http://support.microsoft.com/kb/296264 http://support.microsoft.com/kb/296264
你有没有尝试过Server 2003 Performance Advisor ？ 可能会帮助你进一步深入研究这个问题。
你能从Windows 98客户端和域控制器发布任何有希望的事件吗？
此外，什么是客户名字parsing？ 我会尝试重新启动以刷新DNScaching（ ipconfig /flushdns在Windows 98中不起作用），然后ping domain.local 。 看看你回来了，需要多长时间。
我遇到了DNS导致延迟30秒的问题，因为域控制器有多个A条目（这是多宿主，公共和私有networking）。
最终发生的事情是客户端首先尝试连接到分配给DC的公共IP地址。 这将在30秒后失败，然后尝试使用分配给DC的专用IP进行连接。 这将工作。
如果你想快速跳过这个testing，你总是可以尝试\\ [server ip] \ share \ executable.exe，看看它是否快速启动。
虚拟机是通过桥接虚拟适配器还是通过NAT访问networking？
我们在这个服务器上镜像了Active Directory，一旦删除，问题就消失了。 在如此小的环境中（25个用户），为什么这会有所作为？