Revving Up RAS
Powerburst by Airsoft is a unique product.
It's a remote-access accelerator. You can use it in both the Windows NT Server
and Novell NetWare environments to speed interactions between a remote client
and a file server. Powerburst improves performance by caching file accesses for
the remote server. This approach means the client cache can handle subsequent
accesses to a cached file so the server doesn't have to repeatedly retrieve the
same file remotely.
Conceptually, this approach is similar to how the Netscape Navigator caches
Web pages as you cruise the Internet. However, the big difference--and the big
deal--is that Powerburst ensures the accuracy of the data in the cache before
passing it to the requesting application.
In the Powerburst architecture, remote access breaks down into three
logical functions, the file server, the client, and the agent. The file server
can be a NetWare server or an NT Server. To access the file server, clients use
a dial-in link such as NT Remote Access Service (RAS) or a router or similar
remote connection. In the version of Powerburst we tested (1.20), no special
software is required on the server.
The client is the user system that initiates the remote connection, or in
the NT world, the client side of a RAS connection. Powerburst does most of its
work on the client: After you establish your RAS link, you activate Powerburst,
and it enables the client-based cache. In the NT Server environment, Powerburst
1.20 currently supports Windows 3.X and Windows for Workgroups (WFW) clients
configured for RAS support. By the time you read this article, a version of
Powerburst that also supports Windows 95 clients will be available. A timeline
on planned support for Windows NT Workstation clients was not available at press
time.
The agent is a special Airsoft-created function that validates data to
ensure that the information in each client's cache is accurate and reflects the
corresponding information on the file server. A single agent can concurrently
handle up to 64 clients. In Powerburst 1.20, the agent software must run on a
DOS-based system locally attached to the same LAN as the file server. By the
time you read this, you can expect a new version of Powerburst that lets you run
the agent as a virtual loadable module (VLM) under NetWare or as a service under
NT.
The interaction between the client and the agent is the key to
understanding Powerburst. On the client system, when you first start Powerburst,
it begins building its cache of data as the client interacts with the remote
file server. When an application requests data that exists in the cache, the
client sends a terse, coded message to the agent. This message identifies the
file in question and the data area in the file. The agent then uses a local,
high-speed LAN connection to check the data on the file server and reports back
to the client. If the data is unchanged, the request is satisfied from the local
cache. Otherwise, Powerburst retrieves the data from the file server and
refreshes its cache.
The assumption is that the client-query/agent-response approach is faster
than retrieving the entire file over the remote connection. To further enhance
performance, the client does look-ahead caching to predict future requests. In
many ways, Powerburst's caching technique is similar to that of disk-caching
programs, such as the DOS SMARTDRV program. The difference is that Airsoft has
developed proprietary caching algorithms to address the unique characteristics
of remote access.
The Test
We tested Powerburst 1.20 on a DOS-based 60-MHz Pentium system as the agent,
a 60-MHz Pentium NT server as the file server, and a 50-MHz 486 laptop running
WFW as the client. Powerburst came on two high-density disks: one for the agent
and one for the client. The package included a thin, but fairly complete,
manual.
The first decision was which protocol to use between the DOS agent machine
and the NT server. Powerburst supports NetBIOS/NetBEUI and NetBIOS over TCP/IP
in the NT environment. The DOS machine we used was already configured to run
NetBIOS/NetBEUI with WFW, so we decided to take the path of least resistance. If
WFW had not been on that machine, we could have installed DOS LAN Manager
support from the NT Server distribution CD.
Installing the Powerburst agent software was simple and straightforward.
After we installed it, we had to run a configuration program to define a name
for the agent. The agent name is really the NetBIOS name that the clients use to
establish sessions with the agent. Then, we rebooted DOS and brought up the
agent by issuing three commands: netstartfull, share/l:500/f:5100, and pwragent
The netstartfull command activates WFW network support for DOS. The
activation sequence prompts you for a username and password for your workgroup
or domain. A critical requirement is that the username you specify has
read access rights to all the files that the remote clients potentially will
access.
The Powerburst agent software requires share /l:500 /f:5100. This is a DOS
terminate-and-stay-resident (TSR) service.
The pwragent command invokes the agent, which runs as a foreground
application. The agent software displays a brief configuration summary and then
waits for an incoming client connection. This command doesn't establish a
connection to the file server until a client connection is made.
With the agent up and running, our focus shifted to the client environment
where we used WFW. A Windows-based setup program handles the installation of the
Powerburst client software. This program copies the files to either a hard disk
or a network disk. Then the setup program installs a new program group that
contains Activate, Deactivate, Powerburst Control Panel, and Powerburst Helper
applets. Finally, the program modifies the Windows system.ini file and the DOS
config.sys file. (Powerburst wants files=100 and buffers=40.) You need to reboot
when the installation process is complete.
Before you can use the Powerburst client software, you must configure the
agent name you set up in the agent software. The client needs this name to
communicate with the agent. The client-to-server RAS connection can use
NetBIOS/NetBEUI or NetBIOS over TCP/IP. We used NetBIOS/NetBEUI.
Before you start the client software, you must use RAS to establish a link
to the NT server and connect to one or more directories. If you attempt to start
Powerburst before making these connections, you get a warning message saying
that you don't have any remote file connections. After you connect to a
directory, you activate Powerburst using the Activate icon or through the
Control Panel. The Powerburst client then establishes a session with the
Powerburst agent, displays confirmation of the end-to-end connection, and the
caching process begins. Screen 1 shows the confirmation display.
Quick Cache?
The first time you run the Powerburst client, performance will be slower
than usual because the client must build its cache, so that Powerburst can
satisfy read requests from the cache--if the requested information is there.
Information in the cache is delivered to the application about twice as fast as
over the remote access link.
For a simple test, we loaded a 90KB Word for Windows document over a RAS
link, with and without Powerburst enabled. First, we loaded the document with
RAS to establish a baseline time. Then we enabled Powerburst with an empty cache
to see how long loading the document and establishing a cache took. We loaded
the same document again to see how the Powerburst cache affected the load time.
Our tests took the following times (in seconds):
RAS only (Powerburst not enabled): 40.86
Powerburst enabled, no cache in place: 58.11
Powerburst enabled, accurate cache: 19.47
Loading the file from the Powerburst cache was approximately twice as fast
as the initial RAS load. However, this was a best-case scenario. When we
randomly added and deleted throughout the document, the client load time shot up
to 46.38 seconds because most of the file needed to be reloaded. When we
significantly changed only the second half of the file and then only the last
fourth, the load time stayed in the same neighborhood--51.87 seconds and 46.93
seconds. The extent of changes didn't make much difference in the reload time.
In all fairness to Powerburst, focusing a test on the loading of a single,
stream-oriented file is not a reflection of real-life performance. In real life,
you work with a variety of files with several application processes. However,
this test clearly shows the best and worst that Powerburst offers. You won't get
best-case--or worst-case--performance from all your remote-access applications.
Real-life experience will fall somewhere between these extremes.
In the Right Direction
Does the fact that you won't get 100% performance improvement 100% of the
time invalidate the usefulness of Powerburst? Not at all. With repetitive work
using file-based applications such as Word for Windows, Lotus 1-2-3, Microsoft
Mail, and dBASE over a remote link, this product will improve performance.
Even if you average only a 50% improvement, that's still a 50% advantage
over a regular RAS link. Clearly, that's a step in the right direction.
End of Article
Register
