Kbase 11434: NLM Performance Enhancement Suggestions: V6.x and V7.x
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  16/10/2008 |
|
Status: Unverified
GOAL:
How to improve NLM Performance.
FACT(s) (Environment):
Progress NetWare Loadable Module (NLM)
SYMPTOM(s):
Maximize the performance of your hardware and Progress-based application.
FIX:
Some suggestions to enhance the Progress NetWare Loadable Module (NLM) for Novell NetWare networks to maximize the performance of your hardware and Progress-based application.
The following list deals with Progress versions. Make changes as appropriate for your network configuration:
- Make sure you are using Version v6.2M15 or later (including Version 7.x).
- The _MPROSRV NLM is no longer supported in Version 6.x. You must use _MPROTLI -N TLI when you start your NLM server. In Version 7.x, _MPROTLI has been renamed back to _MPROSRV and the -N startup parameter is disabled (it automatically defaults to TLI).
Sample Progress Version 6.x NLM load line:
LOAD SYS:DLC\_MPROTLI VOL1:\DATA\CUSTOMER.DB-S ACME -N TLI
Sample Progress Version 7.x NLM load line:
LOAD SYS:DLC\_MPROSRV VOL1:\DATA\CUSTOMER.DB -S ACME
- Verify that you are running the latest versions of the following files:
- IPX (Version 3.10)
Progress highly recommends the use of ODI drivers because Novell no longer supports monolithic IPX/SPX.
- Driver for your network interface card (consult your hardware vendor).
- LSL.COM (version 1.21 or later).
- IPXODI.COM (Version 1.20 or later).
- NETX.COM (Version 3.26A or later).
- If you are using a windows client, make sure you have the latest Novell Windows drivers:
vipx.386, vnetware.386, nwipxspx.dll, and netware.drv
The following lists startup parameter considerations:
- Do not use the -yield startup option when you load the Progress NLM. The -yield option explicitly relinquishes control to NetWare and places the NLM in a "sleep" mode in which it is not using the CPU to listen for incoming packets. There is no need for -yield with the TLI NLM.
- You might improve performance if you increase the number of database buffers via the -B startup option when the database loads.
The ability to increase this startup parameter to a large value is one of the benefits from the way the NLM uses the file server memory space. Database buffers contain commonly accessed database blocks in RAM.
Keeping data in memory limits input and output to the disk and often results in performance gains. The size limit to the -B parameter depends on a number of variables:
- The amount of RAM in the file server.
- The number of other NLMs are loaded on the system.
- The number of users that access the Progress NLM.
- The level of general file server use.
Determining the most efficient value for your -B requires some trial and error. Try different values, track the results, and implement the value that yields the best results.
NOTE: Increasing -B can also degrade the performance of the NLM and the file server in general. Progress checks for data in database buffers before it goes to the disk for the data.
If the data that is requested is not commonly accessed, the data probably is not located in the buffer. Time has been spent searching the buffer before the data is found on disk. The larger the buffer, the more time is spent.
Database buffers are measured in units of 512 bytes. Divide the value of -B to determine the number of KBytes the buffer setting occupies. Also, keep in mind that as your database grows, you might want to increase -B proportionally.
Resource use considerations are as follows:
- Consider what other activity is taking place on the file server.
This means looking at how many applications the file server is servicing (other third party NLMs, applications like Windows being run off of the server, Multiple Name Space NLMs, etc.), how many users are on the system, and the level of non-Progress related disk I/O.
For example, if there is a significant amount of activity on the system and the file server has only 8 MB of RAM, you might want to consider a relatively modest investment in additional memory. The amount of RAM and disk space you need is a function of the activi.ty level on the server and your expectations for performance.
Use the "MODULES" command to view the NLMs that are running.
- Another consideration is the number of times the Progress NLM is being loaded.
If you load the NLM against more than one database, consider whether you set a large value for -B and is that value necessary for both databases. Is it possible to lower -B for the database that is not as mission critical so that the other database can have a lot of buffer space allocated to it.
- Placing relevant files on separate disks might also increase performance.
This means placing the .db database file, the before-image file, and the application r code on separate disks. In such a configuration, one disk does not carry the burden of reading the application r files, writing to the before-image file while it reads and writes to the database file.
NOTE: The r files refer the compiled versions of Progress procedures that have a file extension .r.
- It might be effective to upgrade to a more powerful CPU in the file server.
- You might consider dedicating a NetWare file server to run just the Progress NLM if performance is especially important. (This should not be necessary in most cases.)
If you decide to dedicate a NetWare file server to the Progress NLM, you can further enhance performance by disabling the NetWare Transaction Tracking System (TTS) via the DISABLE TTS file server console command.
TTS thus becomes a redundant fault tolerant feature because Progress uses before-imaging.
NOTE: Other applications might require TTS. It should be disabled only if you are sure other applications that the file server services do not require TTS, or if Progress is the only application running on the system.
Client considerations for performance enhancement are:
- Make sure DOS clients run in protected mode.
While in protected mode, Progress can run on machines with only 2 MB of RAM. Some base memory is needed to run, however, that degrades the performance of the client executable on such machines. It is best to have more than 2MB of RAM in machines that run the protected mode implementation of the Progress client software.
Progress for Windows client software slows all Windows applications on machines with less than 4 MB of RAM.
- Use the -T startup option to place client temporary files on a local disk to minimize network traffic.
By default, Progress places the temporary working files that exist for the life of the session in the your working directory. The directory usually is on one of the file server disks.
If you run the Progress for DOS client software, the working directory is the directory from which Progress is started.
If you run Progress for Windows, the working directory is specified in the "Working Directory" field for the properties of the Progress icon..