Performance Tuning of a Progress application can happen at several different times: as
part of the development and release cycle, as part of a capacity
planning project, or (unfortunately, most often) when a visible lack of
performance impacts a production activity. You can avoid the
production impact by tuning earlier.
Some examples of production impact which commonly stimulate a performance tuning engagement:
Response times within the customer-facing application become unacceptably slow.
Nightly
operations such as reports begin to run over the available time, either
not completing at all because they must be terminated, or impacting
morning production until the jobs finish.
Data accumulations or new application or software releases cause a drop in performance.
Many
companies faced with these issues "throw hardware at it," i.e. spend
more and more money buying larger and larger systems. This solution is
both expensive and temporary! The correct solution fixes the problem
by making the code and database run efficiently.
Progress
databases and code are so easy to use and obliging that often
developers or DBA staff do not stop to consider whether a particular
configuration or structure is efficient... but then problems arise when
the application is scaled up. Progress does not have a problem scaling
-- many problems which are blamed on Progress or the underlying hardware
can be configured away or are indications of inefficient programming.
As
part of the Progress Consulting group I ran the Performance Tuning
Workshops and gave the related breakout sessions at Users Conferences
for several years. I gave the first-ever breakout session at a Users
Conference on the use of the Progress AppServer. I have focused on the
architecture of large-scale systems from many-processor centralized
machines and NUMA boxes to distributed systems of all sorts. And I am
nearing completion of a Masters Degree in Parallel and Distributed
Systems from Vrije Universiteit in Amsterdam, one of the few programs
of its kind in the world.
