Home » Developer & Programmer » Forms » performance tuning
| performance tuning [message #83742] |
Fri, 05 December 2003 00:31  |
isha
Messages: 3
Registered: August 2002
|
Junior Member |
|
|
hi
can anybody tell something about performance tuning and
how can we improve the performance of a form...
thanks
isha
|
|
|
|
| Re: performance tuning [message #83751 is a reply to message #83742] |
Sun, 07 December 2003 00:57  |
Parul
Messages: 6
Registered: May 2002
|
Junior Member |
|
|
What Is Performance?
Before setting out to improve performance, it’s helpful to have a clear view of
specific goals, and what is involved in achieving them.
You need to be precise about what areas you want to improve, and how
performance in those areas is perceived or measured.
Additionally, improving performance can involve understanding the many
interrelationships and dependencies in today’s computing environment, the costs
involved, and the trade-offs that may occur in improving performance in one area.
Performance When?
The use of Forms Developer and Reports Developer is divided into design time and
runtime. Design time, when programmers are building the applications, is not
usually a concern in terms of performance. It is runtime — when the applications
are being exercised by multiple end users in the daily business environment — that
is almost always the main concern. As a result, the rest of this chapter focuses on
performance in the runtime environment.
Performance of What?
There are many ways to view an application’s performance. Its storage
requirements, its coding efficiency, its network loading, and its server usage, are just
a few areas. Every situation is different, and every site and department will have its
own set of priorities and its own view of which performance area is most important.
In addition, "good" and "bad" performance in these areas are relative things. There
are rarely any absolute standards.
Often the most visible area is performance in terms of response time for end users
(that is, how long people using the application must wait after making a choice or
entry). Here, too, there are no absolute standards. No matter what the actual
response time, users will have an opinion — which will depend in part on what
Reduce start-up overhead with pre-loading
Use just-in-time compiling
Increase Tier 2 hardware power
Use multiple Tier 2 components (Web Application Server)
Performance Suggestion Explanation
Guidelines for Building Applications
they are accustomed to and what their expectations are. Real numbers are
irrelevant. If end users are not happy with the response time, then that area is
certainly a candidate for improvement.
3.2.3 Interrelationships
Applications do not run in a vacuum. In a client/server environment, the
application is dependent on two underlying hardware and operating system
configurations, plus a hardware and software network connection. In a three-tier
environment, the situation is even more complex. In addition, the application is
interacting with one or more database servers, and may also be calling other
software components as it runs.
Further, an application is often sharing these hardware and software resources with
other applications. Because of this sharing, an application that is efficient in itself
can be adversely affected by other inefficient applications.
Performance of an application, then, is not just a result of its own design and
usages, but a very complex result of the combined interactions of a great number of
different components and factors.
Trade-offs
Some improvements in performance are straightforward and purely beneficial.
Eliminating useless code in an application would be an example.
Other improvements might not be so clear cut, however. For example, giving one
application a higher network priority by necessity lowers the relative priority of the
others. As another example, we might restructure a database to improve access time
for one type of application, but find that we have actually degraded access time for
other important applications.
At the single application level, a classic trade-off is space versus speed. We might be
able to decrease our main storage requirements by off-loading some components,
but that would most likely degrade the application’s response time (since those
components would need to be loaded when needed). On the other hand, we might
move the loading operations into the start-up phase, which would improve later
response time, but at the cost of higher initial start-up overhead.
Before deciding on any particular improvement effort, it’s helpful to understand the
broader implications, and make choices according to your priorities.
Measuring Performance
How do we tell if our applications are performing adequately?
In the case of response time, the opinion of our end users is paramount. But in
other areas we would like more tangible data; some hard numbers.
Forms Developer Specific Measurements
The Ora_Prof built-in package is distributed with both Forms Developer and
Reports Developer. It allows you to examine the PL/SQL in an application, and find
out how much time a specific piece of code takes to run.
The following product-specific measurement tools are also available.
Forms Measurements
You can obtain general information about a Forms application by setting the
runtime option STATISTICS=YES.
PECS
You can use Form Builder’s Performance Event Collection Services (PECS) to gather
more detailed information about an application’s runtime behavior.
You activate the PECS data collection by specifying the runtime option PECS=ON.
The simplest use of PECS is to collect application-wide statistics. This does not
require any changes to the existing application (only the activation of PECS via the
runtime option).
PECS also allows you to focus on specific areas in your application. PECS provides
you with a number of built-ins that you can insert into your code to identify
sections or events or classes that you want to examine in detail.
Once the data has been collected, you can use the PECS Assistant to view and
analyze it. The Assistant produces various types of reports that let you see such
things as elapsed time, CPU time, events or occurrences reached, usage of your
PL/SQL code, and so forth. Your analysis of the application’s runtime behavior can
help you spot potential areas for improvement. For example, some section of code
might be taking considerably longer to execute than the others, and would therefore
be a candidate for closer investigation.
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 12:33:52 CDT 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
