Consultor Eletrônico



Kbase 1251: How to optimize performance -system and Progress application
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   11/13/2001
How to optimize performance -system and Progress application

900531-slk01


INTRODUCTION: Date Last Modified: 6/26/90
=============

This Product Services Technical Support Knowledgebase entry describes
how to debug system and application performance problems.


WHY YOU'LL NEED TO DO THIS:
===========================

There are many different areas that you can look at when debugging
performance problems. Depending on your circumstances, you may
need to look at all areas or just one.


PROCEDURAL APPROACH:
====================

I. Accessing Records
-----------------
If the performance trouble is related to how long it takes
to retrieve records, investigate the following areas:


1. Check to see that you use an index on the FIND/FOR EACH
statements. See the PROGRESS Reference Manual (FIND and
FOR EACH section) for a description on how PROGRESS selects
an index.

2. If the database is large (or greater than 8mb on DOS),
making the database a multi-volume database can help
problems with disk access. Moving the before-image
file (-g startup option) to another disk also helps.

3. Try increasing the -B (PROGRESS buffers) startup option
on the server or single-user session. Usually, the larger
the buffers are, the greater chance of finding the record in
memory, rather than having to go to disk. The PROGRESS promon
utility option #3 (Block Access) helps determine if this is an
area that can be changed to help performance. See the
PROGRESS System Administration Guide for more information on
the promon utility. There is a tradeoff between increasing
the -B and taking up more RAM - see Section III of this
document for details.


II. Takes a Long Time Getting From One Procedure to Another
-------------------------------------------------------

If you notice a significant delay in running procedures, here are
some areas to look at:

1. Check if the procedures are compiled.

- Once procedures are compiled, PROGRESS only needs to
do a "schema cache" the first time the procedure is brought
into memory. Then runs of that procedure are much
faster. The -y startup option, can help you determine
whether you are running uncompiled procedures. This option
was introduced and documented in version 6 of PROGRESS but
is also available in version 5. The -y startup option writes
statistics to your log file during your PROGRESS session.


2. Network environment (e.g., DOS/LAN or BTOS)?

- Make sure the compiled procedures (.r's) are local to each
user's workstation. It can take a significant amount of
time to transfer .r's across a network each time a user runs
another procedure.

- On DOS/LAN, it may be helpful to increase config.sys
buffers on the database engine.

- Keep temporary files local to each user's workstation.
Use the -T startup option to relocate temporary files.

III. Inconsistent "Drops" in Performance or Consistently Slow
--------------------------------------------------------
This is usually indicative of memory/swapping problems. Here are
some places to look:

1. PROGRESS startup Options on the Server (proserve):
-B, -s, -c

PROGRESS startup Options on each Client (mpro):
-e, -l


- Each of these parameters take up RAM. There is a tradeoff
between the value of these parameters and how many users
you require to be running with the amount of RAM you have
on system. For example, if you have 16mb RAM total on
system, and have the following set for PROGRESS:

proserve dbname -B 8000 (8mb RAM for -B)

mpro dbname -e 500 -l 500 (1mb additional for each user)


and you require that 20 users run PROGRESS, there will
probably be some swapping or paging activity on the system.

For default startup, the server and first user usually
require 1.5 mb of memory and an additional 1mb for each 2-3
users after that (on UNIX).


2. Run System Reports to debug swapping or paging problems
( S.A.R.'s, vmstat, or iostat). You should look for the
number of swap outs or page outs. If this number is
consistently high, or tends to increase rapidly and then go
back down, you probably are swapping or paging. In this case,
you can attempt to decrease PROGRESS startup options,
decrease the number of users, or add more memory.


ONLINE PROCEDURES OR UTILITIES:
==============================

PROGRESS Database Monitor: promon


REFERENCES TO WRITTEN DOCUMENTATION:
====================================

PROGRESS Reference Manual - FIND/FOR EACH - index rules.


PROGRESS System Administration - Chapter on the PROGRESS Monitor
(PROGRESS version 5)

PROGRESS System Administration II - Chapter on the PROGRESS Monitor
(PROGRESS version 6)

PROGRESS System Administration - Chapter on Startup and Shutdown
(PROGRESS version 5)

PROGRESS System Administration II - Chapter on Startup Options
(PROGRESS version 6)

Progress Software Technical Support Note # 1251