From: hamilrk1@bisdpo1.bisdnet.jhuapl.edu ()
Subject: RE: Performance Problems with File Services
Reply-To: hamilrk1@bisdpo1.bisdnet.jhuapl.edu ()
Organization: Johns Hopkins University Applied Physics Lab
Date: Mon, 5 Oct 1992 17:36:55 GMT

Mike,

>Hello all.
>Here's an update.
 
>The server's memory has been upgraded from 16Mb to 48 Mb. After 
>readjusting the memory, caching parameters we found that there was no 
>observable improvement

Ok.

Just a quick note here .... If by "caching parameters" you mean the open 
file caching mechanism built into PATHWORKS .... I believe that the actual 
caching of open files by the PCFS_SERVER process does not include 
sharing with other processes. The open files are cached exclusively for 
the PCFS_SERVER process for the duration of the open file caching timer 
(this is default of 15 seconds). Any requests from other processes for 
files in the cache will result in conflicts due to the exclusive locks. This 
is just fyi and may not be a problem for you. We share several file 
services between PATHWORKS for DOS and PATHWORKS for Macintosh on 
the same system. Turning on the open file caching was a disaster as the 
Macintosh file server could not access any files cached by the 
PCFS_SERVER process ....
 
>Further monitoring showed that the bottleneck seemed to be disk io with 
>respect to the access of the service database that happened to be on the 
>system disk.

This seems reasonable as the PCFS_SERVER process does a tremendous 
amount of Direct and Buffered IO ...

>The DEC guru who was helping us could not understand why this was 
>happening So as a work around, a RAM disk was installed on the server 
>and the service database was moved there. Immediately, the file service 
>performance improved to what has been described in previous postings 
>to this list server.

Sounds like a clue to the problem. We are about to test the Executive 
Software package I/O Express for the same reasons that you have set up 
this ram disk. We have a VAX 4000-60 which does nothing but 
PATHWORKS! Nice to be able to tune a VAX for just a single application!
I will post again on the results of using this I/O package ...

So far we have noticed that loading applications from file services is 
slow enough to cause our users to complain. 

Using LANSESS instead of DECNET certainly solved all the performance 
problems. Our Network adminstration frowns on the use of bridged 
protocols and we decided that LANSESS could not be a solution. DECNET 
was chosen as the network transport. If you can use LANSESS instead of 
DECNET then this might just solve all of your problems. Give it a try!

On our network using DECNET as the transport, investigation with a 
network sniffer showed lots of retransmissions! The VAX was too fast 
for our clients (IBM PS/2 Mod 55SX, COMPAQ 386 20 Mhz with 3C503's). 
The release notes for PATHWORKS for VMS V4.1-1 suggested reducing the 
DECNET EXECUTOR Pipeline quota to around 2300-3400 to reduce the 
possibility of Server overruns. Read the release notes for a full 
explanation. We have seen a performance improvement with this change 
but are still not satisfied with the overall performance.

Some other things that you might want to try in conjuction with the 
Pipeline quota on the VAX are:

1) On your clients try reducing the RECEIVE and TRANSMIT PIPE QUOTA 
down to "2". You do this from NCP on the PC Client ..... This has a similar 
effect as the pipeline quota on the Server. The whole idea to to slow down 
the transmissions to reduce the chance of data overruns.

2) On your clients try enabling DECNET Flow Control. This is done by using 
the following switch on the DNNETH.EXE image:

   /fc:1

Add this switch to the line in STARTNET.BAT which invokes the 
DNNETH.EXE image. This forces DECNET to use flow control and reduces 
the possibility of data overruns ... Again, we have had some success doing 
this. The down side is that more traffice is actually being transmitted on 
the network. This is because of the overhead associated with the flow 
control.

>My question is, and it may be a stupid one because I am no VMS whiz, why
>didn't the caching take care of this? Access to this file was read only,
>and the high io rate seemed to indicate that if anything was in the cache
>it would be the the service database. Setting up a RAM disk in this case
>has merely served to provide the equivilant of a dedicated chunk of cache.
 
Again, if the "cache" is the PATHWORKS open file cache ..... It might only 
cache open files for a specific user of the PCFS_SERVER. This is unlikely 
and even silly to suggest .... but it might be worth looking into ..... 
Otherwise you would expect that the open file caching would have the 
same effect as your ram disk ....

-BobH
 

 
 
 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Robert K. Hamilton            hamilrk1@bisdpo1.bisdnet.jhuapl.edu         
Johns Hopkins University  Phone: (301) 953-6068
Applied Physics Lab          FAX  : (301) 953-1093
Bldg. 9-163
Laurel, Md.  20723-6099
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+