Appeon 6.6 Prev Page Prev Page
Appeon Performance Tuning Guide
Appeon Performance
Expected performance level
Automatic performance boosting
Impact of the Internet and slow networks
Impact of “heavy” client-side logic
Impact of large data transmission
Performance-Related Settings
Appeon Developer performance settings
Appeon Enterprise Manager performance settings
Timeout settings
DataWindow data caching
Multi-thread download settings
Custom Libraries download settings
Log file settings
Internet Explorer performance settings
Web and application server performance settings
SAP Sybase EAServer
JVM startup option
Configuring data sources
HTTP properties
Microsoft IIS server
Recommendations for avoiding common errors on IIS
Advanced thread settings
Database performance settings
Recommended database driver
Recommended database setting
Identifying Performance Bottlenecks
Heavy window report
Appeon Performance Analyzer
Getting Started
Enabling Appeon Performance Analyzer
Starting Appeon Performance Analyzer
Getting to know Appeon Performance Analyzer
Removing Appeon Performance Analyzer
Working with Appeon Performance Analyzer
System Configuration
Calls Analysis
Download Analysis
View Detail
Additional Functions
Testing Appeon Web applications with LoadRunner
General Limitations on Performance Testing
Testing Environment
Testing Steps
Configuring AEM
Data Preparation (for update only)
Preparing Test Cases
Recording Scripts
Modifying Scripts
Additional steps for Update operation
Parameterization of SQL statements
Playing back Script to test the correctness of scripts
Setting Scenarios
Additional steps for Update operation
Running Scenarios
Modifying the scripts of NVO
Modifying the scripts of EJB/JavaBean
Errors appear when playing back scripts with LoadRunner 8.0
The value of sessionID is null
Error message appears in script playback
Error message in Appeon Log
Failed to parameterize scripts
Out of memory error and application server shut down
Field values do not change after parameterization and playback
Runtime errors causing scenario failure
Transactions failed
Unable to connect to remote servers
Analyzing log files
Analyzing Windows application log files
Analyzing Appeon Server log files
Analyzing active transaction log
Identifying Performance Bottlenecks of Web Server and Application Server
Identifying Performance Bottlenecks of DB Server
Deadlock analysis
Identifying Performance Bottlenecks of PB application
Analyzing performance bottlenecks of PB application
Tuning: DB Server
Tuning: Excessive Server Calls
Technique #1: partitioning transactions via stored procedures
Technique #2: partitioning non-visual logic via NVOs
Technique #3: eliminating recursive Embedded SQL
Technique #4: grouping multiple server calls with Appeon Labels
Tuning: Heavy Client
Technique #1: thin-out “heavy” Windows
Technique #2: thin-out “heavy” UI logic
Manipulating the UI in loops
Triggering events repeatedly
Performing single repetitive tasks
Initializing “heavy” tabs
Using ShareData or RowsCopy/RowsMove for data synchronization
Using computed fields
Using DataWindow expressions
Using complex filters
Using RowsFocusChanging/RowsFocusChanged events
Technique #3: offload “heavy” non-visual logic
Tuning: Large Data Transmissions
Technique #1: retrieving data incrementally
For Oracle database server
For all other database servers
Technique #2: minimizing excessive number of columns

Technique #3: eliminating recursive Embedded SQL

It's actually quite common to find Embedded SQL in a loop, especially Select and Insert statements. As explained previously, server calls that are recursive in nature are quite dangerous, potentially generating tremendous number of server calls. If your application requires loops or recursive functions, it would be best to replace any code resulting in server calls with code that does not.

For this technique, we will assume we have Select and Insert SQL statements in a loop. The general idea is to first create a DataWindow/DataStore using the SQL. Then replace the SQL statements contained in the loop with PowerScript modifying the DataWindow/DataStore, which does not result in server calls. If the SQL statement contained in the loop is an Insert statement, we would want to replace that with PowerScript that would insert data into the DataWindow/DataStore. Once all the data has been inserted, then in one shot we would update the DataWindow/DataStore to the database (outside the loop), resulting in only one server call. If the SQL statement contained in the loop is a Select statement, we would retrieve data into a DataWindow/DataStore before executing the loop, and then write PowerScript in the loop to select the desired data from the DataWindow/DataStore.

The following is a code example that increases the price of a specific order by 20%, where Embedded SQL is used to update the change row-by-row (hence the loop), and then save those changes to the database:

long ll_id

declare order_detail cursor for 
select id from order_detail where orderid = :arg_orderid;
open order_detail;
fetch order_detail into :ll_id;

do while sqlca.sqlcode = 0
        update order_detail set price = price*1.2
        where orderid = :arg_orderid and id = :ll_id; 

        if sqlca.sqlcode < 0 then
        end if
        fetch order_detail into :ll_id;
close order_detail;

Now we will replace the Embedded SQL with a DataWindow. Specifically, we will cache the data in a DataWindow and update the database with a single DataWindow Update, resulting in just once server call:

long ll_rows, i

ll_rows = dw_1.retrieve(arg_orderid)
for i = 1 to ll_rows
    dw_1.SetItem(i, "price", dw_1.GetItemDecimal(i, "price")*1.2)

if dw_1.update() = 1 then
end if

With this technique we have just eliminated server calls from inside the loop, reduced the number of server calls to just one, and created a data caching mechanism at the client-side that can be used to feed data to other controls of the PowerBuilder client.