Good afternoon, gents.

I've got a non-interactive BTrieve application. It basically parses
through a file and throws what it sees into the BTrieve database. Less
than 50 records get handled in all.

On the BTrieve server, it runs fantastically well, finishing in a virtual
instant.

When I run it remotely, I can count the seconds before it terminates.

Other applications run against this database feel somewhat laggy when run
remotely.

We have it running over TCP/IP. The applications are DOS-based (running
on Windows 2000). Which BTrieve DB server is used is determined by a
look-up of the mapped drive of the current directory.

What sort of things should I be looking for to improve performance?

I know the information in this e-mail is a bit light, but I'm not certain
what's relevant. Feel free to ask questions.

Above all, thanks for your time.

-Adam

Typically there are two or three issues that can cause bad
performance. By virtue of the fact that the application can be run on
the server and performs well there that eliminates general server
slowness.

Is is slow to connect or slow to run?
e.g. does it take 20 seconds to connect then process the records in an
instant or does it connect quickly then process the records slowly.

Try a
ping -l 1024 <servername>

If the stopwatch time from hitting enter to the address popping up on
the screen is a while it is probalby name resolution.

If it is the first, a slow connect, it might be caused by slow name
resolution. I mention 20 seconds because that is the default timeout
before windows tries a broadcast name resolution scheme. I have seen
even longer caused by an internal machine using an external (ISP) DNS
server which did not know about the internal server.
If this is the issue a hosts file entry should resolve it.

If the round trip times are > 10ms then there may be a
misconfiguration or just a slow link on the network.

If it is a slow to process perhaps the network is just slow.
The title kind of implies remote as in WAN, but not necessarily.
Maybe check a traceroute between the client and the server (and from
the server to the client) to see that nothing strange is going on.
e.g. a hop through the public side of an internet router (usually on a
slower link) can definitely cause slowdowns.

Leonard

On Mon, 19 Jan 2004 14:54:04 -0500, Adam Augusta <roxton (AT) wpi (DOT) edu>
wrote:

Thanks for taking the time to respond.

On Tue, 20 Jan 2004, Leonard wrote:
Certainly not 20 seconds. Although there have been delays of 4-7 seconds,
whereas on the server the results would be nearly instantaneous.

It's difficult to tell whether it's connection or processing because the
program runs autonomously. Visual indicators almost seem to suggest both,
because there's a 2-3 delay before it pops up a "Running..." message and
then another 2-3 seconds that the program sits on that screen.

< 10ms

I thought maybe it was trying and failing to use IPX, so I removed the
protocol from my network configuration. Didn't help.

Nothing truly odd. No WAN. The server is on a different internal subnet,
linked through a gateway server with multiple NICs. I'm pretty sure both
the client and the server are respectively running on 100Mbps switches.
We don't have problems with other services running on that subnet.

-Adam

On Tue, 20 Jan 2004 09:31:46 -0500, Adam Augusta <roxton (AT) wpi (DOT) edu>
wrote:

2-3 seconds almost sounds like a load delay.
There would not be one on the server as the requesters are already
loaded by the engine.

Is the application loading locally from the client or across the
network from the server?
Also are the requesters installed on the client machine?
Last but not least, what about the path? Does it include any network
drives or worse network drives that are no longer present?

On Wed, 21 Jan 2004, Leonard wrote:
The binary resides on the same server as the datafiles. I could try
putting the binary on the client, but I'm skeptical about the possibility
that my 100KB-200KB executables have a significant load time.

Sure.
Installed packages from:
pvsw\CLIENTS\WIN32
pvsw\CLIENTS\DOS\WINDOSBX (It's a DOS utility)

Would the application even run without requesters?

None that aren't present, but sure. The Btrieve data files themselves
exist on a mapped network drive. I set the data folder to be the current
(working) directory before running the program. The binary executables are
currently present on the same mapped drive in a different folder, which is
in the path.

Does the path matter in this case? Wouldn't the requester see the
datafile in the current directory and not even /bother/ with the remainder
of the path?

-Adam