Kbase 10804: Checklist for Client Performance Fine Tuning (Programming & Startup Parameters
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/11/2010 |
|
Status: Verified
GOAL:
Checklist for Client Performance Fine Tuning (Programming & Startup Parameters)
GOAL:
How to improve client performance
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Versions
FIX:
The performance of a system is a function of both the application and the system on which the application runs. Although the distinction between the application and system performance is somewhat arbitrary, application performance depends on code design and programming techniques, whereas system performance depends on the Progress product design and any inherent system limitations of the hardware, operating system, and network.
Examine the application design and coding, memory, disks, CPU, and network management. Maximum performance is accomplished through better resource allocation, better programming, and better database design.
Application design for maximum performance should focus on the following:
- Indexes
Make sure the right ones have been defined and that when you retrieve records, you use selection criteria (WHERE clause) that makes use of an index. Record selection that uses "OR" or "MATCHES" does not use an index. Record selection that skips a field in a multi-field index also does not use an index.
For example, if you request records that have a middle name of "Mary" when the index is made up of last_name, first_name, and middle_name, Progress has to read each record to answer your query. Use COMPILE with LISTING and COMPILE with XREF as a tool to analyze your code.
- Transaction scope
Keep the transactions small. This minimizes the .bi file writes, and ensures records that are part of a multiple user application are not locked for too long.
- Minimize I/O
Interaction with peripherals is inherently a slow activity. For example, if you need to display a counter during a repetitive process, you might choose to update the counter every 100 records rather than with every iteration.
- Use NO-UNDO on program variables when you DEFINE them
Program variables are written to the local before-image file (.lbi) if Progress needs to keep track of their interim values.
- Avoid recursion to minimize the stack management activity of the CPU
- Calls to the operating system in some environments require a memory management task that can slow down the application
If there is a way to accomplish the action without escaping to the OS, you should consider that alternative
- Use HIDE and VIEW to minimize the number of active frames and reduce CPU consumption
- Limit the use of GLOBAL variables to reduce R-code program size
Don't declare the entire application's list of global variables in one include file and {include} it everywhere - declare only the ones you need in the child procedures
Memory management can be accomplished by making changes to the operating system and/or memory startup parameters. Examine each of the following startup parameters in turn:
- Directory size (-D)
If -D is set too low, an unexpected recompiling (of session compiles) and/or reopening/rereading of .R code files occurs. In general, raising -D keeps commonly used .R files in the .srt file, thus saving search/move/open operation overhead.
- Maximum memory (-mmax)
If you have large procedures or deeply nested procedure calls, you can use -mmax to increase the initial size of the execution buffer to reduce disk I/O activity required to swap segments to the sort file.
- Local buffer size (-l)
If you increase the local buffer, you can effect a modest performance gain because this lowers the frequency with which Progress consolidates free space in the buffer.
- Stack Size (-s)
The size of the stack (an internal memory area used by Progress program modules) in 1K units. This parameter is used to avoid stack overflow errors that occur most likely when data definitions are load.ed for very large tables or use recursive programs.
- Speed Sort Startup (-TB) and Speed Sort Merge Number (-TM)
If you must use un-indexed field sorts (such as the sorts in work files), the -TB and -TM options speed up the sorting process. The -TB option controls the size of the blocks Progress sets aside for sorting.
The -TM option controls how many of these blocks can be merged at one time. These sort options are particularly important when you do an index rebuild (PROUTIL).
Disk management helps to spread the I/O work that your hardware has to do. Better use of your existing hardware also improves performance. Consider the following options:
- Quick Request (-q)
By using the quick request option, you avoid a search of PROPATH each time procedure is executed with a RUN statement. This option is useful once an application is in production and the .p source code files are stable.
- Temporary Directory (-T)
Disk arm contention is reduced if temporary file writes are made to one or more disks away from the .db, AI and/or BI files. If the disks are independent channels, parallel disk I/O can improve performance considerably.
- Buffers for Temp Tables (-Bt)
Allocates a buffer in memory to store TEMP-TABLE's. TEMP-TABLE's will only be written to disk once the size of your TEMP-TABLE's is larger than the area allocated by -Bt. -Bt is 10 by default, which is too small for most applications (especially SmartObject ones, which rely heavily on TEMP-TABLE's). If you have memory available, consider increasing this parameter.
Networking options to consider:
- Message Buffer Size (-Mm)
If your database records are large, increase this parameter to avoid record fragmentation. However, if the network works more efficiently with small messages, reduce -Mm and fragment larger records. If you change the -Mm value on any database command, you must change all the client connections (-Mm value) to that specific Database to have the same Message buffer size in both sides (clients and server).
- Schema Cache File (-cache)
This parameter is used to reduce connection time when the client connects to a database over a wide-area network WAN. Progress stores the schema cache as a binary file, called a schema cache file, on a local disk. The client can then read the schema directly from the schema cache file. This parameter should be used when a large number of clients connect to a database simultaneously. For example, after a database shutdown and/or crash.
.