PC_Client_Performance[1]

8/7/2019 PC_Client_Performance[1]

1/60


2/60


3/60

Oracle E-Business Suite 11iand 12

PC Client Performance

Executive Overview ..........................................................................................5Why Not Just Skip to the Results? .............................................................5

Introduction ....................................................................................................... 6The Importance of the Holistic Approach ...............................................6Oracle Client Recommendations ................................................................7

The Testing Methodology................................................................................8Creating a List of Test Candidate Transactions........................................8The Test Environment and Testing Issues ...............................................9

Testing Accuracy.........................................................................................11PC Clients Used in these Tests .................................................................11

Windows Memory Definitions and Measurement Tools ..........................12Different Types of Memory ......................................................................12

Choosing a Tool to Measure Memory.................................................13Choosing Which Memory to Measure ................................................16

Process Trimming .......................................................................................19Rules of Thumb Private Bytes and Working Set ................................20

Understanding the Browser Memory Offset and Scaling Results............21How to Map Integrated Browser Components......................................22

Adobe Acrobat Reader, Skype, and the Google Toolbar.................22

Microsoft Phishing Option...................................................................24Factors That Affect the Browser Memory Footprint............................24Deciding How To Scale Results ...............................................................25

Baseline the Browser Memory Offset .................................................25Decide Which Scaled Approach to Use..............................................25

Oracle E-Business Suite 12 The Results...................................................27Comparing Browsers and Oracle E-Business Suite Components.......28Average Memory by Oracle E-Business Suite Component Type........31Reviewing the Ratio of Working Set and Private Bytes ........................ 31Comparing Menu Memory Utilization.....................................................33Comparing Memory Profiles across a Range of Clients........................34

Comparing Load Times for across the Range of Clients......................35Comparing Load Times across Fast Clients.......................................36Comparing Reload Times......................................................................37Comparing Load Times and Jar File Volumes...................................38

Network Traffic for Oracle E-Business Suite 12 with JRE..................39Comparing Oracle E-Business Suite 11iand 12 .........................................42

The Effect of Business Flows in Oracle E-Business Suite 11iand 1242Comparing Working Set for Oracle E-Business Suite 11iand 12 .......43

Oracle E-Business Suite 11iand 12 PC Client Performance Page


4/60


Comparing Oracle JInitiator 1.3.1.29 with Sun JRE 1.5.0_12..............44Recommendations For Low Specification Clients .....................................45

Is a Low Specification Client Usable?......................................................46Controlling the User Environment ..........................................................46The Low-Specification Client Checklist ..................................................46

Memory Optimizers...............................................................................49So, How Much Memory Does my Application Need? .........................49

More Testing Tips.......................................................................................49Conclusion........................................................................................................50

Appendix A: OAF/HTML Screens and Forms Used in the Tests.....52Appendix B: Tuning the Client.................................................................55Appendix C: Windows Memory Internals...............................................57


5/60

EXECUTIVE OVERVIEW

It often makes financial sense to extend the operational life of IT equipment. This

paper provides guidelines on how to improve performance and thereby possibly

extend the useful life of slow or low-memory PC clients. It identifies specific

scenarios where the difference between low and high specification clients makes very

little difference to end-user performance, and answers the important question of

whether you need to upgrade memory, CPU, or both. This paper compares OracleE-Business Suite 11iand 12 using certified browsers, Oracle JInitiator 1.3.1.29

(Oracle E-Business Suite 11ionly) with the Sun Java2 Standard Edition Java

Runtime Engine 1.5.0_12 on a range of PC client configurations using Windows XP.

Extending the useful life of older PC

clients can often be cost-effective, even if

they have been fully depreciated.

Upgrading to the latest and fastest machines helps provide the best performance, but

the latest technology tends to command a price premium. The costs involved may be

disproportionate to the business gain and the performance may be substantially

more than strictly necessary to support the business. Budgetary constraints and asset

life dictate that the price/performance goal is to balance the return on investment

while providing reasonable longevity. Although the cost of hardware continues to

diminish, the time needed to upgrade a range of machines can be prohibitive,

especially when multiple geographic locations are involved.

The information in this paper will help you make informed decisions to establish the

minimum requirements for a specific price-performance point, and identify a specific

configuration that will achieve the throughput necessary to support your business.

The approach, tools, and observations provide a quantifiable basis for desktop

upgrade decisions that enable you to determine a suitable specification for a PC

client. This can be benchmarked with your particular set of applications in a range of

heterogeneous environments to ensure its suitability and performance.

Extending the concepts presented in the The Holistic Approach to Performance Tuning

Oracle E-Business Suitewhitepaper, this paper applies a holistic approach and

considers all the salient facts that may affect performance. This provides a

foundation for a cost-benefit analysis between zero-cost options, upgrading the

hardware as a one-off cost, and the on-going costs incurred from improvements to

the network infrastructure.

The holistic approach provides a

foundation for a cost-benefit analysis anda quantifiable basis for desktop upgrade

decisions.

Why Not Just Skip to the Results?

You can find a plethora of definitions for every aspect of Windows terminology

across the Internet, some right, some incomplete, and some wrong. The definitions

used in this paper are very precise, and this necessitates some complexity and

discussion around Windows memory management. A basic understanding of what is

being measured is essential for a meaningful review of the comparisons and charts.

A basic understanding of what is being

measured is essential for a meaningful

review of the comparisons and charts.



6/60

INTRODUCTION

While this paper focuses on low specification clients, some customers will already

have sufficient hardware in place, but will be concerned about their ability to support

the business at some point in the future. Even if you have what would normally be

considered a high-specification machine, you may still encounter memory problems

when running several applications simultaneously, so the ideas and concepts

presented here are still relevant.

As this paper cannot cover all the permutations and combinations of applications

that you could be running, it provides a comprehensive approach and describes the

tools that you can use to profile the application and Windows environment.

Microsoft state that adding memory makes a significant difference to Windows

performance and this is also true for some Oracle E-Business Suite components.

This statement does not mention CPU speed, and therefore it appears that they

consider this less significant. Consequently, this paper includes data points from a

range of PC clients that will help validate whether or not additional memory alone is

likely to improve performance sufficiently.

This paper does not discuss Windows Vista or Sun Java2 Standard Edition JavaRuntime Engine 1.6. Certification with the Oracle E-Business Suite is planned and

details will be included in a later revision of the paper.

The Importance of the Holistic Approach

Understanding where and how the machines will be deployed is just a starting point

and adopting a holistic approach is essential. In addition to considering factors that

affect your tests directly, such as the other applications that will be used on the

client, you also need to consider key transactions that are necessary to support the

business, simulation and modeling of the network, and whether some performance

issues are a result of other factors such as application tier or database performance.

The holistic approach provides a

foundation for a cost-benefit analysis and

a quantifiable basis for desktop upgrade

decisions.

It is very unlikely that this paper could match the exact combination of Oracle E-

Business Suite components with the specific combination of software that you use

on the same specification client, in addition to modeling specific network scenarios.

Therefore, the rationale of this paper is to provide examples of Oracle E-Business

Suite components and an approach that you can use in your own environment.

In addition to providing benchmarks for the range of machines that you would

expect to deploy, this paper also includes a very low-specification client (below the

recommendation for the Oracle E-Business Suite) as a checkpoint and control. The

memory on this client could not be upgraded, but the information may be useful, for

example, for rugged machines typically used in hostile environments that may be

exceptionally difficult or expensive to upgrade.

Including a client below the minimum

recommendation provides insights to the

performance of specialized clients that are

difficult or expensive to upgrade.



7/60

Oracle Client Recommendations

Oracle has traditionally taken the same approach as Microsoft by specifying the

minimum desktop client recommendations. While the official specifications offer a

useful starting point, as shown in Table 1, the ultimate decision of what constitutes

acceptable performance for a given scenario in your environment is driven by your

business requirements.

Oracle Desktop Client Recommendations Required Recommended

Processor 233MHz 1.4GHz + or higher11i

MetaLink Note 232833.1

RAM 256MB Or higher1

Processor 350MHz 1.4GHz + or higherR12 MetaLink Note 405293.1

RAM 256MB Or higher1

Table 1: Oracle Client Requirements and Recommendations

1You will experience better performance with additional memory

The Oracle client recommendations state that when evaluating CPU speed and

amount of memory, consider Microsoft's minimum requirements for the operating

system, other software that runs concurrently, and external factors such as network

characteristics. You should check that the desktop configuration is sufficient to

achieve the throughput necessary to sustain your business model; your requirements

may be higher than the minimum specification. Even if you have what would

normally be considered a high-specification machine, you may encounter

performance problems when running several applications simultaneously.A minimum specification client only

provides a minimal performance that may

not be sufficient to support your business. It is important to note that minimum specifications are exactly that, and will onlyprovide minimum performance. A minimum specification client may be adequate

for casual home use, but would probably not be considered sufficient when running

several applications together as would typically be the case in a business setting. For

example, displaying thousands of tasks and shifts that span several weeks on a Gantt

chart in Advanced Supply Chain Planning will cause severe paging on minimum

specification machines, and the PC client will appear unresponsive for a considerable

time.



8/60

THE TESTING METHODOLOGY

You will need to create a list of candidate transactions, benchmark a range of

configurations to determine performance within your specific environment, and then

consider which factors you need to include in your testing. This section provides

guidelines on selecting a set of transactions to test, and provides a provisional set of

guidelines based on the experience gained during the testing that was conducted for

this paper.

Creating a List of Test Candidate Transactions

One of the primary components of a benchmark is a set of key transactions that are

usually best defined by the business and user managers. Users typically cite form or

screen opening times and inter-field navigation as performance concerns. As data

and inter-field operations generally have a high dependency on the data volumes,

system setup, profile options, and other variables, these factors have been excluded

as the test environment is based on a single machine using a default Oracle E-

Business Suite install and the Vision database.

Create a list of critical business

transactions that you

need to benchmark.

If you wish to expand the tests in this paper, it is important not to confuse issues

directly relating to client performance with other factors such as navigating betweenfields on a form or querying data. These are more likely to be influenced by the

relative performance of the database, application tiers, and associated servers.

The tests in this paper focus on the time to open a form or screen as the primary

indicator of client performance. While some tests include querying data, this is

generally restricted to situations where this is required to enable other forms to

open. Their definitions are listed in Appendix A. Some screens and forms can be

accessed through multiple responsibilities or users, but each path may produce

different results. For this reason, the user details and menu navigation path are

included to ensure that any comparisons are valid and to assist with comparative

testing in the event that you are unfamiliar with the full range of products.

The tests in this paper focus on the t ime to

open a form or screen as the primary

indicator of client performance.

Your initial list of forms and screens is collated by surveying your departments or

business management units. The composite list may be very large and you may need

to create a subset of representative test candidates. If your background is technical,

you may consider mapping the forms and their respective transactions against high-

volume or high-transaction tables. However, this will need further review from a

functional perspective and understanding of the business flow that includes which

forms can be kept open simultaneously, and (and more importantly) the frequency

of switching between forms, screens, and responsibilities.

You may also benefit by using an approach where a business process can be broken

into a set of discrete functions that need to be completed within a set time. For

example, a customer service agent who takes an order over a phone will typically

need to perform the following tasks:

Enter or locate customer and address information Enter an order for the goods and check their availability Enter payment details Create a picking list for the warehouse Print an invoice and shipping label



9/60


10/60

All the tests in this paper were run against an Oracle E-Business instance with the

Vision Demo Database. The machine was a single 2.13GHz Intel Core Duo server

with 4GB RAM running Red Hat Linux 4 using the ext3 file system on a logical

volume group that spanned two disks. As this machine is exceptionally small when

compared to a typical production system, all the tests were run once prior to

recording results to ensure that the performance of this machine did not adversely

affect the tests. This is similar to most production systems that utilize a number of

caches that maintain the code and data that is common use. While this does not

affect client memory, you should expect to achieve better response times on your

system.

You should expect to achieve better

response times on your system.

The benchmarks compare Oracle JInitiator 1.3.1.29 and the Sun Java2 Standard

Edition Java Runtime Engine (JRE) 1.5.0_12, which were the latest certified versions

at the time of writing. No patches were applied to the Oracle E-Business Suite 11ior

12 environments, even though there are several patches or family packs that you

would normally apply to any environment for functionality or performance. This

approach means that you can quickly replicate this environment. It may be pertinent

to compare a subset of tests in your environment to establish if there is a significant

difference or factor that can be applied to scale the results in this paper.

To save time, use a subset of tests to

establish a scaling factor that can be

applied to the results in this paper.

When a form or screen starts, it will frequently access system, product, user, and

other information. This initial communication between the client and server is

affected by latency, available bandwidth, and possibly other constraints related to the

network infrastructure (such as packet prioritization). Therefore, if you are planning

to deploy clients in remote high-latency locations, you will need to simulate the

salient conditions in your test environment. This is especially important as a form

accessed over a LAN may only take a few seconds to open, whereas it may take a

minute or even longer when deployed over a high latency network link. If it

transpires that latency is the primary performance bottleneck, then you should

consider traffic compression technologies and caching. Network optimization will

have a positive effect on overall client performance.

You need to encompass all salient client

and network conditions in your test

environment.

The following key points were identified during testing:

The nature of Windows memory management means that you need to restartthe browser in-between each of the tests when determining the memory profile

of individual forms and screens. This does not affect combinations of screens

used in a standard business flow.

If you repeatedly open and close a browser you may notice that the memorymeasurements change, especially on very low-specification clients. This may be

the result of paging, and should stabilize after a short time. It is imperative to

ensure that the initial browser memory allocation does not change betweentests, as this would skew the results.

You need to ensure the working environment is representative of the userexperience. In this paper, all the applications were opened in advance of the

tests. Equally important is that they are in the same state each time. In the tests

the windows overlaid each other; minimizing any of them at any time would

have radically skewed the results. You will need to bear this in mind when

following a set of actions that represent a standard business flow.

Oracle E-Business Suite 11iand 12 PC Client Performance Page 1


11/60

Unless shown to be contributing to a memory problem, avoid minimizing andrestoring the measurement tools as this significantly changes the memory profile

on low-specification machines.

Do not leave a test part way through and then return to it later, as the Windowsmemory manager may well have reorganized the Windows environment and this

may create a substantially different environment.

Unlike working on the Internet, if you make a mistake when selecting a formand quickly click on another option, you will find that you have an apparently

anomalous large memory footprint. This is accounted for by both forms being

opened, but only one being visible, as they overlay each other when they are

rendered.

With Internet Explorer 7 and Firefox 2 specifically, some of the memorymeasurements take some time to settle after a screen or form has opened.

Several of the clients had a relatively large amount of memory (1-2GB) thatshould have been more than adequate to test without process trimming or other

Windows memory management issues. It was surprising how few applications it

took before Windows started to trim the Working Sets, so you should consider

this, especially when testing a suite of applications. Refer to the Process Trimming

section for further information.

Additional guidelines are provided in the More Testing Tipssection.

Testing Accuracy

If your simulation and testing methodology is consistent, repeated tests on the same

PC client should be within a tolerance of 2.5%. If the accuracy is lower, then you

should establish the cause, as it could be contributing to problems with the end-user

experience.

Even though measuring Windows memory

is an inexact science, you should achieve

an accuracy of 2.5%

PC Clients Used in these Tests

The PC clients used in the test are listed in Table 2. All of the machines were

running Intel processors with Windows XP SP2 and all the latest patches.

With the exception of the Intel 930 Core Duo PC, all the machines were laptops.

The 366MHz/128MB client is below the Oracle recommendation, but the

architecture meant that it was neither possible nor practical to change the amount of

installed memory. This was included as it provides insights to the performance of

specialized clients that are difficult or expensive to upgrade. In theory, as the tests

were conducted with the minimum of other applications running, 256MB should be

adequate for all except the most demanding of tests.

Virtual machines (VM) were considered as an easy way of changing the systemmemory, as they appeared to function without a problem. However, the memory

profile (specifically Working Set and Private Bytes) within the VM environment did

not always follow the same profile as a native Windows environment. At this stage,

more research is needed to reconcile disparities in the memory measurements

between real and virtual clients, and consequently further testing was not carried out.



12/60

Speed Memory Comment

366MHz

Pentium II

128MB This is the minimum specification client for Oracle E-

Business Suite 12. The memory is just above the Microsoft

minimum but below Oracle recommendations.

700MHz

Pentium III

256MB Although old technology, this is the minimum memory

recommended for Oracle E-Business Suite 11iand 12.1.6GHz

Pentium

1GB This speed appears to be very common, but many users

expect to run several large applications simultaneously but

with only 256MB or 512MB RAM.

T2400 Mobile

Core Duo

1.8GHz

2GB This is alleged to be equivalent to 3.43GHz (according to

non-Intel resources). At the time of writing, this is the

standard Oracle laptop (with either 1GB or 2GB of RAM).

Intel 930 Core

Duo 3GHz

2GB This is one of the fastest clients available at reasonable cost

without commanding a substantial price-premium.

Intel 930 CoreDuo 3GHz 256MB Again, one of the fastest clients, but this will highlightdifferences between the 256MB and 2GB memory sizes.

Table 2: PC Clients Used for the Tests

WINDOWS MEMORY DEFINITIONS AND MEASUREMENT TOOLS

One of the challenges of Windows internals is that definitions found on the Internet

are often incomplete, taken out of context, or simply erroneous. For this reason, the

specific meaning of each of these terms needs to be defined and explained. This

section introduces the types of memory and how each is managed; further detail and

more comprehensive definitions are included in Appendix C: Windows Memory

Internals.

An understanding of the terminology is

essential for successful interpretation of

the test results.

Different Types of Memory

Like most operating systems, Windows uses a virtual memory model, and each 32-

bit Windows process can have private and shared memory, which are defined as

follows:

Private memory This is the exclusive private virtual memory allocatedto the process and inaccessible by any other process. It is also referred to

as Private Virtual Bytes.

Shared Memory Shared memory contains an image or a mapped filesuch as a dynamic link library (DLL) that can be simultaneously accessed

by multiple programs. Once referenced, the object is mapped into each

processs address space even though the data or image file is only loaded

once into system memory.

Private memory and shared memory are collectively referred to as the processs

Working Set(WS), which is defined as the combination of physical private and shared

memory pages that have been used or recently touched by the threads of a

process. They can be referenced without incurring a page fault.



13/60

The amount of shared memory depends on the combination of applications that you

use concurrently, and (to some extent) the functions that you are using within the

Oracle E-Business Suite. Figure 1 compares the average amount of shareable and

shared memory for each of the browsers across a range of tests (on the 1.83GHz

T2400 Core Duo with 2GB RAM). You would not expect many memory pages to

be shared in the test environment, as the client only had standard background

applications such as a virus checker, and a minimal business set of applications open

including Mozilla Thunderbird (email), Pidgin (chat client), Process Explorer and

Microsoft Excel.

The amount of shareable and shared

memory depends on the other applications

in use at the same time.

Figure 1: Comparing Shareable and Shared Memory

The amount of shareable memory will vary over time, but is not really a concern, as

it does not limit the actual amount of shared memory pages. As Internet Explorer is

a Microsoft product, you would expect it to share more memory pages with the

Windows Kernel and other Microsoft applications, and this is indeed evident in the

results. The amount of shared memory used by Internet Explorer increases when

also using other Windows applications such as Microsoft Outlook. Firefox is an

open source browser, so not surprisingly shares a relatively small amount of memory

with Windows components. Even so, the 3.5MB difference between Firefox and

IE7 is only 35% and in practical terms, this is a small percentage. Several other

factors need to be considered prior to choosing a particular browser.

Choosing a Tool to Measure Memory

Undertaking meaningful measurements of the various types of Windows memory

can be complicated, so this section starts by providing an overview of the available

tools and then maps them to the different type of memory in a tabular format.

This section focuses on the following three tools:



14/60

Task Manager (taskmgr) Start by enteringtaskmgrat a commandprompt, from the taskbar context menu, pressing [CTRL] [SHIFT]

[ESC], or [CTRL] [ALT] [DEL] then selecting Task Manager. The

column names can be misleading. In the default view, it shows the

mem usagecolumn, which is a measure of only the physical amount of

memory used by a process (Working Set). You also need to display

VM Size, which is the processs virtual private memory usage (and not

the virtual memory size). Measurements do not necessarily reflect a

reduction in the Java heap belonging to the Oracle client even though

you can see a reduction in the Java console and a corresponding

reduction in the commit charge (shown in Task Manager). Working

Set can be overstated, as Windows does not necessarily trim the

physical memory allocated to a process until it has a need to, or there

is a period of inactivity. If Windows trims the Working Set, you

cannot use this as a reliable measure of the true amount of memory

(Private Virtual Bytes) that the program is using.

Performance Monitor (perfmon) Start from the commandprompt, or navigate to Settings | Control Panel | AdministrativeTools | Performance. This very comprehensive tool requires pre-

configuring with an appropriate set of counters. It can be

cumbersome and scaling graphs can be difficult. In general, it is better

suited to tracking changes over time.

Process Explorer (procexp) Start from the command prompt, orthe installed location. This is a free program available from Microsoft

and is the tool that was used for all the measurements in this paper. It

is quick and easy to configure, and there are support forums should

you encounter issues. Documentation is minimal, but this tool was

the easiest to configure, and provided the complete range of metrics

throughout this paper.

Process Explorer is shown in Figure 2. The top pane shows detailed information

about currently active processes. The lower window can be configured to show

either the process handles that a process has opened, or (as in this example) the

DLLs and memory-mapped files that the process has loaded.

The Process Explorer, a free tool from

Microsoft, provides the Working Set and

Private Bytes used for the measurements

throughout this paper.

The following steps were used to configure the tool to provide the measurements in

this paper:

In Options | Configure Highlighting: UncheckOwn Processes. Right-click either column set and select the correspondingcolumns in the Process Memory tab (top pane) and DLL tab

(lower pane) sections.



15/60

Figure 2: Process Explorer

Process Explorer provides the Working Set(WS) and Private Bytes(PB) used for the

measurements throughout this paper. The Peak Working Setspecifies the maximum

amount of physical memory that a process has been allocated since it started. During

testing, the peaks only lasted a short time even on the slowest client, and there was

no correlation with any major performance related Window events. The peaks were

always within close proximity of the Working Set and can generally be ignored. WS

Private shows the amount of memory exclusive to the process. The WS Shareable

and WS shared columns break down the processs non-private pages into what can

potentially be shared, and what is actually being shared by at least one other process.

As a point of interest, on a PC with plenty of memory, Working Set is usually larger

than Private Bytes. If Private Bytes significantly exceed Working Set for the majority

of applications that have never been minimized, you will benefit from running fewerapplications simultaneously or additional memory. This introduces further important

concepts that are discussed at length in the Process Trimmingsection.

Working Set is usually larger than Private

Bytes on a machine with plenty of memory.

If Private Bytes exceed Working Set for the

majority of applications that have never

been minimized, you will benefit from

running fewer applications simultaneously

or additional memory. Notice that Figure 2 shows a very small Working Set for the Palm Desktop; this

indicates that the application was minimized and the process has been trimmed.

While the process only had 5MB of physical memory allocated, it was still using

20MB of private virtual memory (Private Bytes).

Double-click a process (or right-click and select Properties from the context menu)

to show additional process information. The Performance Chart in Figure 3 provides

a graph of the Private Bytes history, and although not the focus of this paper, the

CPU and I/O. The Performance tab in Figure 4 shows detailed information aboutthe process. This information provides significantly more detail. For example, it is

possible to calculate the precise amount of physical RAM that is currently backed up

in the paging file. This may be interesting if you were trying to size a paging file

accurately, instead of simply using the standard approach of using minimum =

maximum = 2 x physical memory. The columns displayed on the main screen

provide adequate analytical information for the purposes of this paper.



16/60

Figure 3: Process Explorer Performance Graph

Figure 4: Process Explorer Performance Tab

Choosing Which Memory to MeasureAs you will appreciate, there are several different ways to measure memory. Peak

Working Set, Working Set, Private Bytes, WS Private and WS Shared are compared

graphically in Figure 5. To be pedantic, the measurements include the initial amount

of memory used by the browser, which is a pivotal topic discussed in The Browser

Offset Memorysection. As such, the chart should only be used to compare the

different approaches to memory measurement. In order to make the comparison

easier, the terminology is summarized in Table 3.

There are four ways to measure memory.

Figure 5: Comparing Memory Measurements



17/60

The least noteworthy is the sum of the amount of physical memory exclusive to the

process (WS Private) and the amount shared with at least one other process (WS

Shared). Although this is an absolute measure of the physical memory utilization, it

is understated: instead of using WS Shared, it should use WS Shareable (as used by

Working Set) to map all the pages used by the process.

If you decide to use Working Set,

you also have to measure

Private Bytes as a control.

Working Set represents the pages in physical memory that are dedicated to a

particular process. From a theoretical point of view, Working Set (effectively thesum of WS Private + WS Shareable) would seem to be the most accurate way to

measure the size of a single process. With multiple applications, counting the entire

Working Set for each process will over-count memory, as the shared component is

included in each. Due to the way that Windows manages memory, you also need to

measure Private Bytes to ensure that the Working Set has not been trimmed (which

can happen as soon as an application is started).

You could argue that you only need to be concerned with the Peak Working Set as

this is the most likely to cause problems. However, as mentioned in the previous

section, these were very short duration and did not have a significant affect, even on

the smallest of machines. Therefore, this does not represent the actual amount of

memory being used. Furthermore, like Working Set, Peak Working Set may also be

subject to process trimming on low-memory clients.

Private Bytes represents the private virtual memory that the program has been

allocated and is used exclusively by the process; it can reside in physical memory or

the page file. It is smaller than Working Set as it does not include the shared memory

component, but could be considered more accurate if the shared memory

components were already shared by the other active applications.

Private Bytes is more accurate than

Working Set on a low-memory client.

At this stage, the difference between Working Set and Private Bytes looks very small,

and you might argue that you could use either of these approaches. Each has its

problems and both have potential inaccuracies. It appears that you could quote a

maximum safe value (Working Set) or more accurate (Private Bytes), and for slightly

better accuracy add the amount of shared memory. In order to understand more

about the relationship between these two figures you need to understand what

happens when the Windows memory manager trims a process.

This paper focuses on both Private Bytes

and Working Set.



18/60

Process

Explorer

Task

Manager

Performance

Monitor

Description Comments

Virtual Size N/A Virtual Bytes A processs virtual address space consists

of free, reserved, and committed memory

pages. Reserving address space costs

nothing in terms of memory consumptionbut allows for future allocations from a

contiguous area of memory.

This is far higher than the

physical requirements. It does

not represent the real amount

of memory that the program isusing.

Private

Bytes

VM Size Process |

Private Bytes

This is the private virtual memory that the

process has been allocated. It is committed

memory that can reside in physical memory

or page file and is protected and

inaccessible by any other process. The

difference between Private Bytes and WS

Private is the total that is currently not in

memory but is backed by the page file.

This may undercount memory

as it omits the shared memory

that the process is using.

However, it is accurate when

shared memory is minimal. It is

the best value to use once a

process has been minimized, or

on a machine with low memory

where the process may be

immediately trimmed.

Working Set Mem

Usage

Process |

Working Set

These pages are currently resident in

physical memory and dedicated to a

specific process. It is effectively the sum of

Process Explorer WS Private + WS

Shareable. The peak Working Set is the

maximum amount of physical memory

used since the process was started.

This value can be larger than

the minimum number of bytes

actually needed by the process,

as it includes the shared

memory for each application. It

may artificially reduce as you

open more programs (due to

trimming). The accuracy

decreases when severalprocesses involved in the total.

WS Private N/A N/A This is the amount of physical mapped

memory used by, and only accessible by,

that process. Other processes cannot share

it. This is the same as Private Bytes except

all referenced pages are currently resident

in physical memory as opposed to both

physical memory and page file.

This cannot be used in

isolation, as it does not include

the shared memory component.

WS

Shareable

and WS

Shared

N/A N/A WS Shareable is the amount of memory in

a processs Working Set that can be shared

with other processes. WS Shared is the

subset of the shareable memory that is

shared with at least one other process.

Use this to determine the

amount of shared memory that

is in use/may be used by the

process Working Set.

Table 3: Mapping Task Manager, Performance Monitor, and Process Explorer



19/60

Process Trimming

Understanding process trimming is essential as it explains why the ratio of Private

Bytes to Working Set radically changes. A processs Working Set may be trimmed

with only a single Oracle E-Business Suite form open on a PC client with only 1GB

RAM; if this happens, it will skew your results, hence the need to monitor Private

Bytes.

Working Set may be trimmed with a only

single Oracle E-Business Suite form or

screen on a client with only 1GB RAM.

If the Working Set of an existing process increases, or you start another applicationand there is enough physical memory available, it is simply assigned from the

available pool of free memory without affecting other processes. However, if

insufficient free memory is available, Windows will need to trim (displace) memory

pages from other processes. Unlike unmodified memory pages that can be reused

immediately, modified pages must to be written to the page file before they can be

reused. Paging large numbers of modified memory pages due to insufficient physical

memory or too many applications running simultaneously will result in disk thrashing.

Once a process has been trimmed and the Working Set dramatically reduced, it can

take several seconds for an application to recover and become responsive again. It

would be natural (but incorrect) to think that Oracle E-Business Suite was the cause

of the slowdown, when in fact Windows was responsible. To ensure optimal

performance at all times, users should never minimize an Oracle E-Business Suite

component.

Users should never minimize an Oracle

E-Business Suite form or screen.

If you accidentally minimize a form in a

test, you will have to restart the test.

The Performance Monitor chart in Figure 6 shows the relationship between

Working Set and Private Bytes for the Oracle E-Business Suite 12 Purchase Order

form using Internet Explorer 7 on a client with 2GB memory (effectively

unrestricted and not subject to immediate trimming). The chart shows the process

from starting the browser, logging in, selecting the purchasing menu, and opening

the form. Up to this point, Working Set exceeds Private Bytes as expected.

Minimizing the form results in a substantial reduction of the Working Set, but

(importantly) Private Bytes remains static. When free memory falls below a

threshold, pages are trimmed from the Working Set. While the exact memory figures

are not relevant, minimizing all browser windows reduces the Working Set to 14%

of the original.

Minimizing an application radically

reduces the Working Set, but Private Bytes

remains the same.

Restoring the browser window containing the form and running an open query

proves that the application is functioning, but at this point, it is only using 40% of

the original allocation. Moving and maximizing all the browser windows increases

the Working Set, but this only reached 70% of the original, even when subsequent

queries were run. However, minimizing and then later maximizing a form that

contains a multi-record block causes a loss of mouse focus within that block. It is

therefore advisable not to use the minimize form option until the resolution ofOracle bug 6041461.



20/60

LoginScreen

PurchasingMe

nu

StrartPurchaseOrder

Minimizeall

Windows

Form is

Displayed

Restore the Form

Run an Open Query

Maximize the

Form Window

Maximize all

Explorer Windows

Minimize the

Form

StartBrowser Run further

Queries

Private Bytes

Remains the Same

Figure 6: Process Trimming -Working Set and Private Bytes Compared

Rules of Thumb Private Bytes and Working Set

As previously mentioned, Windows trimming can be very aggressive. Sometimes you

may find it difficult to understand why trimming is taking place when you appear to

have ample free memory. The process is discussed in detail in the Process Trimming

and the Memory Stackssection of Appendix C.

Once trimmed, a processs Working Set is understated as it only counts physical

memory and does not include memory paged to disk; therefore, you also have to

monitor Private Bytes. This leads to the following rules:

Once trimmed, a processs Working Set isunderstated, as it does not include

memory paged to disk.

On a client with plenty of available memory, use Private Bytes to check thatWorking Set has not been trimmed, as it is not affected by the Windows

memory management process.

On a client where the Working Set has

been trimmed (perhaps as soon as the

application is started), you have to use

Private Bytes, and for better accuracy, add

the amount of shared memory. On a client with little available memory, Windows will trim the Working Set

physical memory for use by other applications, perhaps as soon as it is

started. In this case, you have to use Private Bytes instead, and for better

accuracy, add the amount of shared memory.



21/60

UNDERSTANDING THE BROWSER MEMORY OFFSET AND SCALINGRESULTS

During the tests, the browser was set to display a blank Home Page by default.

The browser offset (initial amount of memory) varied between 9MB and 36MB,

depending on the browser/client combination. The variation of more than 25MB

between the highest and lowest Working Sets needs to be normalized; failing to

consider this would skew and invalidate comparisons across browsers.

Failing to normalize the browser offset

would skew and invalidate comparisons

across browsers.

Figure 7 shows the measurements for private bytes and working set for each of the

three browsers across the five test machines, using JRE with Oracle E-Business Suite

12. The chart is color-coded. Each browser is assigned a different color using two

shades: blue for IE6, yellow for IE7, and orange for FF2.

Figure 7: Browser Memory As Measured For Oracle E-Business Suite 12 Using JRE

There is a lot of detail in this chart. Notice that the browser footprint on the first

two low-specification machines is very small; this may be due to a more radical

approach to memory management, effectively resulting in immediate process

trimming. When IE7 is installed over IE6, it integrates all the same browser

extensions used by its predecessor, and the larger footprint relates to an increase in

functionality.

Firefox has the highest memory footprint

on the 1.83GHz Core Duo,

but this includes several plug-ins

and helper applications.

A first glance at these results shows that Firefox has the highest memory footprint

(on the 1.83GHz Core Duo), but this is misleading as this particular browser

includes several plug-ins and helper applications that you may not find in a normal

business environment. A more accurate comparison for the basic Firefox browser is

the 23.6MB on the Intel 930 Core Duo, which was a fresh install and this is

noticeably less than Internet Explorer 7 (30.4MB).



22/60

The initial intent was to reduce the browser memory profile to a minimum and

ensure consistency by using an identical Windows build. The high impact changes

listed in Appendix B were necessary for the smallest clients and for consistency were

applied to all environments. Although the changes improved performance, none

significantly influenced the browsers footprint. While this is clearly unrelated to

Oracle E-Business Suite, establishing the reasons for the difference in browser

behavior was the first mystery that needed to be solved in these tests.

Understanding the browser offset

identified additional optimization

opportunities for low-memory clients that

would have been missed.

How to Map Integrated Browser Components

The Process Explorer shown in Figure 2 lists the DLLs referenced by the browser.

Sorting by WS Total will show the highest memory components first. Not only is it

sometimes difficult to correlate DLLs to a specific browser component, it can be

difficult to differentiate between core browser components and those associated

with additional features. Some can be intuitively mapped to a plug-in or helper

application, while others can be mapped from within the browser.

Identify the highest memory utilization

components using Process Explorer and

then map obscure DLLs from within the

browser.

In Firefox enter about:pluginsin the URL; in Internet Explorer 6, this information is

available in the Tools menu; in Internet Explorer 7 use the Manage Add-ons screen.

An example of the Manage Add-ons screen is shown in Figure 8. The displaycategories include Add-ons that have been used, those currently loaded, those run

without requiring permission and those that load when Internet Explorer Starts

(This final option was available at the start of the tests, but appears to have been

removed, possibly by a Windows update).

Figure 8: Internet Explorer 7 Manage Add-ons Screen

Adobe Acrobat Reader, Skype, and the Google Toolbar

Adobe Acrobat Reader, Skype, and the Google Toolbar were installed in each of the

browsers and their memory profiles compared in Figure 9. The Internet Explorer 7

memory utilization increased much more than the other browsers even though the

version and size of the utilities was identical.



23/60

Figure 9: Comparing Browser Add-On Memory Profiles

Table 4 shows an abbreviated export from Process Explorer for Internet Explorer 7

with Adobe Reader, Skype, and the Google Toolbar. Note that some utilities will not

appear in the DLL listing until they have been used at least once.

The largest components are the

Google Toolbar and the

Microsoft Phishing Filter Data File.

Process PID Working Set Private Bytes

iexplore.exe 4680 39,900KB 28,612KB

Name Description WS Total WS Private

IEFRAME.dll Internet Explorer 3008KB 2328KB

googletoolbar Google IE Client 2560KB 2328KB

ieapfltr.dat MS Phishing Filter Data File 2392KB 0KB

mshtml.dll MS HTML Viewer 2260KB 40KB

SPhoneParser Skype 1756KB 576KB

SKypelEPlugin Skype 1168KB 740KB

shell32.cll Windows Shell Common 476KB 36KB

Total 24,588KB

Table 4: A Sorted Extract from Process Explorer

In this particular example, the WS Total for the mapped components account for

approximately 24MB out of the total 39MB Working Set, which is considerably less

than the Working Set Size. A part of the reason is that, for example, Adobe Reader

(AcroIEHelper.dll) does not appear in the list unless you have a PDF file open in the

browser.



24/60

Microsoft Phishing Option

Table 4 identifies the Microsoft Phishing option as one of the largest components.

This can be disabled and the results for the Internet Explorer 7 memory footprint

are shown in Table 5.

Mapping add-ons and plug-ins can be

difficult and instead it may be easier to

measure the browser memory footprint

before and after you integrate the features.

Option Working Set Private Bytes

On 39,900KB 28,612KB

Disabled 36,416KB 24,736KB

Difference 3,484KB 3,876KB

Table 5: Exploring the Microsoft Phishing Option

Given that the Phishing data file (ieapfltr.dat) has a WS Total of 2,392KB, disabling

this option shows a Working Set reduction of 3,484KB, which indicates that some

other associated components were not loaded. While disabling this function on an

Intranet may be useful, this highlights a possible requirement to review proposedchanges with a wider audience (such as network security in this case).

Disabling every add-on resulted in an unexpectedly small reduction of the browsers

Working Set by approximately 7MB. For IT professionals wanting to take the

analysis to the next stage, the browser startup events can be captured using Process

Monitor (also free from Microsoft). These can be filtered using the browser Process

IDentifier (PID), which is shown in Process Explorer. There are in excess of 30,000

events for Internet Explorer 7, but again, correlation to the DLLs, drivers, and data

files is not easy. Trying to normalize the browser footprints was abandoned after

extensive analysis.

Disabling all add-ons did not reduce the

browser memory as much as expected and

attempting to normalize the browser

footprints was abandoned.

Factors That Affect the Browser Memory FootprintNormally the Internet can supply a plethora of information, but there is very little

discussion on the amount of memory used by browser components. The following

list of components was compiled throughout the investigation; some aspects could

be construed as obvious while others are more obscure:

Avoid integrating browser components

that are not essential to the business.

Figures 7 and 9 show that Internet Explorer 6 has the smallest browserfootprint, and as will be shown, the smallest average Working Set across the

Oracle E-Business Suite tests in this paper.

The browser footprint may be automatically trimmed if there is littleavailable memory. This can be affected not only by applications that are

automatically started with Windows, but also by background services.

A significant amount of memory can be used by browser themes, extensions,plug-ins and helper applications such as Adobe Acrobat, Adobe Shockwave,

Adobe Flash Player, Apple QuickTime, RealNetworks RealPlayer, Skype,

and password managers.

Toolbars can use several megabytes of memory. Codecs (to support multimedia content) are generally not required.



25/60

Phishing controls are probably not required on secure Intranets withrestricted or no Internet access

The download history uses memory and should be regularly cleared. Thisseemingly insignificant issue has been reported as an issue with Firefox.

Windows components including the number of language packs and multi-lingual support, all use memory. Avoid the installation of unnecessary

language packs, even if you use a corporate image.

Avoiding other integrated components is more difficult, such as MIDI andaudio support, the Remote Access connection manager and associated APIs

and the Windows Telephony client. The combination depends on the type

of client and device drivers, but older machines tend to have more drivers

that are less integrated with Windows (and less shareable/shared memory).

Overall, when designing a system for low-memory clients, the goal is judicious

removal of high-memory non-essential components that needlessly add to the

browser memory footprint.

Deciding How To Scale ResultsDeciding which method to use to scaleresults is critical.

As different browsers have different offsets on each client, it is important to find an

approach that can be used to scale the results so that they can be compared.

Deciding which method to use to scale results was found to be as involved as trying

to normalize the browser footprints.

Baseline the Browser Memory Offset

Referring to the discussion around Figure 7, the most reliable measurements for the

browser footprints are the fresh installs on the Intel 930 Core Duo PC. Rounding

these figures keeps the calculations simple without introducing significant errors.

Table 6 shows the resulting offsets that have been used as a basis to scale all the

results.

Table 6 shows the offsets that have been

used as a basis to scale all the results.

Browser IE6 IE7 FF2

Working Set 20MB 30MB 25MB

Table 6: Standard Memory Offsets

Decide Which Scaled Approach to Use

The approaches considered to scale the results are as follows:

Difference the Results Using an Average Browser Footprint Adjusteach result by adding or subtracting the difference between the actual

browser offset and the datum provided in Table 6. This approach worked

remarkably well until it was noticed that the ratio of Private Bytes to

Working Set was being skewed for particular tests.

Exclude the Browser Offset Deducting the initial browser footprintmeans that you could simply add your browser offset to scale the results for

your environment. However, the results are skewed by the differences

shown in Table 6, thereby reducing differences between the browsers.



26/60

Scale Results based on the Static Ratio of Browser Offsets Thisapproach resulted in a dramatic increase in Private Bytes for both IE7 and

FF2 as the ratio of Private Bytes and Working Set is not static and varies by

the type of Oracle E-Business Suite component.

Scaled Results Using a Variable Ratio This proved to be the mostaccurate method, but you have to use variable scaling as follows:

The variable scaling ratio is the

most accurate.

oUse a scaling factor based on the browser offset from Table 6 tocalculate the new Working Set

oEstablish the percentage difference for the original Working Setand Private Bytes

oUse the percentage to calculate the new Private Bytes value fromthe new Working Set

CAUTION! You cannot use this approach on a client running Windows XPSP2 with less than 2GB memory otherwise you will find that the Windowsmemory manager may skew the results due to aggressive trimming. In thiscase, you will have to use Private Bytes as the key, but this may be lessaccurate (depending on the shared memory).

Figure 10 shows a graphic comparison and visual check of all the average memory

used by each method for the full range of tests using Oracle E-Business Suite 12

with JRE. Firefox included several additional components and including it shows

how well each method worked.

Figure 10: Verifying the Choice of Scaling Method

This chart shows that excluding the offset reduces the differences between the

browsers, but this is misleading as this incorrectly indicates that Firefox has the

highest footprint. Scaling using a static ratio dramatically changes the ratio of Private

Bytes and Working Set for IE7 and Firefox. The scaled results using a variable ratio

follow the same pattern as the extrapolated averages in Table 6; the Firefox browser

with the additional components has been fully normalized and the ratio of Private

Bytes and Working Set for all three browsers is verifiable.



27/60

Figure 10 implies that Internet Explorer 6 remains the browser with the smallest

initial memory footprint. You might infer that the other browsers are less suitable

for low-memory clients and although the difference of a few megabytes is very small,

further research shows that this decision is not so clear, as the profile changes

depending on the type of application used. This highlights a common problem with

mixed benchmarks, and demonstrates that while using a more granular approach is

sometimes beneficial, it does not eliminate the need to perform your own tests with

your own particular combination of applications.

ORACLE E-BUSINESS SUITE 12 THE RESULTS

The first half of this paper includes a full testing methodology that can be deployed

in your environment and describes how to accurately scale the results when working

with different browsers across a range of clients.

The key points that need to be understood for successful interpretation of the results

includes the types of memory that need to be measured (Working Set and Private

Bytes), the ratio between them, why they cannot be used in isolation, and what

happens when an application is minimized or the process is trimmed by the

Windows memory manager.As a recap, some of the key points are as follows:

Working Set and Private Bytes are both important and should not be usedin isolation.

oWorking Setis a measure of the combination of physical privateand shared memory pages that are currently resident in physical

memory and dedicated to a specific process. When measuring

multiple applications, it can be overstated as it includes the shared

memory component.

oPrivate Bytesis a measure of the virtual private memory allocatedto the process. It can reside in physical memory or the page file,

but does not include shared memory and so may undercount the

amount of memory being used.

Minimizing or trimming a process results in a substantial reduction of theWorking Set, but importantly Private Bytes remains static. Once trimmed, a

processs Working Set is understated as it only counts physical memory and

does not include memory paged to disk.

On a client where the Working Set has

been trimmed (perhaps as soon as the

application is started), you have to use

Private Bytes, and for better accuracy, add

the amount of shared memory.

The following rules were established:

On a client with plenty of available memory, use Private Bytes to check thatWorking Set has not been trimmed, as it is not affected by the Windows

memory management process.

On a client with little available memory, Windows will trim the Working Setphysical memory for use by other applications, perhaps as soon as it is

started. In this case, you have to use Private Bytes instead, and for better

accuracy, add the amount of shared memory



28/60

Unlike Oracle E-Business Suite11i, Release 12 does not use Oracle JInitiator for its

Forms-based content. Instead, Oracle Forms runs directly with the native Sun Java2

Standard Edition Java Runtime Engine 1.5.0_12. For further information, refer to

Steven Chans bloghttp://blogs.oracle.com/schan/release12.

All the measurements in this paper assume that you have used the standard menus as

installed and not used shortcuts that would inevitably change the memory utilization

profile. Recall also that the browser was restarted for technical reasons between eachtest instead of using the change responsibility function.

Although this paper focuses on low-memory clients, you will find that as Windows

takes a very aggressive approach to trimming process memory, using a client with

less than 2GB of memory will skew your results. For this reason, the amount of

client memory is important and needs to be considered in each set of results. Note

that the amount of memory used by Process Explorer and Excel is relatively small,

and therefore should not affect the tests.

Comparing Browsers and Oracle E-Business Suite Components

Figure 11 shows the Private Bytes and Working Set for all three browsers on the

1.83GHz 2GB RAM client for the full range of tests listed in Appendix A.

Rather than chart the functions in the order that they were tested, they were

consolidated into groups. Aggregating the functions in this manner (rather than by

product area or business flow) provides a much clearer picture and highlights several

points that might have otherwise gone unnoticed. The dashed lines denote each

section in the chart. The first section shows the browser and login screen followed

by menus, then by OAF/HTML screens, Oracle Forms and finally Gantt Charts.

Note that the last form, the Supply Chain Planners Workbench Form is a necessary

precursor to its associated Gantt chart. The last two sets of results are the same

Gantt chart, without and with data. It is important to bear in mind that the amount

of data in the Vision database is limited, but there is enough to show acorresponding variation.

Sequencing charts by type brings

highlights anomalies and patterns are

easier to notice.

http://blogs.oracle.com/schan/release12http://blogs.oracle.com/schan/release12


29/60

Figure 11: Working Set and Private Bytes for the Full Range of Tests



30/60

While the chart may or may not show the exact screens that you use, generalizations

provide guidelines for rough estimates. There are several distinct levels in the chart,

which form the basis for the following generalizations:

While it is possible to generalize, the

amount of data that is displayed may

dramatically increases the memory profile,

especially on large Gantt charts.Menus: The amount of memory varies depending on the number

of items. It is interesting that Firefox 2 has the poorest footprint

when used with large menus. As well as being a reason to keep

menus small, this is important enough to warrant moreinvestigation, and is discussed in the Comparing Menus section.

OAF/HTML Screens: Most of these have the same memoryprofile peaking at around 40MB Working Set (excluding

Dashboards) with Internet Explorer (which also has the highest

memory footprint). Although self-evident, if you have memory

constrained clients, using OAF/HTML screens is preferable to

forms as they have a smaller footprint. This is something that you

may want to consider when creating your own custom or bespoke

applications.

Dashboards: Although a part of the OAF/HTML screens group,these differ fundamentally, as they render several graphs and

charts that have no associated data. As these graphs and charts are

rendered as graphics, the memory footprint is unlikely to change

regardless of the amount of data. It is notable that IE7 has a

substantially higher footprint.

Forms: The first four forms have an almost identical footprint,which is not surprising as they all use the same JAR files. The

forms between the Contact Centreand Customer Interaction Historyare

also very similar, although they tend to use different sets of JAR

files. The two exceptions in this group, which both have

significantly higher memory profiles as they are larger, are the Item

Costsand Order Entryworkbenches.

Gantt Charts: These have the highest memory footprint, andagain, are all very similar. The last two sets of figures show that

the amount of data being displayed does make a difference to the

amount of memory that they require. While the Vision database

does not contain much data, some customers have noticed

exceptionally high memory requirements with these charts and

therefore you may need to consult users to establish how much

data they regularly display on screen. If there is a performance

issue, then advise that reducing the amount of data (if possible)will bring temporary respite while you determine the amount of

memory that they require.



31/60

Average Memory by Oracle E-Business Suite Component Type

If you use a range of products, then the generalized benchmark figures such as the

browser averages for the full suite of tests shown in Figure 12 may be more useful. If

your Oracle E-Business Suite usage can be broadly categorized into OAF/HTML,

forms, or Gantt charts, it may be useful to focus specifically on that area (bearing in

mind that there may be exceptions). This chart shows the average memory utilization

(Private Bytes and Working Set) grouped by type for Oracle E-Business Suite 12using browsers with JRE across all of the tests on the 1.83GHz 2GB client.

Figure 12: Average Memory Utilization for Oracle E-Business Suite 12 Using JREGrouped by Type

To be more precise, you need to consider this chart and the amount of memory that

each browser shares with the other applications that users typically run

simultaneously. The amounts in this test as shown in Figure 1 are IE7: 9.6MB, IE6:

8MB, and FF2: 6.2MB. These relatively small differences indicate that Internet

Explorer 6 still appears to be the best choice for memory-constrained clients. Some

of these figures will be affected by the amount of data (such as Gantt charts,

customizations, and form folders) and it is important to note that these figures do

not scale linearly when using multiple forms or screens at the same time.

If a browser uses more memory, the

overall profile may reduce when

considering the amount of shared memory.

Reviewing the Ratio of Working Set and Private Bytes

The variation in Private Bytes to Working Set ranges between 5% and 30% for thefull set of tests. Examples of a very small difference include the Customer Interaction

Historyand Supply Chain Planners Workbench Form, with Firefox, and the Payables,

General Ledger and Project Forms with Internet Explorer 7. The original results are

shown in Figure 11. When the tests were repeated, the ratio increased, as did the

Working Set (marginally). As there was no change in the other applications being

used, you could infer that the frequency of tests resulted in the Windows memory

manager aggressively trimming memory.



32/60

It follows that if you restrict your measurements to Working Set in isolation, then

depending on the other applications that you use on your client, you could have

anomalous readings that would otherwise go unnoticed, even on a client with 2GB.

As noted in The Test Environment And Testing Issuessection, it was surprising how few

applications it took to change the memory model. For this reason, you always need

to compare Working Set with Private Bytes to provide a check point that will ensure

that process memory is not being trimmed without your knowledge.

Looking more closely at Figure 11, a very specific pattern of the ratio of Working Set

and Private Bytes emerges, as shown in Figure 13. The percentage difference is

substantially larger during the first half of the chart (login and OAF/HTML) as

compared to forms, and then there is another smaller step change to the Gantt

charts. Both forms and the Gantt charts have a substantially higher memory

footprint. This either implies that the Windows Memory Manager was trimming to a

greater degree, thus dropping Working Set while Private Bytes stayed the same, or

perhaps that the different set of Forms used fewer shared memory objects between

them, thereby raising Private Bytes while Working Set stayed the same.

Using different views of the same set of

results sometimes helps to validate an

investigation.

Figure 13: The Relationship between Private Bytes and Working Set

If you think it unlikely that Windows was trimming the process, you need to

consider other factors that may cause this behavior. For example, the amount of

shared memory, or some other memory structure, could vary between the different

types of forms and screens. As all browsers exhibit the same step changes, any

browser will show this effect. The amount of shared memory is determined by the

set of applications that are running simultaneously, and measurements from Internet

Explorer 7 are shown in Table 7. This shows that the difference between the

functions is minimal, in which case shared memory cannot be the reason.



33/60

Function Memory (KB)

Browser 9708

Login Screen 12344

OAF/HTML Screens 12444

Menu 12998Oracle Forms 13400

Gantt Charts 13588

Table 7: Shared Memory by Product Group

Comparing Menu Memory Utilization

The memory utilization and the number of items in each menu are compared in

Figure 14. The Main (Choose Responsibility) menu (110 items) and Payables

menus (280 items) have relatively few items and display quickly. The final three

menus are substantially larger. Enterprise Asset Manager Menu (1200 items),Manufacturing and Distribution Manager Menu (2650 items) and Order

Management Super User Menu (1650 items) take substantially longer and have a

larger memory footprint.

Keep menus small especially in low

bandwidth situations

(latency is not as important).

Figure 14: Menu Memory Utilization

Trimming a large menu results in a reduction of the memory utilization from 63MB

to 27MB; this represents a saving of almost 50%. With menus in particular,

bandwidth is the primary network constraint; latency has a much lower affect. For

example, for all latencies from 50ms to 300ms, the Manufacturing and Distribution

Manager Menu takes almost a minute to display on a network with only 256Kbps

available bandwidth, and almost two minutes with 128Kbps available.



34/60

Clearly, the memory utilization and bandwidth concerns are sufficient reason to keep

menus small whether memory-constrained, or working over a high latency or low-

bandwidth connection. This is true even though the memory utilization for multiple

forms and screens (as used in a complete business flow) does not scale linearly.

Firefox exhibits a high memory utilization compared to Internet Explorer, which

appears to scale more linearly in proportion to the number of items being displayed.

However, keeping menus small will reduce this difference between the browsers.Some customers combine menus under a single responsibility, so they can take

advantage of being able to keep multiple forms open. If this is not something you

have considered, the only complication that you need be concerned with is profile

option precedence (user, responsibility, application, site) and ensure that the profile

options are set at user level (and not defaulting from the responsibility level).

As the time to display a menu was identified and logged as a result of these tests, you

will need to review Oracle bug 6329486 for possible patches.Review Oracle bug 6329486 for possible

patches.

Comparing Memory Profiles across a Range of Clients

This test compares performance across four of the PC clients detailed in Table 2 that

represent the range of memory being considered (128MB, 256MB, 1GB, and 2GB).Two salient factors are that the CPU and technology inevitably varies across the

machines (which is not relevant for this test) and that 128MB is below the minimum

Windows and Oracle specification. The software on the three smaller machines was

kept to a minimum of essentially Oracle E-Business Suite, Process Explorer,

ZoneAlarm, Norton AntiVirus, and the default set of background processes. Tuning

the Windows environment did not significantly affect the memory profile. A handful

of standard Windows tuning practices were employed to improve performance (as

listed in Appendix B), but all of them failed to significantly reduce or stabilize the

browser memory footprint.

Figure 15 shows the Working Set for the full range of tests and color-coordinatedcallouts containing selected sections of Private Bytes, which can be easily mapped

back to the original client using the colors and/or machine specification. Including

full graphs for Private Bytes made the chart overly complex and hid some of the

detail.

The callouts show the Private Bytes (same

color as the main chart) and Working Set

(shown in red) for each of the four clients

As indicated by the browser offset shown as the first measurement in the chart, the

initial browser offset was not compensated for on the two smallest machines with

128MB and 256MB respectively. Both of these small clients have an almost identical

memory profile, though it took a very long time for the Gantt charts to be rendered

and the stability of the undersized (128MB) client was questionable due to the

amount of thrashing observed. The 1GB client starts by following the same

coordinates as the 2GB machine, until the memory requirements suddenly increasewith forms and Gantt charts. At this point the Working Set on the client with 1GB is

less than on the client with 2GB. Recalling that working set is the physical memory

pages that are dedicated to a specific process, the somewhat surprising conclusion is

that Windows must be aggressively trimming the process on the client with 1GB.

Although the pages will most likely be in memory (on the standby or modified list),

there is still a finite cost in recovering and making them available to the parent

process when referenced again.



35/60

Figure 15: Oracle E-Business Suite 12 Memory Profiles across a Range of Clients

The callout on the left shows a sample of the Working Set and Private Bytes for the1.6GHz 1GB client. The ratio between these measurements appears exceptionally

consistent. Although they fluctuate through the remainder of the tests, they follow

the expected pattern (Working Set greater than Private Bytes) for all clients, until the

final stage of the tests containing the Gantt Charts. At this point, Private Bytes

(shown in red) exceed Working Set for all the clients with less than 2GB. Each of

the callouts on the right of the chart shows the Private Bytes and Working Set for

the WIP Discrete Job Workbench.

This represents a fundamental change in the expected profile, and is typically one

area where inadequate client memory results in performance problems and

consequently complaints from unhappy users. The worst profile and greatest

difference between the sets appears on 700MHz 256MB client, though to be fair, the

128MB client was really struggling for memory and so you would not expect

anything sensible from the memory figures. As you would expect, the 366MHz

128MB client also uses old technology, and so paging and other disk activity would

be slower than on the other clients.

Windows was trimming processes on a 1GB machine even when all running

applications were using less than 160MB. It is worth stressing again that if private

bytes exceeds working set for the majority of applications, either the client is running

too many applications, or (if all the applications are needed) you need more memory.

If Private Bytes significantly exceed

Working Set for the majority of

applications that have never been

minimized, run fewer applications

simultaneously or add memory.Comparing Load Times for across the Range of Clients

Unlike OAF/HTML screens and menus, E-Business Suite 11iand 12 forms and

Gantt Charts will download the necessary JAR files to the local client when a form is

accessed the first time. For example, using JRE 1.5.0_12 the Purchase Order form

downloads 10.3MB of JAR files, whereas a Gantt chart may require 19.3MB of JAR

files (the exact figures vary with the functions in use). Once JAR files have been

downloaded, they remain valid for the browser session. They are revalidated if you

restart the session, but not if you switch forms or responsibilities.



36/60

Comparing Load Times across Fast Clients

The Oracle E-Business Suite load times were compared for the same four clients

used in Figure 15, for the full range of tests excluding the measurement for the WIP

Discrete Job Workbench with no data. Again, reviewing all the data in one graph is

cluttered, and therefore a range of graphs have been used. When reviewing the

charts, note that the Y-axis scale has been changed in order to highlight key

elements.

Figure 16 compares the initial and subsequent load times for two fastest clients.

Remember that JAR files need to be downloaded the first time they are used, and the

download time will be influenced by network characteristics such as latency and

available bandwidth. In high-latency situations, using a local proxy server will help to

alleviate network problems and improve download times. The client specification is

listed in Table 2. Although CPU benchmarks are not very representative, the

1.8GHz Mobile Core is allegedly equal to a 3.43GHz Pentium (non Intel sources),

though this has not been verified.

Figure 16: Comparing Initial and Subsequent Load Times

Accepting a small margin of error, the times for each of the clients for the initial

login and menu are comparable for each of the clients (menus do not use JAR files).

The times to load the large menus are relatively long, even though these are the

fastest clients in the test and they are being loaded over a low latency LAN.

The difference in client speed is very clear in the forms and Gantt chart sections. As

expected, the fastest machine (which usually commands a price premium) provides

the best response times. Downloading the JAR files is generally a one-off operation

and most of the time you will be working with locally cached (downloaded) JAR

files. The relative performance of the two fastest clients is very similar, bearing in

mind that both machines are very lightly loaded in terms of the number of

applications that are running.



37/60

There is only about 2 seconds difference in response times between the two fastest

clients even though they are a generation apart in technology terms, and one will

cost more than twice as much as the other.

The fastest client that commands (which a

price premium) is not significantly faster,

and the evidence suggests that CPU

definitely less important than memory.

You can calculate the amount of time spent validating the JAR files by subtracting

the validatedand first usefigures. Notice that the graphs converge at two points in the

forms section. The reason is that in order to get to these forms, you have to navigate

through other forms, so the previous business flow validated the JAR files.

Comparing Reload Times

Figure 17 compares the load times for forms that were previously used in the same

session. This is more representative of normal user operation (with cached and

validated JAR files) where users will iteratively cycle through the same set of forms.

Notice that the vertical scale has been changed to 100 seconds, which is a very long

time to sit waiting for a screen update. The 366MHz actually takes 172 seconds for

the final Gantt chart (Supply Chain Planners workbench) with the majority of the

time spent paging memory; the machine ended up in an almost unusable state.

Changing the scale of your graphs may

highlight features that are otherwise

difficult to notice.

Figure 17: Comparing Load Times for Forms Previously Used in the Same Session

Both of the smaller clients perform very poorly when rendering large menus and the

graphics-rich dashboards. While this chart provides an overall picture of what is

happening, expanding the Y-axis scale to 30 seconds, as in Figure 18 really highlights

the differences.

While technology does not generally scale linearly, the 366MHz is approximately

twice as slow as the 700MHz. The 366MHz appears to work almost as well as the

rest of the machines for small OAF/

PC_Client_Performance[1]

Documents

Transcript of PC_Client_Performance[1]