The Strain of Gateway Services for NetWare

[Editor's Note: Do you have something to share with other readers who visit Windows NT Magazine online? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (300 to 700 words) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100. Reader to Reader submissions are the reader's opinion and do not necessarily represent the views of Windows NT Magazine.]

If you've ever run Windows NT's Gateway Services for NetWare (GSNW), you might have wondered whether this service was putting a strain on your server. Even though Novell might not be the master any more, no one can deny the presence of Novell servers in most companies. And in the cases where Novell servers coexist with NT servers, the GSNW lets NT clients access data on the Novell server. These users don't even see the Novell server. Instead, they think they're accessing a share on the NT server. And although Microsoft envisioned IT administrators using this service for migration purposes, people kept using it because it was both easy and fast, and it ran without any double-logon hassles. Best of all, you don't need to install the Novell protocol on your clients. It sounds wonderful, but a lot of people have asked me if this service adds extra strain on the server, and if so, which component (i.e., the processor, the memory, the disk, the paging file, or the network) has to cope with this extra strain.

I tested the GSNW in various classrooms, and in each case, some 10 clients connected and copied 10MB (simultaneously) from one Novell server through one NT server, running the GSNW. The NT server ran standard software (sometimes a few BackOffice programs) and used between 64MB and 256MB of RAM. In most cases, the Novell server was a 486 processor with 32MB of RAM. (For more detailed information on the test environment, you can download the log file [7561.zip] from the Article Info box and view it in Performance Monitor, and you can refer to the sidebar, "Test Environment.")

In Performance Monitor I tracked the following instances on the server:

Table 1 gives you an idea of how the copy affected these counters.

In each case, I didn't notice a significant difference in measuring the memory usage. Cache memory went up slightly, but the paging file and the disk remained relatively stable. As a result, I could assume that GSNW wasn't straining the hard disk and the internal memory that much. However, I did notice a parallel between the bytes sent and the processor activity. As soon as I used GSNW to copy chunks of data, the CPU usage increased.

When you think about it, this is a logical response: The server is receiving IPS/SPX packages and has to send them to a network with either TCP/IP or NetBEUI. So the server is mainly performing packet translation. Of course, as more and more users are copying files across the network, this might create both a processor and memory bottleneck, because more caching needs to be done.

So if you're worried about GSNW slowing down under the load, you can try some of the following options:

—Bart Portier
[email protected]