Home
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
Overview
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
Overview
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
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
Appendix
Modifying the scripts of NVO
Modifying the scripts of EJB/JavaBean
Troubleshooting
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
Database
Tuning: Excessive Server Calls
Overview
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
Overview
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
Overview
Technique #1: retrieving data incrementally
For Oracle database server
For all other database servers
Technique #2: minimizing excessive number of columns
Conclusion

Advanced thread settings

The following settings are the most-Appeon-related settings in ASP.NET.

When you call an Appeon web application from IIS, you may experience contention, poor performance, and deadlocks. Clients may report that requests stop responding (or "hang") or take a very long time to execute.

This problem might occur because ASP.NET limits the number of worker threads and completion port threads that a call can use to execute requests. If there are not sufficient threads available, the request is queued until sufficient threads are free to make the request. Therefore, .Net will not execute more than following number of requests at the same time:

(maxWorkerThreads*number of CPUs)-minFreeThreads

Note: The minFreeThreads parameter and the minLocalRequestFreeThreads parameter are not implicitly multiplied by the number of CPUs.

maxWorkerThreads and maxIoThreads

.NET uses the following two configuration settings to limit the maximum number of worker threads and completion threads that are used:

<processModel maxWorkerThreads="20" maxIoThreads="20" />

The maxWorkerThreads parameter and the maxIoThreads parameter are implicitly multiplied by the number of CPUs, the default value of these two parameters are both 20. If for some reason your application is slow, perhaps waiting for external resources, you could try to increase the number of threads to a value less than 100. For example, if you have two processors, the maximum number of worker threads is the following: 2*maxWorkerThreads

minWorkerThreads

The setting determines how many worker threads may be made available immediately to service a remote request. By default, the minWorkerThreads parameter is not present in either the Web.config file or the Machine.config file at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG. You need to manually add the following line to make the setting work.

<processModel minWorkerThreads="1" />

Threads that are controlled by this setting can be created at a much faster rate than worker threads that are created in other ways. The default value for the minWorkerThreads parameter is 1. The setting is recommended to set in the following way.

minWorkerThreads = maxWorkerThreads / 2

Note: This setting is implicitly multiplied by the number of CPUs.

minFreeThreads and minLocalRequestFreeThreads

The two settings determine how many worker threads and completion port threads must be available to start a remote request or a local request:

<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8" />

The default value is 8. If there are not sufficient threads available, the request is queued until sufficient threads are free to make the request. Therefore, .NET will not execute more than the following number of requests at the same time:

(maxWorkerThreads*number of CPUs)-minFreeThreads

Note: The minFreeThreads parameter and the minLocalRequestFreeThreads parameter are not implicitly multiplied by the number of CPUs.

maxconnection

The maxconnection parameter determines how many connections can be made to a specific IP address. The parameter appears as follows:

<connectionManagement>
  <add address="*" maxconnection="2" />
  <add address="65.53.32.230" maxconnection="12" />
</connectionManagement>

The maxconnection parameter setting applies to the AppDomain level. By default, because this setting applies to the AppDomain level, you can create a maximum of two connections to a specific IP address from each AppDomain in your process.

execution Timeout

The setting limits the request execution time:

<httpRuntime executionTimeout="90" />

The default is 110 seconds.

Note: If you increase the value of the executionTimeout parameter, you may also have to modify the processModel responseDeadlockInterval parameter setting.

Recommended thread settings

For most applications, you can use and apply the recommended changes in the Machine.config file as below, which can be found at C:\WINDOWS\Microsoft.NET\Framework\v2.0.********\CONFIG:

  1. Set the values of the maxWorkerThreads parameter and the maxIoThreads parameter to 100.

  2. Set the value of the maxconnection parameter to 12*N (N is the number of CPUs that you have).

  3. Set the values of the minFreeThreads parameter to 22*N and the minLocalRequestFreeThreads parameter to 19*N.

  4. Set the value of minWorkerThreads to 50. Remember, minWorkerThreads is not in the configuration file by default. You must add it.

If you have hyperthreading enabled, you must use the number of logical CPUs instead of the number of physical CPUs.

Note: If you have a server with one processor, when you use this configuration, you can execute a maximum of 78 .NET requests at the same time because 100-22=78. Therefore, at least 22*N worker threads and 22*N completion port threads are available for other uses (such as for the Web service callbacks).

For example, if you have a server with four processors and hyperthreading enabled, then n=8 (=2*4). Based on these formulas, you would use the following values for the configuration settings that are mentioned in this section.

<system.web>
......
<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" />
<httpRuntime minFreeThreads="176" minLocalRequestFreeThreads="152" />
<connectionManagement>
  <add address="[ProvideIPHere]" maxconnection="96" />
</connectionManagement>
......
</system.web>

Also, if you use this configuration, 12 connections are available per CPU per IP address for each AppDomain, and you can execute a maximum of 624 .NET requests at the same time because 8* 100 - 176= 624.