IBMSizingModel adempiere

Capstone – Thesis Report Leroy Pinto – 10039345

Sizing Model for the ADempiere Application S07-123

of 86

University of Technology, Sydney

Faculty of Engineering

SIZING MODEL FOR THE ADEMPIERE

APPLICATION

By

Leroy Pinto

Document Version Number: 2.3

Student Number: 10039345

Project Number: S07-123

Major: Computer Systems Engineering

Supervisor: Stuart Nettleton

Industry Co-Supervisor: Alan McNamara

A 12 Credit Point Project (48012) submitted in partial fulfilment of the

requirement for the Degree of Bachelor of Engineering

23 November 2007



of 86

Faculty of Engineering

Subject: 48012 – Capstone Assignment Number: 1 Date Submitted: 23/11/07 Assignment Title: “Sizing Model for the ADempiere Application” Capstone Thesis Report Student Name(s) and Number(s) Tutorial Group: Leroy Pinto 10039345 Declaration of Originality: The work contained in this assignment, other than that specifically attributed to another source, is that of the author(s). It is recognised that, should this declaration be found to be false, disciplinary action could be taken and the assignments of all students involved will be given zero marks. In the statement below, I have indicated the extent to which I have collaborated with other students, whom I have named. Signature Statement of Collaboration:



of 86

Abstract

Enterprise Resource Planning (ERP) is an industry term for a broad set of activities,

supported by a software application, which adds value to a business. For example, a

manufacturer managing the critical sectors of its operations, such as interacting with

suppliers, would benefit from the implementation of an ERP application.

ADempiere, an Open Source ERP Solution, is a powerful tool for businesses. ADempiere

provides all critical functionalities expected from a commercial-grade ERP-CRM

software application, such as financials and Supply Chain Management (SCM).

For large scale commercial ERP software applications to add value they require adequate

sizing models and performance testing frameworks. These functions allow for effective

planning, overall costing and satisfying resource needs of a business. ADempiere lacks a

sizing model and performance testing framework. In respect to this present gap, this

Capstone project’s main objective is to determine the best way to fill this requirement and

contribute to the existing and future ADempiere community. This will be achieved with:

� An ADempiere Implementation Plan

� An ADempiere Performance Testing Framework

� An ADempiere Sizing Model

The ADempiere sizing model is to be developed using the IBM Work Load Estimator.

The Work Load Estimator is a useful tool in determining the hardware characteristics

needed for a business wishing to pursue an Open Source ERP solution. The Workload

Estimator provides current and future growth recommendations for the hardware

characteristics of the system, which satisfy the client’s needs.

This Capstone Thesis Report outlines and details the successful implementation and

optimisation of ADempiere, on the IBM System i, under SUSE Linux Enterprise Server

10. Using an Open Source commercial grade performance testing application, named

WebLOAD, a performance testing framework was developed to assist the ADempiere

community.



of 86

Acknowledgement

This thesis would never have reached its present form, without the contribution of many

people. The material for this deliverable has been from a variety of contributors, outlined

in section 9. I would like to make special thanks to the ADempiere Open Source

community, special thanks to (Trifon Nikolaev Trifonov, William Grayson Heath) and

IBM Innovation Centre Australia – John Schilt, Prasad Mucherla and Felix Fong for their

willingness, support and enthusiasm in collaborating on the production of this work. I

would also like to thank Phuong Hoang (UTS Engineering Capstone Student) for his

assistance to various parts of this Capstone Thesis Report.

I would like to express my appreciation to the WebLOAD Open Source community for

their assistance in the area of performance monitoring and java scripting.

I would also like to express my sincere appreciation to my supervisors Stuart Nettleton

(UTS Engineering), Alan McNamara (Badja Consulting) and the Faculty of Engineering

for their support.

Sign Here

Leroy Pinto

Sydney/Australia 2007



of 86

Table of Contents

Acronyms and Abbreviations ............................................................................................. 9

Definitions......................................................................................................................... 10

Semantics of Expressions ................................................................................................. 10

1 Introduction ............................................................................................................... 11

1.1 Project Background ............................................................................................ 11

1.2 Document Purpose ............................................................................................. 12

1.3 Document Scope ................................................................................................ 13

1.4 Assumptions and Considerations ....................................................................... 14

2 Environment Overview ............................................................................................. 15

2.1 Operating System ............................................................................................... 15

2.2 Java Development Kit & Java Run Time Environment ..................................... 16

2.3 Database server .................................................................................................. 16

2.4 PL/Java ............................................................................................................... 16

2.5 Application Server.............................................................................................. 16

2.6 ADempiere ......................................................................................................... 16

2.7 Web Client.......................................................................................................... 17

2.8 Performance Measurements Manager Profiling ................................................. 17

3 ADempiere ERP Architecture................................................................................... 18

3.1 Deployment Scenario ......................................................................................... 18

3.1.1 Hardware Constraints.................................................................................. 18

3.1.2 Hardware Characteristics ............................................................................ 19

3.1.3 Application Characteristics ......................................................................... 20

3.1.3.1 Client Tier ............................................................................................ 20

3.1.3.2 Web Tier .............................................................................................. 21

3.1.3.3 Application Tier ................................................................................... 22

3.1.3.4 Database Tier ....................................................................................... 22

3.2 Memory Tuning.................................................................................................. 24

3.2.1 Environment Setup...................................................................................... 25

4 Testing Methodology ................................................................................................ 26

4.1 Workload Validation .......................................................................................... 29

4.2 Maximum Connection Test ................................................................................ 30

4.3 Maximum Simultaneous Users Test .................................................................. 31

4.4 Traffic Surge Test............................................................................................... 32

4.5 Long Term Stability Test ................................................................................... 33

4.6 Why WebLOAD? ............................................................................................... 34

4.6.1 Constraints & limitations ............................................................................ 36

5 IBM Work Load Estimator & Recommendations on System i ................................ 37

5.1 Constraints and Limitations ............................................................................... 37

5.2 Relative Performance Analysis .......................................................................... 38

5.3 IBM Workload Estimator Validation ................................................................. 40

5.4 ADempiere Workload Estimator ........................................................................ 42

5.4.1 Sizing Model Walkthrough ......................................................................... 44

6 Future Directions ...................................................................................................... 46

7 References ................................................................................................................. 47

8 Appendices ................................................................................................................ 49



of 86

8.1 JBoss Application Server Performance Optimisation ........................................ 49

8.2 Performance Testing Results .............................................................................. 53

8.2.1 IBM System i 550 Work Load Validation .................................................. 53

8.3 IBM System i550 ............................................................................................... 54

8.3.1 2 Gigabytes RAM, 1 CORE........................................................................ 55



8.4 Other Performance Results................................................................................. 58




8.5 Test scenario ....................................................................................................... 62

8.5.1 Simple Test ................................................................................................. 62

8.5.2 Moderate Test ............................................................................................. 63

8.5.3 Complex Test .............................................................................................. 64

8.6 Test Scripts based on test scenario ..................................................................... 66

8.7 IBM Work load Estimator Attributes ................................................................. 67

8.8 Implementation Plan .......................................................................................... 71

8.8.1 Pre-implementation Tasks .......................................................................... 71

8.8.1.1 Java Installation ................................................................................... 71

8.8.1.2 PostgreSQL Installation ....................................................................... 72

8.8.1.3 PL/Java ................................................................................................ 74

8.8.2 ADempiere Installation ............................................................................... 77

8.8.3 Trouble Shooting ........................................................................................ 78

8.8.3.1 Error Database Port ............................................................................. 78

8.8.3.2 Error IbmX509 Key Store ................................................................... 78

8.8.3.3 Error JDBC .......................................................................................... 79

9 Project Proposal ........................................................................................................ 80

9.1 Timeline ................................................................................................................ 80

9.1.1 High level time line ........................................................................................ 80

9.1.2 Low level break down .................................................................................... 81

9.1.3 Low level Gantt Chart .................................................................................... 82

9.2 Risk Assessment ................................................................................................... 83

9.2.1 Risk Severity Matrix ....................................................................................... 84

9.2.2 Risk Response................................................................................................. 85

10 Document Control ..................................................................................................... 86

10.2 Version Control .............................................................................................. 86



of 86

List of Figures

Figure 1 – ADempiere Environment Overview ................................................................ 17

Figure 2 – IBM Innovation Centre Hardware Spec .......................................................... 19

Figure 3 – Web Tier & Application Tier .......................................................................... 21

Figure 4 – ADempiere 3 Tier Architecture ....................................................................... 23

Figure 5 – Sizing Model Process ...................................................................................... 26

Figure 6 – Testing Methodology....................................................................................... 27

Figure 7 – Authoring Environment ................................................................................... 35

Figure 8 – Execution Environment ................................................................................... 35

Figure 9 – Initial Testing - IBM System i (Linux) - Supported Users .............................. 39

Figure 10 – Initial Testing – IBM System i (Linux) – rPerf ............................................. 40

Figure 11 – ADempiere Sizing Process ............................................................................ 42

Figure 12 – ADempiere Sizing Process Breakdown......................................................... 43

Figure 13 – Sizing Model Walkthrough – Data Entry ...................................................... 44

Figure 14 – Sizing Model Walkthrough – Recommendation ........................................... 45

Figure 15 – 1 User, Hit time, Page Time, Response Time ............................................... 54

Figure 16 – 1 Core, 2GB – Page time, Hit time, Round Time .......................................... 55

Figure 17 – 2 Core, 4GB – Page time, Hit time, Round Time .......................................... 56

Figure 18 – 4 Cores, 8GB – Page time, Hit time, Round time ......................................... 57

Figure 19 – 1 Core, 2GB – Hits, Pages, and Throughput ................................................. 58

Figure 20 1 Core, 2GB – Context Switches (Thread switching), CPU Usage ................. 58

Figure 21 – 1 Core, 2GB – Disk Operations ..................................................................... 59

Figure 22 – 2 Cores, 4GB – CPU Usage .......................................................................... 59

Figure 23 – 2 Cores, 4GB – Disk Operations ................................................................... 60

Figure 24 – 4 Cores, 8GB – Context Switches (Thread switching), CPU Usage ............. 60

Figure 25 – 4 Cores, 8GB – Disk Operations ................................................................... 61

Figure 26 - High level Gantt Chart ................................................................................... 80

Figure 27 - Low level Gantt Chart .................................................................................... 82

List of Tables

Table 1 – Acronyms ............................................................................................................ 9

Table 2 – Definitions ........................................................................................................ 10

Table 3 – Semantics of Expressions ................................................................................. 10

Table 4 – Hardware Constraints ....................................................................................... 19

Table 5 – Hardware Characteristics .................................................................................. 19

Table 6 – Environment Setup ........................................................................................... 25

Table 7 – Workload Validation......................................................................................... 29

Table 8 – Maximum Connection Test .............................................................................. 30

Table 9 – Maximum Simultaneous Users Test ................................................................. 32

Table 10 – Traffic Surge Test ........................................................................................... 32

Table 11 – Long Term Stability Test ................................................................................ 33

Table 12 – Transaction Complexity .................................................................................. 39

Table 13 – WebLOAD Test Results –Validations ............................................................ 41

Table 14 – Workload Estimator – Validations ................................................................. 41

Table 15 - Milestone Plan & Task breakdown ................................................................. 81



of 86

Table 16 - Risk Analysis ................................................................................................... 83

Table 17 Severity Risk Table ............................................................................................ 84

Table 18 - Risk Response Table ....................................................................................... 85

Table 19 - Version Control ............................................................................................... 86



of 86

Acronyms and Abbreviations

Acronym Definition

API Application Programming Interface

AJP Apache Jserv Protocol

CRM Customer Relationship Management

EJB Enterprise Java Beans

ERP Enterprise Resource Planning

HTTP Hyper Text Transfer Protocol

IEEE Institute of Electrical & Electronic Engineers

J2EE Java 2 Enterprise Edition

JDBC Java Database Connection

JDK Java Development Kit

JNDI Java Naming Directory Interface

JSP Java Server Pages

PMM Performance Measurements Manager

RAID Redundant Array of Independent Disks

rPerf Relative Performance

SCM Supply Chain Management

SLES SUSE Linux Enterprise Server

SME Small or Medium Enterprise

Table 1 – Acronyms



of 86

Definitions Name Description

Round Time The amount of time required to run one round of the Agenda

Page Time The amount of time it takes for a page to load

Hit Time The time it takes to complete a successful HTTP request. The Hit time

is the sum of the Connect time, Send Time, Response Time and

Process Time.

Connect Time The time it takes for a virtual client to connect to ADempiere.

Response Time The time it takes for ADempiere to send a HTTP request back to the

virtual client.

-Xmx This is an argument to the java application which sets the maximum

java heap size.

-Xms This is an argument to the java application which sets the minimum

memory allocation pool.

Swing Client This is a J2EE thick client which has a rich graphical user interface

deployed from the user’s desktop. Table 2 – Definitions

Semantics of Expressions

Name Description

Shall Mandatory expression

Will Indicates willingness and intent

Should Optional task that may not be applied due to constraints

Table 3 – Semantics of Expressions



of 86

1 Introduction

1.1 Project Background

Enterprise Resource Planning (ERP) is an industry term for a range of services that

provide functionalities to a business. ERP systems integrate all data and process of an

organisation into a single system. Multiple components of software and hardware are

used for the integration. This is obtained from a unified database to store the data from

various sub system modules (Infosys Technologies, 2007). These functionalities help to

manage the important parts of a business, including product planning, maintaining

inventories, interacting with suppliers, providing customer service and tracking orders.

A Sizing Model is a compressive manual which enables the client to customise the needs

of their business. A Sizing Model’s main objective is to provide hardware

recommendations to the client while minimising operating costs. (Bilanych, J., Sykes H)

The IBM Power Platform is a robust high end computer system, the IBM System i and p

are flexible option packages that help reduce complexity and maximise businesses value.

The IBM Power Platform provides a reliable, highly secure way for a Small Medium

Enterprise (SME) to simplify their IT and reduce cost to invest in a growing business.

(Bilanych, J., Sykes H)

ADempiere is a new commercial grade ERP software application which adds value to a

businesses services, accountings and processes. ADempiere, for the first time ever – has

been implemented on the IBM Power Platform (section 8.8).



of 86

1.2 Document Purpose

This document will detail, through verifications and results provided as part of this

Capstone project research, that an ADempiere implementation on the IBM Power

Platform is a viable option. The combination of the two shall have benefits to both, the

open source community and the Small-Medium Enterprises (SME).

However, for large scale commercial ERP software applications to add value, adequate

sizing models and performance testing frameworks are required. These functions allow

for effective planning, overall costing and satisfying resource needs of a business.

Presently, ADempiere lacks a sizing model and performance testing framework. In

respect to this present gap and problem, this Capstone project’s main objective is to

determine the best way to fill this requirement and contribute to the ADempiere

community. This will be achieved with:

• An ADempiere Implementation Plan

• An ADempiere Performance Testing Framework

• An ADempiere Sizing Model



of 86

1.3 Document Scope

The scope of this document is limited the sub sections listed below:

• Introduction

• Environment Overview

• ADempiere ERP Architecture

• Testing Methodology

• IBM Workload Estimator & Recommendations on System i

• Future Directions

• References

• Appendices

Document Assumptions and Exclusions:

• This document specifies to only use ADempiere 3.3.0 and above.

• The author of this document holds no guarantees or representations that the

ADempiere deployment scenario will be successful.

• The information provided and the recommendations made are based on an

existing lab-tested environment design. These designs do contain margins of error

that can be reduced only if additional testing is undertaken. The methodologies in

this document will help to provide the resources and tools for your specific

environmental needs.

• This document is only designed for the amount of users prescribed; however it

can be used as a guide for further growth testing.

• Recommendations provided in this document assume the audience has applied the

latest software prerequisites, updates, and patches for the ADempiere ERP

application.



of 86

1.4 Assumptions and Considerations

• Complex solutions, such as when there are large number of transaction points,

complex java scripting, or work flow processes coupled with a very low ‘think

times’ between transactions, may require significantly larger hardware

requirements that are specified within this document, in these instances this

document may not apply.

• The architectural scenario outlined in this document may not resemble the

production environment of the audience. This document assumes when the

database resides in the same system as ADempiere, the data and hardware system

resources are generally distributed evenly.

• Deployments greater than the recommended concurrent users require a more

detailed analysis and more testing to be completed by the party. Detailed analysis

of business requirements, existing infrastructure and proposed data size, and

transactional value needs to be analysed. This document should not be used for

anything greater than the recommended users supported. This document’s testing

methodology works within the constraints limited by the scope of this document,

and may not be applicable to anything that exceeds it. However it should be used

only as a guideline to conduct testing on the required infrastructure.



of 86

2 Environment Overview

The ADempiere ERP environment is a collection of software components. These

components co-operate together to produce a unified system. SME require a robust,

efficient and low maintenance solution for an ERP environment. The IBM Power

Platform is a means of providing ADempiere to a SME without the need to worry about

bundling multiple software/hardware components. From the research undertaken, a

recommended ADempiere environment was chosen based on analysis and ADempiere

community recommendations.

The ADempiere ERP environment consists of the following (Figure 1 provides a

summary):

• Operating System – SUSE Linux Enterprise Server 10

• IBM Java 2 Development Kit

• IBM Java 2 Run Time Edition

• ADempiere 3.3.0

• Application Server – JBoss

• PL/Java 1.3.0

• Database – PostgreSQL 8.2.x

• Performance Measurements Profiling

2.1 Operating System

SUSE Linux Enterprise Server 10(SLES 10) edition by Novell was the primary operating

system used within the environment. SLES 10 was chosen to operate on the IBM Power

Platform because of its compatibility and support. SLES 10 provides a dynamic, and

relatively easy and reliable platform for ADempiere to run on alongside its software

components. In comparison, Red Hat Enterprise Linux was tested for implementation,

however due to compatibility issues with PL/Java 1.3.0 – SLES 10 constituted to be the

optimal solution.



of 86

2.2 Java Development Kit & Java Run Time Environment

The IBM Java 2 Development tool kit was used in this environment because of its

compatibility and optimisation with IBM Power Platform.

2.3 Database server

The ADempiere Database Server is primarily used for storage and processing data.

Currently the ADempiere community recommends using PostgreSQL. Thus far, the

database server uses PostgreSQL.

2.4 PL/Java

PL/Java is a free add-on module which allows java stored procedures, triggers and

functions to be accessed by the PostgreSQL backend.

2.5 Application Server

The ADempiere Application server is primarily used for serving the ADempiere

application processes, work flows and data forms. ADempiere utilises the JBoss

Application Server, this is an Open Source Java 2 Enterprise Edition (J2EE) server.

JBoss is a pure Java based server; this allows any java based application to be deployed

onto the JBoss application server for hosting the ADempiere ERP application. It must be

noted that most J2EE application servers will be able to support ADempiere; more likely

of a choice would be the IBM Web Sphere Application Server. However, due to time

constraints the implementation of this is excluded from this document. As a result, JBoss

was chosen in this environment, since it is the most widely used application server within

the community.

2.6 ADempiere

ADempiere is an ERP Bazaar for Open Source Developers that contribute improvements

from various other ERP and Customer Relationship Management (CRM) software, as

well as other Business Applications in an open fashion. ADempiere is originally based on

the Oracle backed Compiere ERP application (ADempiere, 2007). ADempiere comes

packaged with JBoss.



of 86

2.7 Web Client

The ADempiere ERP system provides several options for using the software. The

simplest being the web based client. This client is very similar to the ADempiere java

swing client.

The web based client allows a user to access ADempiere through a Java 1.5.0 supported

web browser. This method is preferred as it allows performance testing to be duplicated

accurately; which allows simulation of many concurrent users.

2.8 Performance Measurements Manager Profiling

The Performance Measurements Manager (PMM) Profiling is a WebLOAD specific tool

used to gather performance metrics of the system, such as CPU utilisation, disk

operations (input/output), network utilisation, web page utilisation etc. This will usually

be excluded from deployments, but has only been incorporated in this deployment for the

purpose of performance analysis and testing.

Figure 1 – ADempiere Environment Overview



of 86

3 ADempiere ERP Architecture

The following architecture diagram describes the deployment scenario used within the

IBM Innovation Centre to conduct performance testing on the ADempiere ERP

application. The architecture and deployment scenario was configured in such a way that

it was compatible with the majority of the ADempiere community.

3.1 Deployment Scenario

In this deployment Scenario, figure 2 represents the hardware model ADempiere was

tested on. The following two sections will describe the hardware and application

characteristics of ADempiere system.

3.1.1 Hardware Constraints

The deployment scenario consists of several hardware constraints that limit the

environment where ADempiere is deployed to (figure 2). This section analyses the

hardware constraints in three layers:

1 Load machines

2 Network Constraints

3 System Under Test (IBM System i550)

Hardware Constraints

Element Constraints Description

Load Machines • Resource contentions were placed upon the

amount of load machines available for stress

testing on the IBM System i550

• Load machines were only capable of producing

loads outlined in section 3.1.2

Network Constraints • Although network latency was not an issue, it is

important to highlight the effect a low bandwidth

connection may place on ADempiere.

• Network may be unreliable

• Latency is non zero



of 86

System Under Test • Resource contentions were placed upon the

availabilities of the IBM System i550, and other

IBM Power series. Testing was conducted in a

series of incremental steps to show a wider range

of scenarios. Testing was conducted on the IBM

i550 in the following segments:

o 1 Core – 2 Gigabytes

o 2 Cores – 4Gigabytes

o 4 Cores – 8 Gigabytes Table 4 – Hardware Constraints

3.1.2 Hardware Characteristics

Element Description

Terminal The user who is controlling WebLOAD

WebLOAD/Users The virtual concurrent users who are running on the load

machines

W10 Intel Pentium III 864Mhz, 1 Core, 1Gigabyte of RAM, Windows

XP load

Machine – capable of producing 1000 concurrent users

X93 Intel Xenon 3GHZ, 4 Cores, 6Gigabytes of RAM, Windows

Server 2003 load machine– capable of producing 2800 concurrent

users

X94 Intel Xenon 3.6GHZ, 2 Cores, 3.12Gigabytes of Ram, Windows

Server 2003 load machine – capable of producing 1800

concurrent users

IBM DMZ IBM demilitarized network zone; this is the location where the

i550 server is located. This network is a 1 Gigabit Ethernet

network which connects the load testing machines (w10, x93 and

x94) to the i550.

IBM System i550 IBM System i server, where ADempiere has been implemented.

The IBM System i550 has 4 Cores and 16 Gigabytes of RAM

available. Load testing was conducted on the i550 in a series of

incremental steps, using the methodology described in section 4

of this document Table 5 – Hardware Characteristics

Figure 2 – IBM Innovation Centre Hardware Spec



of 86

3.1.3 Application Characteristics

The following section will explain figure 4 in detail. Figure 4 details the links between

four conceptual tiers, namely – the Client Tier, Web Tier, Application Tier and Database

Tier.

3.1.3.1 Client Tier

The Client Tier is an important layer in the overall environment of ADempiere. It is

important to not confuse the client with the ADempiere application. This is a popular

misconception when an end user is using a J2EE application. It must be understood that

the client is merely an interface to the other tiers. The client only allows communication

to take place between the end user and ADempiere. The client presents the views to a

user and tracks the conversational state between the server and itself, effectively

conversing with the ‘adempiere.ear’ application. (Singh, I, et al. 2002, p. 51)

The Hypertext Transfer Protocol (HTTP) is used to communicate the actions between the

end user and ADempiere. The Client Tier is constrained by the network in a real life

scenario, where latency is non-zero, bandwidth is finite and the network may not always

be reliable. The client has to be able to adapt to these scenarios. The client should only

connect to the server when it has to, transmit only as much data as it needs to, and works

reasonably well when it cannot reach the server. (Singh, I, et al. 2002, p. 76)

Firewalls and other security aspects may also affect the ADempiere client; firewalls must

be configured to allow http transactions to pass through. Such as, particular Remote

Method Invocation (RMI), Java Naming Directory Interface (JNDI) requests and Java

Database Connection requests (JDBC).

J2EE platforms generally encourage thin-client architectures. Using a browser client

however provides low response times. (Veit, Daniel J. et al, 2007) The client depends

more on the application server for presentation logic, so it must connect to the server



of 86

whenever its interface changes. This causes the browser client to make many connections

to the server which will be a problem when latency is high.

The browser application connects to the ADempiere J2EE application over HTTP. The

browser interfaces with the application by clicking hyperlinked texts and images; the

transaction is completed by submitting forms. These gestures are translated into HTTP

requests for the Web Tier, since the server provides an interface for the transactions to

occur. (Singh, I, et al. 2002, pp. 80-92) The Figure 3 shows the concurrent virtual users

are very much the same as a normal user.

3.1.3.2 Web Tier

The Web Tier is the second point of contact for a user. It processes the HTTP GET &

POST requests from the Client Tier and forwards the requests to the Application Tier.

This shows the web tier is primarily a request-response system, individual requests are

treated independently.

Consequently the ADempiere application needs a mechanism for identifying a particular

client and state of the conversation. Catalina provides an http state session management

mechanism which allows a conversation to be tracked and stored. The Web Tier provides

the support to handle Java Server Pages (JSP) and Servlets. The Web Tier is primarily a

container for the Application Tier’s modules, shown in figure 3.

Figure 3 – Web Tier & Application Tier



of 86

3.1.3.3 Application Tier

The Application Tier is the third point of indirect contact from the user. The connection is

indirect because the Application Tier is not directly driven by the Client Tier; rather it is

directly driven from the requests the Client Tier sends to the Web Tier. Figure 4 shows

this interaction.

The Application Tier provides the functionality of ADempiere as a J2EE application.

ADempiere uses Java Server Pages (JSP). The JSP’s are a way to create HTML pages by

embedding references to the server logic within the page. (Gould 2005) The Application

Tier is the single most important tier in the scheme. It performs and controls the entire

functionality, protocols and services specific to ADempiere, however it does not store the

persistent data itself, rather it contacts the Database Tier for this information. (Gould

2005) The core business logic, and data access is stored in Enterprise Java Beans (EJB)

and JDBC drivers, shown in figure 3. EJB’s primarily use the RMI protocol, to invoke

methods to pass data between the client and ADempiere.

3.1.3.4 Database Tier

The Database Tier is very much in the same line as the Application Tier, even though it is

in the last stage in figure 4. This is because the Database Tier stores and retrieves data

through EJB’s. EJB’s utilise the JDBC driver to make a connection between the

Application Tier and the Database Tier. (Madduri H, et al., 2007)

The Database tier is responsible for managing updates, allowing simultaneous concurrent

access from the application server, providing data integrity and security. The ADempiere

database by default includes sample data which allows basic transactions to take place on

a first time implementation. (Madduri H, et al., 2007)

The user never directly communicates with the Database Tier; rather the Application Tier

uses the JDBC driver to gather data to forward to the Web Tier. The Web Tier then

presents the information through to the Client Tier using its Servlets. This flow of

interaction is also traceable through figure 4.



of 86

Figure 4 – ADempiere 3 Tier Architecture



of 86

3.2 Memory Tuning

Java memory tuning and garbage collection are a critical issue with the use of IBM Java

and ADempiere. There are primarily two areas in memory that can be tuned and

controlled in Java. The first being the Java heap, this is where ADempiere objects that are

not primitive stack variables are allocated. The Java stack is the second area in memory

that is controllable. The java stack contains the call stack and former primitives. (Oliver,

A. 2006)

Primary importance is given to the java heap as it is the heap that is ‘garbage collected’.

The stack is allocated on a per thread basis. There is no exact way to determine the exact

amount of memory ADempiere requires, therefore testing is essential. The minimum and

maximum heap size should be set to the same value on the IBM System i and p. (Chawla,

S. 2003) If the heap utilisation grows when usage is at its peak, then a performance spike

will occur. Usually ADempiere will raise a java dump due to the interaction between

heap resizing and garbage collection. It is important to set the thread stack size to 1MB

per thread. This may sound relatively small, however in a busy environment with

ADempiere running at peak; it is easy to have hundreds of threads running. You may

experience a “Cannot create native thread” or “Out of memory error” if the thread stack

size is set too large for the system.

Section 7 will tabulate the maximum and minimum heap size required for ADempiere, an

ideal rule of thumb is to set the maximum and minimum heap size to 75% of the total

memory available on the system. (Oliver, A. 2006)

The maximum heap size can be set for ADempiere in the following directory:

/opt/ADempiere/utils/myEnvironment.sh

ADEMPIERE_JAVA_OPTIONS=”-Xms1484M –Xmx1484M –DADEMPIERE_HOME=$ADEMPIERE_HOME”

The above shows that the minimum and maximum heap size. The Java heap will not have

to grow from its minimum heap size to keep up with the initial growth, if the maximum

amount of memory has already been allocated to the system. (Chawla, S. 2003)



of 86

When performing tests ensure you run the following command to log all garbage

collection:

nohup vmstat 60 5000 > amountofusers_loadtype_amountofmemory.out &

Often during heavy performance testing a java error may occur in the adempiere.out log

which states an “OutOfMemoryError” exception, this will especially occur when running

a large amount of complex transactions the system cannot handle. This is usually because

heap utilisation grows and a performance spike occurs, which will require a larger –Xmx

value.

The following section describes in a table the environment setup that has been tuned from

testing ADempiere at least 5 times.

3.2.1 Environment Setup

The following section will detail the maximum amount of memory allocated per

environment for ADempiere. These values were gathered and tuned through an iterative

approach to testing ADempiere.

IBM i550

Cores RAM Total Min Heap Size Max Heap Size

1 2GB 1484 1484

2 4GB 3024 3024

4 8GB 6138 6138 Table 6 – Environment Setup



of 86

4 Testing Methodology

The following testing methodology will be used to structure and develop a plan for

ADempiere’s performance testing environment. The testing methodology will be used in

conjunction with WebLOAD as a performance and load testing guide. The methodology

will help to understand the performance boundaries of ADempiere. Figure 5 provides a

structural process of the procedures and methodologies outlined in this document.

Environment &

Architecture

Analysis

Implementation

Plan

Testing

Methodology

AnalysisSystem

RecommendationValidation

Figure 5 – Sizing Model Process

This methodology involves several critical attributes, which apply for different scenarios

that follow an incremental stepped approach to testing. This stepped approach has been

undertaken because; users often exhibit erratic behaviours that can cause significant

performance issues within ADempiere. Along with users, the network which ADempiere

is connected to may exhibit issues of its own. (Halnes, S, 2005)

� System Usage: Many users may simply load the main ADempiere work flow

screen and logout. Others may simply idle, while other users may perform queries

on certain partners or sales. (Joung, P. 2003) Usage behaviours can affect network

systems, such as many concurrent users downloading a PDF report. Capturing and

simulating to represent these behaviours will create better test results.



of 86

� Think Times: The amount of time a user spends between each work flow and a

screen within ADempiere is called the think time. The performance testing tool

should have the functionality to vary this think time to a realistic situation.

(Joung, P. 2003) For example, a user who is unfamiliar with ADempiere will have

a large think time; however a user who is advanced in ADempiere will have a

very low think time.

Sections 6.1 to 6.5 are general tests which describe how to conduct the ADempiere tests

with WebLOAD. Figure 6 outlines the testing methods of ADempiere with the use of

WebLOAD. It must be noted, the testing methodology figure shows a repeated process.

Testing shall only be completed once the tester has gained enough confidence in the

system, and the results produced before any further processing/analysis occurs.

Figure 6 – Testing Methodology

Each test shall identify the goal of the testing, and the procedure required to manipulate

ADempiere to extrapolate the desired outcomes that shall correspond to the stated test

goal. It must also define what specific feature should be tested and the amount of time

allocated to the test.



of 86

The most important factors to incorporate into each test are:

• Tests should be designed to fail the system

• Tests should determine performance defects

• Tests should locate bottle necks

• Tests should be flexible to evolve and respond to different factors

The most efficient way to resolve issues is to use a systematic approach to testing; change

only one feature at a time will help to isolate particular system issues, and problems with

the infrastructure and environment setup of ADempiere. For example, during a test, and

after a test, be sure to analyse the results which may show the database is having

problems. A fix for this scenario might be to increase memory on the database side.

Testing will usually occur at least three times for the fix to be confirmed. The tests

outlined will focus these efforts on the most important factors in ADempiere, which also

have the potential to compromise network traffic.

Methodology Definitions:

• Result: What the test will accomplish

• Purpose: Explains the value and goal of the test, and any other background

information.

• Test specification: The load to apply during the test. Mainly concurrent virtual

users.

• Constraints: Details any value which should not be exceeded during the test.

• Time estimate: The amount of time taken to run the test

• Type of workload: This defines if a linear test or a ramp test will be used as the

work load.

• Methodology: A list of procedures which define how to conduct the test

• Problems Encountered: Contains information on what errors to pay attention to

during the test.



of 86

4.1 Workload Validation

The following is only a minimal workload test to verify that the ADempiere environment

is functional; the test is also a basis for the development of the constraints listed in

section 4.3.

Result

This test is a functional environment test for ADempiere. The test

will ensure proper functionality with minimal loads. This is not a

stress test in itself; instead every other methodology described will

use this to ensure a valid environment.

Purpose This test helps ensure the work load functions correctly on the

ADempiere environment. This work load will also help to discover

basic environmental errors, such as connectivity issues or syntax

errors with test scripts. This methodology should be run before any

other test.

Test specification Users

Constraints 1 User then scale to 10 users

Time estimate Run time: 10 minutes

Type of workload Linear test

Methodology 1. Select the Linear work load in WebLOAD

2. Configure WebLOAD to ramp traffic for 1 User, run time

of 10 minutes and concluding with 1 user

3. Configure the Performance Manager to monitor all

statistics on the ADempiere environment.

4. Run the test

5. During the test, use the WebLOAD Reporter Manager

interface to look for errors. Also ensure to track and view

the adempiere.out application log while the tests are

running with “tail –f adempiere.out”

6. After the test has completed, analyse the graph produced to

locate errors and particular system issues, or scripting

issues which may lead to HTTP 404 page not found errors.

7. Correct or resolve any errors encountered

8. Rerun the test until no more unexpected errors exist.

Problems

Encountered

Application level errors (java errors)

Application time outs

HTTP 404 & 500 response errors

Network level errors

Network timeouts

System configuration errors (inc. ADempiere memory related)

Unexpectedly long response times

Table 7 – Workload Validation



of 86

4.2 Maximum Connection Test

Result This test establishes the maximum number of connections the

ADempiere application and the network infrastructure will

successfully handle.

Purpose This test will help to understand the amount of traffic that will be

generated by a virtual user designed for ADempiere. It will also

help to understand and identify points to potential bottles in the

network infrastructure and the environment.

Test specification Connections per second

Constraints PostgreSQL to be disabled

Receive time does not exceed 15 milliseconds


Type of workload Use a simple script with a small think time, such as logging in a

client. During the test, the environment should encounter a high

rate of connections which are opening and closing, with fast

retrievals of small data.

Methodology 1. If the environment has been tested for an expected

maximum simultaneous virtual users, use the past number

as a guide. If the environment has double the hardware

specifications, times that number by two to develop a

guesstimate. During step 6. Look to see if ADempiere hits

its capacity if not, increase the virtual users and repeat.

2. Configure WebLOAD to use “Step Increments (Time

Calculate)”. Ramp up each step over a ramp time of 5-15

seconds, to ensure the system has the chance to make the

best effort at keeping up with the new load. Configure the

concluding Virtual Users to be set by the number

determined in step 1. Configuring the starting load to be 5

virtual users.

3. Run the test

4. Update the report so it displays the “Receive Time”

5. After this test find the level where the receive time does not

keep up with the traffic and errors are encountered, this will

detonate the maximum for the network. Use the reporter to

determine the maximum connection rate for the

environment.

Problems

Encountered

Often because of JBoss timeouts and TCP retransmissions, the

actual work load at failure is usually lower than what may be

indicated within the reporter.

Table 8 – Maximum Connection Test



of 86

4.3 Maximum Simultaneous Users Test

Result This test will determine the maximum amount of users the

ADempiere environment can successfully handle.

Purpose The work load shall provide the maximum users for ADempiere for

the specific environment. This will help to provide an understanding

of the total number of users ADempiere can handle on the

environment.

Test specification Users

Constraints Ensure the hit time does not exceed 0.67 seconds – 670ms

Total connect time does not exceed 0.008 seconds – 8ms

Total Response time does not exceed 0.015 seconds – 15ms

Total Page time does not exceed 3 seconds – 3000ms


Type of workload Linear workload with x amount of users for 30 mins, starting load

of 50 users. Use many persistent connections and long think times.

This will ensure many users are created and exist for long periods.

Methodology 1. Validate workload

2. If the environment has been tested for an expected

maximum simultaneous virtual users, use the past number as

a guide. If the environment has double the hardware

specifications, times that number by two to develop a

guesstimate. During step 6. Look to see if ADempiere hits

its capacity if not, increase the virtual users and repeat.

3. Configure WebLOAD to ramp up to a concluding x amount

of virtual users. Run time of 30 minutes, initial virtual users

of 50.

4. Configure WebLOAD to ensure each step exceeds the think

time of each user – approximately 15 seconds.

5. Run the test

6. During the test, use the WebLOAD Reporter Manager

interface to look for errors. Also ensure to you have turned

logging off in the log4j.properties in adempiere.ear file and

in JBoss.

7. After the test has completed, analyse the graph produced to

locate errors and particular system issues, or scripting issues

which may lead to HTTP 404 page not found errors.

8. Once you have identified the points that does meets to the

maximum hit time, page time, response time configure

another load to ramp up to 20% past that point.

9. Run the step with the new parameters

10. Afterwards, determine the maximum simultaneous user’s

again by finding the level at which the constraints are held,

and traffic continues without errors.



of 86

Problems

Encountered

Pay attention to time out errors, HTTP 500 Internal Server errors,

HTTP 504 Page not found errors. You may also need to enable

logging when running this test for the first time, because of the

nature of this test look connections may be kept open, but in fact

may be stalled, passing no useful traffic. To avoid this, enable

logging for the first time of running this test, and enable HTTP 200

OKAY status in WebLOAD reporting to determine if the

environment is functioning correctly. Table 9 – Maximum Simultaneous Users Test

4.4 Traffic Surge Test

Result This test determines the ability of ADempiere to handle large surges

in traffic

Purpose ADempiere may encounter a large traffic jump, in a busy

environment; these may be planned or unplanned transactions. This

test will help to determine if ADempiere will manage and deal with

these surges.

Test specification ADempiere http traffic and database test

Constraints Ensure the connection rate test does not exceed the rate determined

in the test

Keep bandwidth utilization limited to that the network can

withstand

Time estimate Specification: 30 minutes

Type of workload Ramp function

Methodology 1. Validate work load

2. Select the Ramp function within WebLOAD

3. Configure WebLOAD to ramp up the load with 500

users and end with x amount of users, holding for 30

minutes

4. Run the test

5. Analyse the results looking for performance bottlenecks

Problems

Encountered

Timeouts may occur with large number of open connections.

WebLOAD will report in the info bar if time outs occur, enabling

the HTTP 200 OKAY Measurement status in the WebLOAD

reporter can be used to confirm this. Table 10 – Traffic Surge Test



of 86

4.5 Long Term Stability Test

Result This test determines the ability of ADempiere to continue

functioning for a long duration, locating any memory leaks that

eventually cause system failure.

Purpose ADempiere may function in the short term; however unseen

memory issues usually occur in the long term. The goal of this test

is to determine the ability of ADempiere to function for long

periods of time under high traffic conditions. The load considered

should be much higher than what would appear in production to

ensure any stability issues are identified.

Test specification Memory, connections, stability of ADempiere

Constraints Ensure the connection rate test does not exceed the rate determined

in the test

Keep bandwidth utilization limited to that the network can

withstand

Time estimate Run time: 6 hours to a 24 hours

Type of workload Use a workload similar to the one determined in the maximum

simultaneous users test for the specific environment. However use a

ramp function

Methodology 1. Validate the work load

2. Determine the maximum performance of ADempiere

by the maximum simultaneous users for the specific

environment

3. Configure WebLOAD to use the ramp function

4. Configure WebLOAD to ramp up to the desired

amount of users and hold for 6 hours

5. Run the test

6. At the beginning of the test ensure no unexpected

errors occur

7. During the test periodically check the health of the

environment, including memory, CPU utilisation,

garbage collection, page time, hit time using the

WebLOAD reporter. Ensure traffic continues to flow

and that errors are not growing exponentially

8. Keep the test until the system fails

9. Analyse the results to determine whether the

performance and behaviour fits within the acceptable

constraints.

Problems

Encountered

Timeouts may occur due to the duration of the test and the large

number of open connections. Monitor the memory utilization with

the java garbage collector, while under steady loads memory leaks

may occur which will lead to system failure. Table 11 – Long Term Stability Test



of 86

4.6 Why WebLOAD?

WebLOAD is a commercial grade load testing and benchmarking software application. It

is flexible and requires little knowledge about performance, load generation, monitoring,

or programming. WebLOAD is a cost effective solution for SME, as it is freely available

while many performance tools available on the market requires substantial amount of

financial commitment.

WebLOAD provides two options; bundled into one Open Source application, a load

generation tool and a performance testing tool. (Witkon, E, 2007) WebLOAD’s load

generation tool invested in more protocol support to generate load to rich application

frameworks. It is a very suitable tool to benchmark ADempiere. (RadView, 2007).

WebLOAD’s performance testing tool invests in more measurements and better

correlating measurements on client and server using network status monitors, such as

Remote Procedure Call (RPC) protocol. It also allows the user to customise the

collaboration framework for analysis performance data in a shared environment, to

integrate different teams, or even to enrich the Open Source community, for testers to

collaborate world wide. It allows for collaboration between users at different locations.

(Witkon, E, 2007)

During testing, WebLOAD generates traffic that focuses on a particular metric,

dependant on the measurement. Since it has a wide variety of loading factors available, it

will ensure that ADempiere is assessed and tested in a properly, which ensures the test

produces results that are relevant to ADempiere.

WebLOAD provides an Authoring Environment (figure 7) similar to other test tools

which allows automatic Java Script generation through proxy recording. (Witkon, E,

2007) It simply records the user’s requests into a script.



of 86

Figure 7 – Authoring Environment

WebLOAD also allows you to define load testing scenarios, to execute the test and record

the results for further analysis. Results can be viewed in real time to diagnose (using the

performance measurements data) any errors with ADempiere.

The Load Generator is used to simulate a desired amount of virtual users concurrently,

primarily limited by the hardware of the load machine. It allows you to enter a mix of

tests to be run on ADempiere. This is shown in figure 8. For example, with WebLOAD

the Load generator has the capability of setting the mix of transactions to allow the

execution environment to rationalise the test into 15% simple users, 25% complex users

and 60% moderate users.

Figure 8 – Execution Environment



of 86

4.6.1 Constraints & limitations

WebLOAD provided a very structural approach to testing. However the major draw back

is its inability of using a fat-client, or JNDI requests to simulate testing. WebLOAD is

only really useable for web based applications.

The second disadvantage is the reporting functionality in WebLOAD. Although

WebLOAD provided an integrated report functionality and data drilling, the main

interface and presentation of these reports were quiet poor and required more processing

by the tester. The core of WebLOAD’s test suite only supports a Windows Environment;

however the load generator is multi-platform. (Petitbois, A., 2007)

Lastly, WebLOAD’s Performance Measurements Manager (PMM), although very useful

has one major drawback. The PMM protocol, RPC, does not allow for java profiling of

system resources. To overcome this issue, the java based garbage collection tool along

side with a virtualisation memory statistics tool was used, which is outlined in section

3.2.



of 86

5 IBM Work Load Estimator & Recommendations on

System i

The IBM Workload Estimator was used in this project as a sizing tool for the IBM

System i. The IBM Workload Estimator was used to develop a sizing guide. The

Workload Estimator allows delivery of a flexible, precise and customized hardware

recommendation for the client. The Sizing Model allows the client to know the hardware

requirements needed as soon as their user capacity is known.

Once performance data was gathered and more importantly verified, the Workload

Estimator allows input of this data to reflect the current load of the system. Using data the

Workload Estimator provides workloads to reflect emerging application requirements.

(IBM Systems, 2007) The main function of the Workload Estimator is to present a simple

user interface with a list of questions, for the user to determine the characteristics of their

system. (IBM Corp, 2007) For example, the Estimator may ask how many concurrent

users shall the system support, the Estimator may also ask the database size of the

system.

Using the user data (answers) provided the Workload Estimator provides current and

future growth recommendations for the hardware characteristics of the system, which

satisfy the client’s performance requirements. (IBM Systems, 2007) These

characteristics are derived from the performance tests undertaken in this project (section

8.2).

5.1 Constraints and Limitations

The IBM Work Load estimator naturally pads and provides contingency for the client’s

recommendations. The Workload estimator will always ensure that the recommended

usage does not exceed 60%. If the recommended usage of the system exceeds 60%, the

Workload Estimator will automatically provide a system with increased performance

requirements.



of 86

5.2 Relative Performance Analysis

The main characteristic used for this recommendation is an IBM benchmarking metric

named Relative Performance (rPerf). This metric is used for the IBM Power Platform.

The rPerf metric is derived from an IBM analytic model which uses features from

internal workloads and benchmarks. The rPerf metric is a combination of several

different factors of a totals system commercial performance, such as CPU, cache and

memory. However, rPerf does not simulate disk or network operations. (IBM Systems,

Hardware, 2007) The metric is used within the IBM Workload estimator to derive and

recommend a commercial system for the client’s specification. Because of this

commercial aspect, the rPerf is scaled and padded to best suit today’s market.

Using “IBM Performance Report” an rPerf value can be obtained for the required

processor. In this case, the rPerf is equal to 22.26, for the “System 5-550” (IBM System

p, 2007). This rPerf metric can be further scaled for the IBM Workload estimator to

derive the rPerf per transaction, dividing the rPerf (22.26) by the amount of users

achieves this goal.

Therefore,

rrentUsersTotalConcu

rPerfnTransactiorPerf =/ - Equation (1)

Performance data was recorded during each test, using a specific testing mix which

replicated ‘real world’ usage as close as possible. While still producing a high load on the

IBM System i 550. The following table describes the transaction complexity:

Transaction Description

Simple Low impact on system, user logging into

ADempiere and logging off

Moderate Medium impact on system, user

performances an enquiry (checking an

accounting period)



of 86

Transaction Description

Complex High impact on system, user logging into

ADempiere and making a purchase order or

sale

Table 12 – Transaction Complexity

Test scripts, transactions and scenarios are shown in section 8.5. Figure 9 displays the

results from performance testing ADempiere. Figure 9 shows a break down of supported

users. The testing mix consists of 25% complex transactions, 15% simpler transactions

and 60% of moderate transactions. As section 5.2.1 recommends, each test case was

tested with 1 core – 2GB RAM, 2 Core – 4GB RAM, etc. Figure 10 displays the use of

Equation (1) on each testing scenario. Figure 10 also displays the method behind the

calculation of section 8.7, index 5.

Figure 9 – Initial Testing - IBM System i (Linux) - Supported Users



of 86

Figure 10 – Initial Testing – IBM System i (Linux) – rPerf

5.3 IBM Workload Estimator Validation

The following section will compare the performance results obtained from WebLOAD

and the estimations generated by the IBM Workload estimator to determine if the

derivations of the recommendations are valid.

Figure 10 displays each hardware specification and the rPerf per transaction. Various

scenarios were looked at, such as 2 Core 4GB and 4 Core 8GB. It is shown from the

graph the lowest hardware specification in relation to the rPerf per transaction is the 1

Core 2GB. This is in-fact the worst case scenario which was used within the Workload

Estimator.

Table 13 and 14 below show the variances between the two results. The results from the

estimator show the most efficient solution for the required amount of users. Note that the

utilisation is unable to reach 100% with the recommendations put forward by the

Estimator; this ensures the system has room for growth. The amount of memory available



of 86

for ADempiere on the immediate solution is on par, or slightly higher then the results

obtained from WebLOAD.

This also shows the benchmarks performed are valid. For a complex transaction, the

rPerf is also higher, shown in figure 10. Thus, shown in Table 14, for a complex scenario,

the immediate solution recommends a higher system type (i570). An extra core is

recommended should the system utilisation reach 60%.

WebLOAD Simple Moderate Complex Mix

Concurrent Users 600 400 200 450

System Type i550 i550 i550 i550

Cores 1 1 1 1

Memory (MB) 2,048 2,048 2,048 2,048

Utilisation 100% 100% 100% 100%

Table 13 – WebLOAD Test Results –Validations

Immediate

Solution

Simple Moderate Complex Mix

Concurrent Users 600 400 200 450

System Type i515 i515 i570 i515

Cores 2 2 2 2

Memory (MB) 4,398 3,470 2,178 3,702

Utilisation 32% 48% 55% 58%

Table 14 – Workload Estimator – Validations



of 86

5.4 ADempiere Workload Estimator

As discussed in section 5, the workload estimator provides recommendation based on the

data (answers) provided by the end user. However, the estimation is also based on the

information (questions) and data gathered from the developer, which is used to derive the

rPerf as shown in section 5.2. Figure 11 provides an overview of the sizing model

development process.

Figure 11 – ADempiere Sizing Process



of 86

Once the ADempiere environment has been implemented, it is important to tune and

optimise ADempiere. Once optimisation is complete, the testing methodology outlined in

this document must be followed to performance test ADempiere. Furthermore, to develop

the sizing model for the Estimator, the rPerf must be developed by analysing the results

of the performance test. Using section 5.2 and the attributes in section 8.7 to develop

questions, an adequate sizing model can be developed, to finally estimate a

recommendation and growth. Figure 12 provides a break down of this process.

Figure 12 – ADempiere Sizing Process Breakdown



of 86

5.4.1 Sizing Model Walkthrough

The following section provides a walk through on how to use the Estimator for ADempiere. Once the Estimator is executed, you

will be presented with the following screen.

Figure 13 – Sizing Model Walkthrough – Data Entry



of 86

Figure 14 – Sizing Model Walkthrough – Recommendation

Capstone Project Proposal Leroy Pinto –

10039345

Sizing Model for the ADempiere Application

of 86

6 Future Directions

The work undertaken in this Capstone project has shown that ADempiere implemented

under the IBM Power Platform can be used as a powerful business tool to enable SMEs

achieving ERP capability. Further more, the developments outlined in this document

allows the community to use as a platform for further testing, and with better parameters.

The document also allows a more standardised approach to testing, which will promote

more confidence in the ADempiere application to encourage future development. This

standardised approach to test testing and sizing will also promote a more robust

application that can be used as rollout sizing strategy with the IBM Power Platform.

To promote the future growth of ADempiere, the community should explore options to

porting ADempiere to different application servers, to suit various SMEs, which may

prefer the likes of IBM’s Web Sphere or BEA’s Web Logic. Database ports to support

MySQL and IBM’s DB2 will also promote this growth, once this is undertaken, this same

testing methodology can be used to test ADempiere – to compare various estimations to

each environment. This will help increase the efficiency and performance of ADempiere,

and also to communicate the effort of ADempiere to the wider ERP community.

Due to resource constraints on the IBM Power Platform’s availabilities, long term

stability testing was excluded from the results. However, even though this was

overlooked, there must be testing in this area to ensure ADempiere is recognised as a

commercial grade, production based – ERP software solution. This will be achieved

through collaboration of various high end technology firms, such as IBM and Sun

Microsystems.

This Capstone project has demonstrated a successful first implementation of ADempiere

on the IBM Power Platform. This will pave the way for a more reliable, customisable and

complete system. From the support of IBM, and the ADempiere community, the IBM

System i was successfully able to support close to 2150 of simple transactions.


10039345


of 86

7 References

• Microsoft Dynamics, 2007 – “Microsoft Dynamics CRM, Suggest Hardware for

Deployments up to 250 Concurrent Users”, White Paper, Microsoft Corporation, January

2007

• Brislen, P., Krishnakumar, R., 2007, - ”What is ERP?”, viewed 04/09/2007

<http://searchsap.techtarget.com/sDefinition/0,,sid21_gci213946,00.html>

• Joung, P. 2003 “General Network Performance Testing Methodology”, Spirent

Communications, July 2003

• Halnes, S, 2005, - “Performance Testing Methodology”, White Paper, Quest

Software, October 2005.

• Witkon, E, 2007, - “The need for a testing framework”. RadView – WebLOAD,

viewed 12/10/2007, <http://webload.org/blog/?p=7>

• RadView, 2007 –“About WebLoad”, viewed 22/10/2007

<http://www.webload.org/the-webload-project.html>

• Mangia, L., Paiano, R., 2003 – “IEEEMMWA: a Software Sizing Model for Web

Applications”, Proceedings of the Fourth International Conference on Web Information

Systems Engineering (WISE03) 0-7695-1999-7/03 © 2003

• Nelly Condori-Fernández, Silvia Abrahão, 2001“Oscar Pastor – Towards a

Functional Size Measure for Object-Oriented Systems from Requirements

Specifications”, 2001

• Bilanych, J., Sykes H., 2007 “Drive Solution sales with IBM Sizing Guides”,

2007, viewed 30/10/2007 <

http://www.developer.ibm.com/servers/sizing/i/IBM_SizingGuide.pdf>

• Infosys Technologies, - “Enterprise Resource Planning”, -

http://www.infosys.com/services/packaged-

applications/enterprise_resource_planning.asp, 2007 [Accessed 01/08/07]

• ADempiere – “What is ADempiere?” , -

http://www.adempiere.com/index.php?option=com_content&task=view&id=10&Itemid=

25, 2007 [Accessed 01/08/07]


10039345


of 86

• Martin Carangelo, Luanne Carlton, Youngsil Rim, Techline IBM –

“Understanding the Sizing Process”http://www-

03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1672, 05/16/2007

• Microsoft Dynamics, “Hardware Sizing for 250 Users with Microsoft CRM”,

Microsoft, October 2006

• Singh, I., et al., 2002, “Designing Enterprise Applications with J2EE Platform”,

Second Edition, Adison Wiley, Boston, viewed 06/09/2007,

<http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/

• Gould, S., 2005, - “Developing n-tier applications using J2EE An introduction to

the Java 2 Platform, enterprise Edition specification”, Javaworld.com, viewed

05/09/2007,<http://www.javaworld.com/javaworld/jw-12-2000/jw-1201-weblogic.html>

• Veit, Daniel J. et al, 2007, - “Enterprise, applications and services in the finance

industry”, Information Systems & e-Business Management; Mar2007, Vol. 5 Issue 2,

p139-141, 3p.

• Madduri H, et al., 2007 – “A configuration management database architecture in

support of IBM Service Management”, IBM Systems Journal; 2007, Vol. 46 Issue

3,viewed10/09/2007,< http://www.research.ibm.com/journal/sj/463/madduri.pdf>

• Chawla, S. 2003 – “Fine-tuning Java garbage collection performance”, IBM

Systems Journal; 2003, viewed 10/10/2007,

http://www.ibm.com/developerworks/ibm/library/i-gctroub/

• Oliver, A. 2006 – “Java Performance Tuning on Linux Servers”, Redhat, 2006,

viewed 15/09/2007,https://rhstack.108.redhat.com/articles/2006/09/18/java-performance-

tuning-on-linux-with-andrew-oliver.html

• Petitbois, A., 2007 – “Stress Test Tools – WebLOAD 8.1”, 2007, viewed

16/10/2007, <http://digg.com/software/WebLOAD_8_1_Quick_overview>

• IBM Systems, 2007 – “IBM Systems Support: IBM Systems Workload

Estimator”, viewed 24/10/2007 <http://www-

304.ibm.com/jct01004c/systems/support/tools/estimator/index.html>

• IBM Corp, 2007 – “IBM Systems Workload Estimator Developer’s User

Guide”, IBM Systems, viewed 28/10/2007 < http://www-

912.ibm.com/wle/HTML/en/Tutorial/developerUserGuide.pdf>


10039345


of 86

• IBM Systems, Hardware, 2007,“rPerf – The relative performance metric for

System p servers”, viewed 25/10/2007 <http://www-

03.ibm.com/systems/p/hardware/rperf.html>

• IBM System p, 2007 – “IBM System p, BladeCenter Performance Report”,

viewed 18/10/2007

<ftp://ftp.software.ibm.com/common/ssi/rep_sp/n/PSO03002USEN/PSO03002USEN.PD

F>

• Millson, M. 2007, - “JBossASTuningSliming”, RedHat, viewed 20/10/2007,

<http://www.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming>

8 Appendices

8.1 JBoss Application Server Performance Optimisation

During testing, it is very important to tune the JBoss application server where ADempiere

is deployed. This is the core to where most performance issues arise. The following steps

will outline what areas should be tuned in JBoss. The following guide has been adapted

from the JBoss Application Server Tuning guide. (Millson, M, 2007)

1. Ensure unused web applications are un-deployed and removed. By default JBoss

includes a few applications. Delete the jmx-console with the following:

� cd $JBOSS_HOME/server/default/deploy

� rm –rf jmx-console.war snmp-adaptor.sar management

2. In section 3.1.2.2 we mentioned Tomcat Coyote is the default web container for JBoss.

Coyote by default listens on port 8080 for HTTP requests and 8009 for Apache Jserv

Protocol (AJP) requests. With the ADempiere environment we have Apache which

forwards HTTP requests to the JBoss instance, Coyote therefore needs the connector

listening on 8009 so ‘mod_jk/mod_jk2’ in the Apache instance can talk to the Coyote

connector on JBoss.


10039345


of 86

� cd $JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/META-

INF

� vi jboss-server.xml

Since Apache is the front end web listener, therefore Coyote is not needed on port 8080.

� address=”${jboss.bind.address}” port=”8009″ minProcessors=”5″

maxProcessors=”75″ enableLookups=”true” redirectPort=”8443″

acceptCount=”10″ debug=”0″ connectionTimeout=”20000″

useURIValidationHack=”false”

protocolHandlerClassName=”org.apache.jk.server.JkCoyoteHandler”

/>

3. Logging takes up significant system resources; there are several places where

logging should be set to ERROR. However, in section 6.2 ensure all logging for

Java is turned on and set to INFO. This will be used to ensure the ADempiere

environment is working correctly. By default, JBoss logs both to console and

server.log and also uses INFO.

� Turn off HTTP access logging; since Apache is the front end listening,

it already has access logs enabled by setting the flag to ‘false’.

� cd $JBOSS_HOME/server/adempiere/deploy/jbossweb-

tomcat55.sar/META-INF

� vi jboss-service.xml

� cd $JBOSS_HOME/server/adempiere/conf/

� vi log4j.xml

� Change the following xml fragment:

<root>

<appender-ref ref=CONSOLE”/>

<appender-ref ref=”FILE”/>

</root>

To:

<root>

<appender-ref ref=”FILE”/>

</root>

� Search for ‘INFO’ and change all entries to ‘ERROR’ in located

within the ‘<priority value=’ tag.


10039345


of 86

� vi $JBOSS_HOME/server/adempiere/deploy/jbossweb-

tomcat55.sar/conf/web.xml

o Jsp.org.apache.jasper FIX THIS

4. Tomcat and JBoss needs to be tuned so there are enough threads to handle the

expected load.

� cd $JBOSS_HOME/server/adempiere/deploy/jbossweb-

tomcat55.sar/

� vi server.xml

� maxSpareThreads should be equal to just 5% more of your peak load.

maxSpareThreads is the maximum amount of unused requests that

are left for the thread pool after peak load.

� maxThreads should be 25% more of the maximum expected

concurrent hits. maxThreads is the maximum number amount of

simultaneous hits the system can handle.

� minSpareThreads should be set to a mount smaller then

maxThreads. minSpareThreads is the number of threads available

when ADempiere is first started.

<Connector port=”8080”

address=”${jboss.bind.address}”

maxThreads=”150” minSpareThreads=”25”

maxSpareThreads=”75”

enableLookups=”false” redirectPort=”8443”

acceptCount=”100”

connectionTimeout=”20000”

disableUploadTimeout=”true”/>

5. JBoss creates a new thread for every incoming RMI request. This is quiet

inefficient in ADempiere, since it is such a large solution for a business,


10039345


of 86

especially when run on the IBM Power Platform. It is dangerous to allow

unrestricted connections when a traffic surge occurs. Pooled invoker should be

used instead of ‘jrmp’.

� ‘cd $JBOSS_HOME/server/adempiere/conf/’

� ‘vi standardjboss.xml’

� Change the following entries:

<invoker-

mbean>jboss:service=invoker,type=jrmp</invoker-

mbean>

To:

<invoker-

mbean>jboss:service=invoker,type=pooled</invoker-

mbean>

nohup ./RUN_Server2.sh > adempiere.out &


10039345


of 86

8.2 Performance Testing Results

Section 4 defined the type of tests that would be undertaken; the following shows the

results from Section 4.3, Maximum simultaneous users test. The tests were undertaken on

the IBM System i 550. Before simultaneous testing was conducted on the IBM System i

550, a work load validation (Section 4.1) was used to verify the system, as well as to

determine the acceptance criteria in Section 4.3.

8.2.1 IBM System i 550 Work Load Validation

The following performance data was collected and recorded based on Section 4.1. The

work load validation is used primarily for two reasons:

• Validation of the environment – to ensure proper functionality

• Development of the acceptance criteria

The graph below (figure 14) shows 1 user was loaded onto the server for 10 minutes; the

user’s prime task was to make a sale, as this is the most complex transaction available out

of the testing mix chosen.

From Section 5.1, it is advised the logging level on the entire ADempiere application is

set to INFO to determine the environment is working correctly to ensure there are no

errors occurring during your work load validation. It is noticeable the hit time, connect

time and response time have a low latency, for this reason the acceptance criterion is

scaled by 20% based on the work load validation. This was done to take into account the

extra stress concurrent users load onto the server. The criterion was further developed by

continuous testing until a criterion was acceptable. Before conducting any further tests on

the ADempiere environment, this work load validation must be repeated to confirm a

valid environment.

Confirming the criteria set by the work load validation manually is a vital step, the most

efficient and sound way to do this is to manually perform a sale using a browser, during


10039345


of 86

your concurrent user load testing. This manual step should be done around the 20%

criterion and validated multiple times by continuous testing. Coupled with performing a

manual sale and using the logs to determine if your workload is valid is the most

important step before conducting any performance tests, and also to ensure the criteria

developed is to the utmost standard as humanly possible.

Figure 15 – 1 User, Hit time, Page Time, Response Time

8.3 IBM System i550

The following performance data was recorded during each test, using specific testing mix

which replicated real world usage as close as possible, while still producing a high load

on the IBM System i 550. The testing mix consisted of 25% complex users, 15% simpler

users and 60% of moderate users. Ensure the work load validation has been undertaken

before continuing with any further testing, this ensures the environment is correct, and

secondly it allows the first few users to improve the end users experience, as more data is

loaded into the system memory and the system is wormed-up. This ensures the response

time is accurate throughout the entire test. (Witkon, E, 2007)

The following section shows only the most important performance data which overall

affects the performance of ADempiere on the IBM System i 550. The test scripts and

scenarios are shown in Section 7.2.


10039345


of 86

8.3.1 2 Gigabytes RAM, 1 CORE

The following image shows the performance results on i550 with 2 gigabytes of ram

allocated and 1 core enabled. The red square outlines the acceptance area of the test case

in section 4.2. Anything beyond the red square is out of scope of the acceptance criteria.

This area is where the ADempiere application becomes unstable due to the amount of

extra load. Outside the acceptance region, the response time is very unpredictable, this is

because the amount of context switches is abrupt, and CPU Utilisation is at its peak. This

is shown in section 7.3.3. Notice the amount of context switches is higher then the other

systems with larger amount of cores, shown in figure 19.

This is because the threads are limited to one processor, this means when complex

operations are being executed the amount of thread switching is significantly larger under

the i550 with 1 Core, which also increases CPU utilisation significantly. The second most

limiting factor is the amount of memory available to the application per user. With every

more complex user, sightly more portion of memory is taken up in relation to a simple

user. ADempiere is heavily dependant on the memory utilisation of the system, once the

complexity of transactions or user load becomes too memory restrictive, the java heap

tends to start garbage collecting which causes a large slow down in the application.

Hence the limiting factor for this scenario is primarily the amount of cores and amount of

memory available. This occurs around the 450 virtual user load size.

Figure 16 – 1 Core, 2GB – Page time, Hit time, Round Time


10039345


of 86



allocated and 2 cores enabled. The red square outlines the acceptance area of the test case


This area is where the ADempiere application becomes unstable due to the amount of

extra load. The response time is very much more responsive and closer to the page time

of the site, the context switches are very stable. It is noticeable that the limiting factor is

not the amount of threads available to ADempiere, but the amount of ram available to

each user. The acceptable user load is limited to 1200 users.

Figure 17 – 2 Core, 4GB – Page time, Hit time, Round Time


10039345


of 86



allocated and 4 cores enabled. The red square outlines the acceptance area of the test case


It is very noticeable that the connect time of each virtual user is increasing as each user

logs onto the system; as a result it is causing the response time to act in an abrupt way.

The page time however is quiet acceptable for most of the life of the test, however the hit

time is what is unacceptable.

Figure 18 – 4 Cores, 8GB – Page time, Hit time, Round time


10039345


of 86

8.4 Other Performance Results


Figure 19 – 1 Core, 2GB – Hits, Pages, and Throughput

Figure 20 1 Core, 2GB – Context Switches (Thread switching), CPU Usage


10039345


of 86

Figure 21 – 1 Core, 2GB – Disk Operations


Figure 22 – 2 Cores, 4GB – CPU Usage


10039345


of 86

Figure 23 – 2 Cores, 4GB – Disk Operations


Figure 24 – 4 Cores, 8GB – Context Switches (Thread switching), CPU Usage


10039345


of 86

Figure 25 – 4 Cores, 8GB – Disk Operations


10039345


of 86

8.5 Test scenario

The following test scenarios were used in conjunction with test scripts and WebLOAD to

conduct stress testing using concurrent users on the ADempiere system. The test

scenarios were broken into four categories, first being simple test, second being a

moderate and a complex test and a mix of all three categories. A simple test defined a

user logging into ADempiere and then logging off. A moderate test defined a user

performing an enquiry into the ADempiere system, for this case, the user was checking

accounting periods. A complex test was a user making a sale/order. Finally, testing mix

was generated of 15% simple, 25% complex and 60% moderate.

8.5.1 Simple Test

Log into ADempiere with the following:

a) Connections Screen – First login Screen

a. User ID = GardenAdmin

b. Password = GardenAdmin

c. Language = English (AU)

d. Click green tick for OK

b) Default Screen – Second login Screen

a. Role = GardenWorld Admin

b. Client = GardenWorld

c. Organisation = HQ

d. Warehouse = HQ Warehouse

e. Click Green tick for OK

c) Once logged in, wait 2.5 seconds, then logout.


10039345


of 86

8.5.2 Moderate Test








e. Role = GardenWorld Admin

f. Client = GardenWorld

g. Organisation = HQ

h. Warehouse = HQ Warehouse

i. Click Green tick for OK

c) Once logged in, wait 5 seconds.

d) Select Performance Analysis/ Accounting Rules/ Calender year

e) Calender Tab

a. Ensure Calender is activated for GardenWorld

f) Year Tab

a. Select current calendar year we are in

b. Periods Tab, and select Create Periods

c. Select the Period tab and check period exists for the current year we are in

d. Click OK check mark

g) Period Tab

a. Select current period

b. Select the Open/Close all button

c. Click the OK check mark in the message box

d. Select a period Action of Open Period

h) Wait 2.5 seconds, and then log out.


10039345


of 86

8.5.3 Complex Test








e. Role = GardenWorld Admin

f. Client = GardenWorld

g. Organisation = HQ

h. Warehouse = HQ Warehouse

i. Click Green tick for OK

c) Once logged in, wait 5 seconds.

Select Quote to Invoice/Sales Orders/Sales Order

d) Order Tab

a. Click the New Record Button

b. Target Document Type = Standard Order

c. Select a Business Partner – C&W Construction

d. Click the OK button

e. Sales Order Form

f. Invoicing select – Price List = Standard

g. Click Save Icon

e) Select Order Line Tab

a. Select the icon in Product and the Product chooser opens

i. Select Oak Tree

ii. Click OK

b. Set quantity = 50

c. Click Save

f) Select the Order Lines


10039345


of 86

a. Select the spreadsheet button

b. Return to Order Tab

g) Select Complete Button

h) Select Document Action of Complete

i) Select the red button with white X near the Sales Order

j) Wait 2.5 seconds, and log out


10039345


of 86

8.6 Test Scripts based on test scenario

The following script was used for the simple test case. For further scripts or results please

feel free to contact me through email. (mailto:[email protected])

function InitAgenda()

{

InFile1 = CopyFile(“C:\\Documents and

Settings\\Administrator\\Desktop\\webload\\input.txt”)

Open(InFile1,WLRandom)

}

/***** WLIDE – JavaScript – ID:41 *****/

strGlobalInputFileLine = GetLine(InFile1, WLRandom)

user_name = strGlobalInputFileLine[1]

password =strGlobalInputFileLine[1]

InfoMessage(“LoginID: “+user_name+” Password: “+password+””)

//END WLIDE

Sleep(1844)

/***** WLIDE – URL : http://XXX.XX.XXX.XX:8080/adempiere/WLogin - ID:9

*****/

wlHttp.Header[“Accept”] = “image/gif, image/x-xbitmap,

image/jpeg, image/pjpeg, application/x-shockwave-flash,

application/xaml+xml, application/vnd.ms-xpsdocument,

application/x-ms-xbap, application/x-ms-application, \x2A/\x2A”

wlHttp.Header[“Referer”] =

“http://XXX.XX.XXX.XX:8080/adempiere/WLogin”

wlHttp.Header[“Accept-Language”] = “en-us”

wlHttp.Header[“Content-Type”] = “application/x-www-form-

urlencoded”

wlHttp.Header[“UA-CPU”] = “x86”

//wlHttp.Header[“Accept-Encoding”] = “gzip, deflate”

wlHttp.Header[“User-Agent”] = “Mozilla/4.0 (compatible; MSIE 7.0;

Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)”

wlHttp.Header[“Proxy-Connection”] = “Keep-Alive”

wlHttp.Header[“Content-Length”] = “70”

wlHttp.Header[“Host”] = “XXX.XX.XXX.XX:8080”

wlHttp.Header[“Pragma”] = “no-cache”

wlHttp.Header[“Cookie”] =

“JSESSIONID=3259673DC49E64601DEC248FB5CCD0D3”

wlHttp.ContentType = “application/x-www-form-urlencoded”

wlHttp.FormData[“User”] = user_name

wlHttp.FormData[“Password”] = password

wlHttp.FormData[“#AD_Language”] = “en_US”

wlHttp.FormData[“Submit”] = “&OK”

wlHttp.Post(“http://XXX.XX.XXX.XX:8080/adempiere/WLogin”)

InfoMessage(“LoginID: “+user_name+” Password: “+password+””)

// END WLIDE


10039345


of 86

8.7 IBM Work load Estimator Attributes

The following section describes the attributes used within the IBM Sizing Work Load

Estimator.

Index Component Purpose Attribute

0 Work load Solution The parent

component where

all child components

will be placed under

ADempiere Series I Work

Load Solution

1 Tier Describes the

system where the

solution will run

System i

2 IBM System Acts as a container

for the partition

component

System i

3 Partition Describes the

operation system the

solution will use

Linux PPC – SLES 10

No LPAR

4 Workload Acts as a container

for those

components which

deal directly with

calculations of

resource

requirements and

the end user

interface.

Name: System i

Application LINUX

Version: 1.0

O/S: Linux PPC – SLES

10

5 Calculations Determines the

requirements

required for a

recommended

solution, these

calculations are

based on the page

component.

Let %READ_OPS% = 55;

Let %WRITE_OPS% = 21;

Rem if this

horizontal Scaling

workload;

Let %QTYSYSTEMS% = 1;

Let %RPERF% = 0;

Let %COMPLEXITY% =

complexUser / 100;

Let %USERS% =

NumUsers *

%COMPLEXITY%;

Let %STORAGE% =

SizeofDB + 100;

Rem complexity

compiled with best

fit of users;

Let SimpleUserRPERF =

simpleUser * 0.0371;

Let ModerateUserRPERF

= moderateUser *


10039345


of 86

0.05565;

Let ComplexUserRPERF

= complexUser *

0.1113;

Let %RPERF% =

SimpleUserRPERF +

ModerateUserRPERF +

ComplexUserRPERF;

Rem working our RPERF

based on number of

users;

If NumUsers <= 200;

Let %MEM% =

2048;

Else;

If NumUsers >

200 AND NumUsers <=

600;

Let %MEM%

= 4.5 * NumUsers +

1500;

Let

%READ_OPS% = 55;

Let

%WRITE_OPS% = 21;

EndIf;

If NumUsers >

600 AND NumUsers <=

1000;

Let %MEM%

= 9 * NumUsers;

Let

%READ_OPS% = 55;

Let

%WRITE_OPS% = 21;

EndIf;

If NumUsers >

1000 AND NumUsers <=

2500;

Let %MEM%

= 5 * NumUsers;

Let

%READ_OPS% = 123;

Let

%WRITE_OPS% = 58;

EndIf;

EndIf;

6 System Criteria –

Advanced

This section is used

to influence the

estimator. The code

is primarily used to

force the system to

use only 1 core

when the amount of

users is less then

Rem Be sure to use

Reject or Accept

statements;

If NumUsers < 450 AND

%SYS_NWAY% > 1;

Reject;

EndIf;


10039345


of 86

450.

7 Page Component The container where

the questions that

the end user will

answer are defined.

Page Name: ADempiere

Work Load Estimator

System i

Page Number: 0

8 Questions The questions are

added to the page

where the end user

will answer in the

order they appear in

the component tree.

9 Attention Box: A component which

provides a comment

within the page for

end user information

Component Name:

NonIBM

Warning Title: Note

Text: This Sizing Model

includes JBoss and

PostgreSQL by default.

10 Integer Question: A component which

provides a user to

input a whole

number. In this case,

the input is the

number of expected

users that the end

user wishes to use

for ADempiere, on

the System i series.

Question name:

NumUsers

Pre-Link Text: Please

indicate the maximum

number of concurrent

users on your application

Specific:

Initial Value: 1

Units: Users

Minimum value: 1

Maximum Value: 2500

11 IntegerQuestion: A component which

provides a user to

input a whole

number. In this case,

the input is the

number of expected

gigabytes the

database will use on

the system I series.

Question Name:

SizeofDB

Pre-Link Text:

What is the size of your

application database

Specific:

Initial Value: 1

Units: GB

Minimum value: 1

Maximum Value: 100

12 Attention Box: A component which

provides a comment

within the page for

end user information

Component Name:

AtnComplexity

Warning Title: Attention:

Text: The complexity of

users is based on

performance data

retrieved. The most


10039345


of 86

complex transaction sized

in this model is a Sales

Order; anything more

complex is beyond scope.

For more information

please see the ADempiere

Sizing Model.

13 Slider Question: This component

contains numerical

values with in it.

The end user can

graphically use the

slider to select a mix

of criteria. In this

component, the end

user will choose a

mix of user

complexity, ranging

from simple to

complex.

Question Name:

ComplexityOfUsers

Pre-Link Text:

Choose the

Linked Text:

complexity

Post-Link Text:

of the transactions

Flyout Text:

Complexity of concurrent

users

Specific:

Minimum Value:

0

Maximum Value:

100

Increment Value:

1

Zones:

ID: simpleUser

Label: simple

Initial Value: 15.0

ID: moderateUser

Label: moderate

Initial Value: 60.0

ID: complexUser

Label: complex

Initial Value: 25.0

14 Raid Question: Specific:

Initial Value: None

15 Growth Factor: Question Name:

%GROWTHFACTOR%

Post-Link Text:

For this workload


10039345


of 86

8.8 Implementation Plan

If you’re looking to install ADempiere on The IBM System i or p Series of machines on

SLES, the guide below will take you through the required steps and any problems

encountered.

8.8.1 Pre-implementation Tasks

� “IBM-JAVA2-PPC64-SDK-5.0”. Download the required IBM Java, for PPC. (ibm-

java2-ppc64-sdk-5.0-5.1.ppc64.rpm) you will have to sign up, but it’s free.

� “GCJ” (GCC) 4.1.0 SUSE LINUX

� “PostgreSQL” (version I used: 8.2.3)

� “PLJava” (version I used: 1.3.1). I’d strongly recommend getting the source from

CVS.

8.8.1.1 Java Installation

The most compatible Java version with the Power Platform is IBM Java, once

downloaded run the rpm with the following:

1. “rpm –Uvh ibm-java2-ppc64-sdk-5.0-5.1.ppc64.rpm”

The destination directory shall be something similar to the following:

2. “/usr/local/bin/java2-ppc64-50”

Create a symbolic link:

3. “ln –s /usr/local/bin/java2-ppc64-50/bin/java /usr/bin/java”

Ensure the symbolic link has been created with a directory listing:

“p570p5:/opt/temp # ls –las /usr/bin/java 0 lrwxrwxrwx 1 root root 38

Aug 28 16:27 /usr/bin/java -> /usr/local/bin/java2-ppc64-50/bin/java”

Create a bash profile if not already done:


10039345


of 86

4. “vi .bashrc”

And set your JAVA_HOME:

5. “export JAVA_HOME=/usr/local/bin/java2-ppc64-50”

Save the file and execute:

6. “. .bashrc”

Check your JAVA_HOME by executing the following:

7. “java –version”

8.8.1.2 PostgreSQL Installation

Install Postgresql8.1.x rpm offered by SLES using YaST>Software>Software

Management:

Using the command ‘yast2’ and ensuring you have an x-session available and your

display has been set to your required terminal, e.g “export

DISPLAY=192.128.162.253” being your computer.

The following packages are required:

� Postgresql-server

� Postgresql-dlevel

� Postgreslibs-64bit

� Postgresqllibs

� Postgresql-jdbc

You will now need to start PostgreSQL:

1. “/etc/init.d/postgresql start”

You will then need to set the system password for your postgres user and then login (add

the user if not done so already):

2. “passwd postgres”

3. “su – postgres”


10039345


of 86

Next you will need to create a database user for PostgreSQL, there are two methods, first

being external to PSQL:

You will need to setup the user as a super user, select ‘y’ to assign role to super user.

4. “createuser adempiere”

Second method:

1. “psql”

2. create user adempiere with password

‘adempiere’;

3. alter user adempiere with superuser;

4. alter user adempiere with login;

5. \q

You can now create the database, there are two ways, one being the following (this

creates a database external to PSQL):

5. createdb adempiere –E UTF8 –O adempiere –U adempiere

Second method:

1. “psql”

2. create database adempiere with owner=adempiere

encoding=’UTF8’;

3. \q


10039345


of 86

8.8.1.3 PL/Java

You will need to download the source to install PL/JAVA before doing this, ensure

JAVA_HOME is set, and Java is installed. Also ensure GCJ has been successfully

installed.

Available from:

8.2.1.1 http://pgfoundry.org/frs/?group_id=1000038

8.2.1.2 “cd /opt”

8.2.1.3 “tar zxfv pljava-1.3.0.tar.gz”

In /opt/

8.2.1.4 “cd /opt/pljava-1.3.0”

8.2.1.5 The following steps will compile pljava and build the required

object files and jar files. Secondly we will be then copying the files

with the required permissions to the /usr/share/pljava

directory. If you prefer you can do this step manually by creating

the directory and manually copying over ‘pljava.jar

deploy.jar and pljava.so’ and setting the required

permissions with chmod. You will then need to create a

postgres.conf file in /etc/ld.so.conf.d/postgres.conf and

add the directories listed below:

� make USE_GCJ=1

� mkdir –p /usr/share/pljava

� install –m 644 build/pljava.jar /usr/share/pljava

� install –m 644 build/deploy.jar /usr/share/pljava

� install –m 755 build/objs/pljava.so /usr/share/pljava

� cat > /etc/ld.so.conf.d/postgresql.conf <<EOF

� $JAVA_HOME/jre/lib/ppc64


10039345


of 86

� $JAVA_HOME/jre/bin/classic

� $JAVA_HOME/jre/lib

� $JAVA_HOME/jre/bin

� EOF

Rebuild the library list with:

8.2.1.6 “ldconfig”

Ensure your ‘libjvm.so’ has been set with the following:

8.2.1.7 “/sbin/ldconfig –p |grep libjvm.so”

Modify postgresql.conf in /var/lib/pgsql/data (remember to uncomment #the

lines):

Add these lines:

8.2.1.8 custom_variable_classes = ‘pljava’

8.2.1.9 pljava.classpath =

‘/usr/share/pljava/pljava.jar’

Modify the following:

8.2.1.10 listen_addresses = ‘*’ # if you want to log in from

the internet

8.2.1.11 port = 5432

Change:

dynamic_library_path = ‘$libdir’

To:

8.2.1.12 dynamic_library_path =

‘$libdir:/usr/share/pljava’


10039345


of 86

8.2.1.13 Modify pg_hba.conf in /var/lib/pgsql/data:

Please note in a production environment change the method to ‘md5’, my case has been

listed below:

#TYPE DATABASE USER CIDR-ADDRESS METHOD

#local is for Unix domain socket connections only

local all all trust

# Ipv4 local connections:

host all all 127.0.0.1/32 trust

host all all 127.0.0.2/32 trust

# Ipv6 local connections:

host all all ::1/128 trust

host adempiere adempiere 0.0.0.0/0 trust

Then install pljava into Database by running:

8.2.1.14 java –cp

/usr/share/pljava/deploy.jar:/usr/share/pgsql/postgre

sql-8.1-404.jdbc3.jar

org.postgresql.pljava.deploy.Deployer –install –user

adempiere –database adempiere –password adempiere


10039345


of 86

8.8.2 ADempiere Installation

Download ADempiere_320.tar.gz, extract the file to /opt, then go to

/opt/ADempiere, run RUN_setup.sh by running:

1. “chmod –R 755 *.sh”

2. “./RUN_setup.sh”

Modify the configuration and press ‘Test’, if okay then press ‘Save’. Please note that

in Database Server>System Password, this should be the password for PostgreSQL.

And Database Password should be ‘adempiere’.

Next step is to import the sample data into the application database.

3. “cd /opt/ADempiere/utils”

4. “./RUN_ImportADempiere.sh” to import data into Database.


10039345


of 86

8.8.3 Trouble Shooting

8.8.3.1 Error Database Port

If you get “Error Database Port (DB Server Port = 5432)”, change the

‘Database Server’ from hostname to localhost.

8.8.3.2 Error IbmX509 Key Store

This error is a result of tomcat being defaulted to the sun key store factory. The main

thing is to add ‘algorithm=”IbmX509’ to the Factory element.

You will need to find the ‘server.xml’ located usually in:

“ADempiere/jboss/server/adempiere/deploy/jbossweb-

tomcat55.sar/server.xml”

Open with your favourite text editor:

“vi server.xml”

Find the “<Connector port=”8443” ” line and at the bottom add

“algorithm=”IbmX509” /> “

Similar to below:

<Connector port=”8443” address=”${jboss.bind.address}”

maxThreads=”100” strategy=”ms” maxHttpHeaderSize=”8192”

emptySessionPath=”true”

scheme=”https” secure=”true” clientAuth=”false”

keystoreFile=”/opt/ADempiere/keystore/myKeystore”

keystorePass=”myPassword”

sslProtocol = “TLS”

algorithm=”IbmX509” />


10039345


of 86

8.8.3.3 Error JDBC

If you receive the following error, you will notice the host is trying to connect to the

address 127.0.0.2, ensure you have enabled this connection in pg_hba.conf.

=========� Config.testJDBC: org.postgresql.util.PSQLException: FATAL:

no pg_hba.conf entry for host “127.0.0.2”, user “postgres”, database

“template1”, SSL off [27]

=========� Config.testJDBC: org.postgresql.util.PSQLException: FATAL:

no pg_hba.conf entry for host “127.0.0.2”, user “postgres”, database

“template1”, SSL off [27]

---------� ConfigurationData.test: Error connecting:

jdbc:postgresql://p570p5:5432/template1 – postgres/postgres [27]

=========� ConfigurationPanel$1.finished: Error JDBC Connection

(Error connecting: jdbc:postgresql://p570p5:5432/template1 –

postgres/postgres) [12]

=========� ConfigurationPanel$1.finished: Error JDBC Connection

(Error connecting: jdbc:postgresql://p570p5:5432/template1 –

postgres/postgres)


10039345


of 86

9 Project Proposal The key sections have been extracted from the project proposal. This has been done to

mainly focus on project time line and to ensure risks have been accounted for.

9.1 Timeline

A timeline has been developed with rough estimates of deadlines for each milestone;

each milestone has been detailed in the development lifecycle. The 12 credit point project

will be completed in accordance with the UTS semester time frame. The following is a

time line estimating the deadlines for tasks involved in completing the capstone project.

Certain risks and constraints are associated with this proposal; if any changes are required

because of this, new due dates will be discussed with the supervisor.

9.1.1 High level time line

Figure 26 - High level Gantt Chart


10039345


of 86

9.1.2 Low level break down

Tasks Due dates Duration(days)

Start Project Proposal 29/07/2007 24

Draft Project Proposal Due 03/08/2007 5

Develop Prototype on VMWare 08/08/2007 8

Develop Performance Test

Scripts

20/09/2007 20

Secure Hardware Resource 24/08/2007 24

Submit final proposal and Blue

form and Appendix B signed by

supervisor to UPO – 4PM

24/08/2007 -

Implementation of ADempiere 02/09/2007 7

Run Performance Scripts on

Hardware

22/09/2007 23

Gather & Record Results 22/09/2007 31

Develop Documentation (Sizing

Model) from results

23/10/2007 30

Draft thesis review 15/11/2007 20

Submit final thesis report and

Gold assessment form and

Appendix B to UPO – 4pm

23/11/2007 -

Table 15 - Milestone Plan & Task breakdown

Capstone Project Proposal Leroy Pinto – 10039345


of 86

9.1.3 Low level Gantt Chart

Figure 27 - Low level Gantt Chart


10039345


of 86

9.2 Risk Assessment

The following risks have been identified as potential problems that could effect the

completion of the project on time and to an acceptable quality. All the risks have been

assessed and determined as to which stage in the life cycle of the project they will occur.

Each risk has also been assessed for both their likelihood of occurrence and also for the

impact of its occurrence. (Gray C.F., Larson E.W, 2006)

These results are listed below in Table 8-1, and have been plotted on a risk severity

matrix in Table 8-2.

Risk

No. Description of Risk

Stage of

project life

cycle

Likelihood

of

occurrence

(1-5)

Impact

of

occurrence

(1-5)

1 Project does not finish on time Delivering 2 5

2 Objectives of project not met Executing 1 5

3 Changes in scope Executing 2 3

4

The supervisor unavailable for

consultation Planning 3 3

5

Serious illness or psychological

condition Delivering 2 5

6 Required resources unavailable All 3 5

7

Hardware/Software problems (java

profiling software incompatible with

IBM Power Platform & IBM Java) All 2 5

8 Insufficient technical skills/knowledge All 2 3

9

Scope of assignment wrong - not

addressing the problem in the way it

was intended to be addressed Defining 2 4

10

Concentrating too much on one section

of the project

Planning /

Executing 4 3

11 Poor time management

Planning /

Executing 3 3

12

Inaccuracies in report regarding

incorrect grammar, poor formatting etc. Executing 2 3 Table 16 - Risk Analysis


10039345


of 86

9.2.1 Risk Severity Matrix

L

ikel

ihoo

d

5

4

10

7

3

4,11

6

2

3,12,8

9

1,5

1

2

1 2 3 4 5

Impact Table 17 Severity Risk Table


10039345


of 86

9.2.2 Risk Response

As a response to the risks listed above, we have a number of different options. Shown in

the table below is a list of our responses on how we are going to manage these risks. We

must ensure that we address all the risks that have a rating inside the grey area on the

Risk Severity Matrix, i.e. 2, 3, 4, 6, 9. (Gray C.F., Larson E.W, 2006)

Risk No. Risk Response Actions to be taken

1 Mitigate - Ensure project runs on schedule

2 Mitigate

- Ensure project runs within the scope of

the project

3 Accept/Mitigate

- Accept the changes in scope and plan

for these changes.

- Ensure scope is clear at the very

beginning of the project

4 Accept/Mitigate

- Unforseen circumstances, will accept

the risk

- Mitigate the risk by planning regular

meetings in advance

5 Accept

- Unforseen circumstance – accept the

risk

6 Retain

- Use VMware to simulate a typical

small business environment of 40 users

- Ensure supervisor knows if resources

are unavailable.

7 Retain.

- Same as above, Risk No 6. Accept risk

and find alternative software

8 Retain.

- Ensure research is adequate to cover

holes in knowledge/skills

9 Mitigate

- Ensure the project is being continually

monitored

- Refer back to original requirements of

assignment regularly.

- Have regular meetings with supervisor

10 Mitigate

- Ensure project follows plan and project

goal

11 Retain

- Ensure tasks are broken down into

manageable pieces to be scheduled for

in a timely manner

12 Mitigate

- Ensure proof reading of all work

submitted. Table 18 - Risk Response Table


10039345


of 86

10 Document Control

10.2 Version Control

Version Date Section Nature of Amendment Amendment Author

0.1 04/09/07 ALL Document Structure Leroy Pinto

0.2 05/09/07 Document Structure Document Structure Leroy Pinto

0.3 05/09/07 Implementation Plan Addition Leroy Pinto

0.4 10/09/07 Optimisation Addition Leroy Pinto

0.5 12/09/07 Intro, Document Purpose Addition Leroy Pinto

0.6 12/09/07 Added Intro, Document

Purpose

Edit Leroy Pinto

0.7 26/09/07 Added Environment

Overview

Edit Leroy Pinto

0.8 10/10/07 Added ADempiere

Architecture

Addition Leroy Pinto

0.9 15/10/07 Edited Environment

Overview, ADempiere

Architecture, Performance

Results

Edit, Addition Leroy Pinto

1.0 15/10/07 Added Testing

Methadology, Performance

Results, IBM Workload

Estimator

Edit, Addition Leroy Pinto


Methadology, Performance

Results, IBM Workload

Estimator,rPerf

Addition, Edit Leroy Pinto


Methadology, rPerf

Addition,Edit Leroy Pinto

1.3 23/10/07 Added Constraints, Why

WebLOAD, Performance

Results,Future Directions,

Validation


1.4 28/10/07 ALL Edit Internal Review

1.5 28/10/07 ALL Edit External Reviewer

1.6 29/10/07 ALL Edit Internal Review

1.7 30/10/07 ALL Edit External Reviewer

1.8 01/11/07 Introduction, Future

Directions


1.9 04/11/07 ALL Edit Leroy Pinto


2.1 20/11/07 ALL Review John Schilt

2.2 22/11/07 ALL Review Phuong Hoang


Table 19 - Version Control

END OF CAPSTONE THESIS REPORT

IBMSizingModel adempiere

Documents

Transcript of IBMSizingModel adempiere