KB#00275-Addressing performance problems with the TCP/IP Client and the Data Server
Addressing performance problems with the TCP/IP Client and the Data Server
Opening the first file via the Data Server will be a little slower than subsequent file opens due to the overhead of initializing a TCP/IP connection between the client and server. This is mentioned in the Data Server manual, and a workaround exists. Keep one file open via the Data Server in order to keep the connection established and bypass the lengthy first open. Here are some results of a test using a program that opens and closes the same file 1000 times:
23 Seconds--Via Mapped Drive (re-establishing the connection each time)
739 Seconds--Via Data Server (re-establishing the connection each time)
5 Seconds--Via Data Server with connection already established
(by keeping one other file open all the time)
These results show that the first open is *extremely* costly, but that it is possible to make the Data Server even faster than a mapped drive.
Many BBx applications start every program (main, called, everything) with a BEGIN statement. This has the nasty little side effect of closing any connection that you may have been trying to maintain with the Data Server, as mentioned above.
Note: Rev 2+ of the Vpro5 Client has a new mode called "persist" - see on-line documentation that ships with product for details and usage. This new mode maintains the connection to the data server when a BEGIN statement is encountered. In rev's prior to 2+ , the only workaround is to modify the code, an example follows:
1) Have the first program open a file or directory via the Data Server on a channel that will not be used later (3200 for this example).
2) Replace BEGINS to a call to a public program (called CLEARFILE for this example).
10 CLEAR; CALL "CLEARFILE"
Where CLEARFILE is similar to:
0010 REM "CLEARFILE--Close ALL channels except 3200"
0040 IF SHOWIT<>0 AND SHOWIT<>3200 CLOSE(SHOWIT)
0050 IF A$>0 GOTO 30
If the first open via the Data Server takes longer than a couple of seconds, it indicates that the network is not configured optimally. Note that in the code example at the top, the first open averages .739 seconds - slower than normal but still quite fast. If the first open takes much longer than that, it indicates a problem. This is not a problem or bug with our software, and can be fixed by ensuring that the TCP/IP stack and its associated functions are configured correctly.
Possible reasons why the first open takes longer than a few seconds:
a) TCP/IP is bound to both a NIC and the dial-up adapter. In this case, the dial-up window doesn't appear when opening the first file, but rather the dial-up connection is attempted first and eventually times out. After the time out, it then attempts to connect via the NIC. At this point, usually *several* seconds later, it works.
b) DNS is improperly configured. We've seen this occur where name/IP resolution is attempted via DNS. If this is setup wrong, it eventually times out a long time later. After the time out, it can drop back to resolution via the hosts file. If this is setup right, the TCP/IP stuff will work, but again only after a very long time.
c) DNS is not configured to do both Name and Reverse Name lookups.
d) This has been seen before when the Data Server was started with logging turned on, and the log file was very large. After removing the log file, the performance improved.
In the above scenarios, the first connection is very slow - from 10 seconds to over a minute. However, it eventually *does* work, and subsequent opens are very very quick as it uses the established connection. The lengthy delay indicates that the TCP/IP stack is not configured optimally, and should be investigated.
Last Modified: 01/05/1999 Product: PRO/5 Data Server
BASIS structures five components of their technology into the BBx Generations.