RSS
  Remote-Access Servers Pushed to Their Limits By Bruce Boardman How do you know if your enterprise remote-access server can stand the heat? What would it take to bring it to its knees? To find out, we pushed a handful of servers to the absolute max--with some surprising results. When it comes to the remote-access server needs of a real-life enterprise, number of ports and sheer speed are not enough. For one thing, an enterprise requires switched access for diversity in protocols and services. The Point-to-Point Protocol (PPP) and IP, while no doubt important, are only part of the enterprise requirement. Protocols like X.25, Synchronous Data Lin k Control (SDLC), IPX and Apple Remote Access (ARA) may also be in the mix. For another, organizations with a worldwide reach may find that digital availability cannot be taken for granted, making the reliance on analog still very important. And finally, the necessity of overseeing not only high port counts but a user count that is easily 10 times higher than that port count makes managing remote-access servers a critical undertaking.
Muscle Tests Our goal was to drive the maximum load possible onto each server and measure the results of that load on a single controlled user. We chose to drive analog traffic because we knew its additional processing overhead would constitute a worst-case scenario. We loaded the servers with consistent IP traffic in the form of endless-loop FTP traffic from the maximum number of supported analog clients minus one. This traffic included logging on and off the FTP server. To this we added a single client that transferred IP and IPX files in a standard Windows95 dial-up networking environment. Three files were transferred by DOS COPY for IPX, and FTP for IP. The files consisted of a fairly compressible text file, the same file compressed with PKZIP, and a highly compressible bit-map graphic. To establish a best-case scenario baseline, we transferre d each file repeatedly without any load. We compared this no-load mark to other known working servers to determine the overall accuracy of the test bed setup. We then loaded the server with FTP transfers that we monitored for speed and consistency of times across the ports. We expected some degree of degradation, but widely varying times either between ports or on the same port between one transfer and the next were checked for indicated bottlenecks. Once we could attribute no bottlenecks to the test bed, we measured the single client against the background traffic. We never attempted to reduce the background traffic load to a level that would improve a poorly performing server. Rather, we considered the maximum allowable analog ports as the benchmark against which to compare all servers--in some cases as many as 96 ports! It was interesting to note that the products that performed better under high load were those that segmented their workloads among multiple processors and/or multiple data paths , rather than those that tried to have one gigantic resource do everything. Results The king of all the products we tested was 3Com Corp.'s AccessBuilder 5000. In a field of excellent products, it nosed out Microcom's Access Integrator, with better management, and Shiva Corp.'s LanRover A ccess Switch and Cisco Systems' AS5200, with better hardware flexibility. All four products make our short list of hot remote-access servers for the enterprise. Note that plenty of changes are in the works for these products, including new Web-based management applications and security services. In fact, some of these modifications will have taken place by the time you read this.
|
To view the Report card.
|
by Steven A. Rodgers with Teresa Rodgers Updated March 7, 1997 |
