Are Your NetWare Servers Staging A Slowdown?
By Bill Alderson and J. Scott Haugdahl
Q:
The response time from our NetWare-based imaging server has been slowing to a crawl. Using our protocol analyzer, we've observed "server busy" packets coming from the server. We'd prefer not to invest in a faster hardware platform or move to Windows NT. We've considered upgrading our infrastructure to accommodate a faster topology, such as 100-Mbps Ethernet at the server, but first we'd like to pinpoint the cause of the slowness.
Scott:
Despite the hype surrounding Microsoft Windows NT, there's still a huge installed base of Novell NetWare servers and clients that require support. Let's examine our client's problem: Is it one that manifests itself in NetWare server-based environments?
Bill:
For starters, have you ever looked at a packet trace to see a client send two or more request packets in succession without a reply from the server?
Scott:
Sure. If we're using an expert system, it might even say "repeated request."
Bill:
Sometimes it takes a bit of work to track down the reason for not receiving a reply, such as a lost packet, a busy router, lack of WAN bandwidth or an overloaded server.
Scott:
In NetWare's case, an overloaded server will typically send back a "server busy" packet.
Bill:
Just as our customer noted, we could see this packet in our analyzer trace, and we immediately determined the primary reason for the repeated request.
Scott:
By setting a filter on "ser
ver busy" packets, we could baseline how often the file server said, "Hey, le
ave me alone. I received your request, but need a bit more time to service it."
Bill:
So, the original request actually was queued up in the server.
Scott:
Getting lots of busy packets shouldn't mean automatically considering a more powerful hardware platform, a faster network or a different network OS platform.
Bill:
We might first consider digging in and tuning the existing server. With our client in this case, we began by taking a closer look at the persistent "server busy" packets from our customer's imaging server.
Scott:
Upon further analysis of a trace, we noticed that the "server busy" packets were sent only in response to file handle allocation requests--such as open, rename, create and delete files.
Bill:
Other requests for files that already had a file handle experienced minimal del
ay.
Scott:
For this reason, we suspected directory-related issues such as maximum file opens and directory caching.
Bill:
After repeated attempts to tune the server by changing several directory-related parameters with no success, we decided to take a different approach to solving this problem.
Scott:
To find the core problem, we had to make the system fail repeatedly. We did this by increasing the directory requests to the point of a fairly heavy load.
On The Edge
By Art Wittmann
FreeWire
By Bill Frezza
Corporate View
By Brian Walsh
In The Middle
By Nick
Gall
Updated October 24, 1997
|
REPORTS
ANALYTICS
Follow 
