Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

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.