Slow Opening and Saving Reports on Network

Archive for File-Open

If File-Open is slow on a network, it may be because you are running Win 2000 or XP on a workstation. These operating systems communicate very slowly with a Win 2000 server and even slower with a NT server. In such cases, you may need to archive your reports by year in TRADATA\DATA so that there will not be as many reports in the directory you are trying to open. This in turn may require that you rebuild the index. Alternatively, you may try using the File–Index rather than File–Open to open the reports. But the speed problem will still exist when you save the reports. 

The most probable solution however is probably to be found in the Microsoft section below. The OS system is probably the culprit and affects our software because we have a lot of files in the directory on the server, and the OS does a poor job of communicating when there are a lot of files in a directory. Microsoft has acknowledge this problem is their OS, but a solution preformed at their OS level is not something with which we assist. Rather, since it involves a registry tweak, it is something you should have your on-site technician do. We provide the Microsoft information below for your technician’s consideration.

 

Local Operation for File-Save

You should also make certain that TRA and TRAPRIV are set for local operation in TRA.INI (and that TRAPRIV is kept relative clean with AIFILES).

  1. Click Start–Run
  2. Type: tra.ini and click OK.
  3. Hit F3 and then in the find box type: DIR
  4. Click Find Next and then close your find box
  5. Scroll down under directories
  6. Make sure that TRA and TRAPRIV are set to run on the C drive.
  7. Further make sure that the mapped drive for TRADATA is to a root directory on the server.

 

Virus Scans and Background Applications

In order to make sure there is nothing on the system or server, causing the slow down,

  1. On the workstation
    1. Turn off your virus software on the workstation and test the file-open/save time.
    2. If this works, then try changing your scan properties. For example in McAfee’s Vshield, Properties–Program–Configure–Detection, try disabling the scan on files you run (etc) and pinpoint what aspect of the scan is causing the slow down.
    3. If this does not work, then shut down background processes to make sure there is nothing running in the background causing the problem. One way to do so would be to reboot in safe mode with network support and then test the file-open/save time.
  2. On the Server
    1. Check System Properties–General, make sure it says Win 2000 Server
    2. In case the problem is due to user restrictions, try setting the user log in on the workstations to Administrator and test the file-open/save time.

 

Beginning of Microsoft Section–Probable Solution

Microsoft Solutions

Microsoft has acknowledged this problem, and you may have your technician consider the following information. Again, this information is provided for your technician’s consideration. Increasing the size of the buffer will make XP and W2000 Servers run more palatably. Running REGEDIT will allow you to change the buffer size. This is not something we support in our tech support, nor is it something we would advise you to do yourself. Your on-site technician can try the MS suggestions and take the appropriate safe guards such as backing up the registery.

 

DETAILS:

Suggested solution to the difference in the way Microsoft XP and Windows 2000 handle the FAT tables (as opposed to Windows 9x). Here is an excerpt from supplied by a tech in the field dealing with our software. If you do a GOOGLE search on SizReqBuf, you will find additional information from Microsoft sites. See two samples below the following details.

 

Default value is 4096 with a range of 0-65565 Decimal. Setting to 29128 and it seems to be a good balance between 2000/xp machines and 95/98 machines. Do the following on NT4/Win2k servers with the share folder with many files (e.g., \\server\photomgr\jpg or \\server\tradata\data:

1.      Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

2.      On the Edit menu, click Add Value, and then add the following registry value:

    1. Value name: SizReqBuf
    2. Data type: REG_DWORD
    3. Radix: Decimal
    4. Value data: 14596

 

 

MS: Remote Directory Lists Are Slower Than Local Directory Listings (Q177266)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q177266

To work around this issue, use the following steps to edit the SizReqBuf registery value:

  1. Start Registry Editor (Regedt32.exe).
  2. Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

  1. On the Edit menu, click Add Value , and then add the following registry value:

Value name: SizReqBuf
Data type: REG_DWORD
Radix: Decimal
Value data: 14596

Data : 512 - 65536 (bytes in decimal) Default : 4096 NOTE : A SizReqBuf value setting of 14596 works well in most standard Ethernet environments. However, the best value to use in a given environment depends on the specific configuration of that environment. The minimum SizReqBuf value setting is 512 , the maximum SizReqBuf value setting is 65536 , and the default SizReqBuf value setting is 4096.

  1. Quit Registry Editor.
  2. Restart the computer.

MS: Slow File Write from Windows 2000 to Windows NT 4.0 Server (Q279282)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q279282

  1. Start Registry Editor (Regedt32.exe).
  2. Locate and click the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

  1. On the Edit menu, click Add Value, and then add the following registry value:

Value Name: SizReqBuf
Data Type: DWORD Value
Radix: Decimal
Value: 65535

  1. Quit Registry Editor.
  2. Restart the server.

After you make this change, the performance of the write process is approximately the same as a read operation between the two computers. Note that the SizReqBuf value controls the buffer size for CORE SMB requests. Setting it to 64 KB has approximately the same effect as Large Write support, which uses 60-KB buffers.

 

 

XP Slow Even on Standalones

It has also been noted that when you upgrade a Win 98 to a XP, it retains its FAT32 subsystem, which is 50% slower than installing XP from scratch on a new system with a NTFS subsystem. So a new machine running XP on NTFS may be expected to run 50%, with all things else being equal. To check which file system you are using, open Windows Explorer. Right click on the C drive and left click Properties. The file system will either say Fat32 or NTFS. Other factors would include making sure you have plenty of ram (such as 512mb) and a fast hard drive (such as 7200rpm). One customer stated that Appraise-It would slow down whenever sending or receiving faxes, but when they plugged the fax machine into a different outlet other than that used by the power strip, Appraise-It functioned at normal speed. So adequate power supply and reduced background applications would also be considerations.

 

End of Microsoft Information–and end of probable solution

 

ADDITIONAL INFORMATION:

XP and 2000 use a VFAT system (Virtual File Allocation Table) as opposed to standard FAT that 9X uses. There are several differences in how the two tables are defined (mostly in information stores, name length and OS compatibility) The VFAT file system is a Linux-based file system that is compatible with Windows 95 and Windows NT long filenames on the FAT file system Windows 95 and Windows NT support VFAT. Technically, VFAT is not a new File System. It uses the same directory structure, format, and partition type as ordinary FAT. VFAT is simply a way to store more information in the FAT directory. The most important feature of VFAT is the ability to store long file names. Since it is built on ordinary FAT, each file has to have an 8 character name and 3 character extension. However, VFAT then allocates additional directory blocks to hold a longer file name. Programs running in DOS, OS/2, and Linux (and old 16-bit Windows programs) will not see the longer file name. Only WIN32 programs running in NT, 2000, XP or Windows 95 can make use of the longer name. Because VFAT uses the old FAT directory to add some unusual new entries, the VFAT additions can be damaged if the disk is manipulated by a DOS or OS/2 disk utility that does not understand the new structure. Even a simple DEL command under OS/2 for a FAT dataset with a long file name can leave the extra blocks in the directory. The Windows 95 SCANDISK utility can be run later to audit the VFAT structure and delete the extra directory blocks for files that no longer exist.

Protocol for File-Save

The following speculative information for NETBEUI is supplied with skepticism.

We have had customers using Appraise-It on a P2P network who changed the network protocol to NETBEUI file sharing and then claim that the reports would then save in normal time span rather than taking one to two minutes. Admittedly, TCP\IP is generally the preferred protocol rather than NETBEUI for true client-sever networks (or P2P) in which you are accessing the Internet.  But NETBEUI is faster for file sharing.  Ideally then, you could set up your network to use both protocols. Use NETBEUI for the file sharing (and TCP\IP for the internet access) so that when Appraise-It saves the file it will be using the NETBEUI protocol.

 

If you still have problems using NETBEUI (or TCP\IP), then have your technician test the hardware (i.e., the hub, wiring, cards) to make certain they are still functioning at full capacity. Of course, ideally you would have a dedicated client server rather than P2P.  If your technician will do a search in google.com for “slow network performance,” he will find numerous articles pertaining to this problem. But we have found no article at this time that resolves the problem for our software and would thus suggest you call Microsoft if a solution is not attainable with NETBEUI protocol.

 

A windows 98 workstation will communicate normally across the network, but the NT, 2000, and XP communicate very slowly with our software. The OS makes the difference so discussing this with MS would be advised. The problem may be due in part to the fact that our application is 16bit and has thousands of reports in the data directory. Emulation mode may help with the 16bit application limitation and archiving with the number of reports in the data directory.  See our faxes concerning emulation and archiving.

 

Other suggestions from the field include: not using NOVELL, using ntfs rather than something like fat or fat32 for the hard disk file structure, be certain you have 100 mbit connectivity throughout the network.