Oracle JD Edwards EnterpriseOne Notifications …...AIS Server, Orchestrator and other Java-based...

Oracle JD Edwards EnterpriseOne 64-bit Performance Characterization Performance, Stability, and Reliability of JD Edwards EnterpriseOne 64-bit Processing WHITE PAPER December 17, 2018

ORACLE JD EDWARDS ENTERPRISEONE NOTIFICAITONS – PERFORMANCE CHARACTERIZATION

Disclaimer

The following is intended to outline our general product direction. It is intended for information

purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any

material, code, or functionality, and should not be relied upon in making purchasing decisions. The

development, release, and timing of any features or functionality described for Oracle’s products

remain at the sole discretion of Oracle.

1 | ORACLE JD EDWARDS ENTERPRISEONE NOTIFICATIONS – PERFORMANCE CHARACTERIZATION

Table of Contents Executive Summary ..................................................................................... 2

Introduction .................................................................................................. 4

What is a JD Edwards EnterpriseOne 64-bit processing? ........................... 4

Why should I upgrade to 64-bit processing? ................................................ 5

Test Configuration / Methodology ................................................................ 6

Interactive Results – Load Tests ................................................................. 8

Memory Profiles ......................................................................................... 10

Batch job results ........................................................................................ 13

Stability Test .............................................................................................. 16

Package Build ............................................................................................ 17

Conclusions ............................................................................................... 18

Appendix A: LOAD TEST CPU Profiles ..................................................... 19

Appendix B: Microsoft Windows + Oracle Database & Microsoft Windows + Microsoft SQL Server - UBE stats .......................................... 20

Appendix C: Test Configuration ................................................................. 23

Appendix D: Data collection scripts ........................................................... 27

2 | ORACLE JD EDWARDS ENTERPRISEONE 64-BIT – PERFORMANCE CHARACTERIZATION

Executive Summary

Oracle’s JD Edwards EnterpriseOne has supported vendor 64-bit hardware, operating systems, databases, Java, and middleware for many years. Additionally, multiple JD Edwards components, such as HTML Server, AIS Server, Orchestrator and other Java-based components, are 64-bit enabled. Now, to round out our architecture, JD Edwards will enable 64-bit processing for the Enterprise Server and development client. This empowers you to move completely from 32-bit to 64- bit processing. You might be asking yourself why you want to make that move. The answer is that you have quite a bit to gain. There are several reasons why you would want to move to 64-bit processing:

• Performance Improvements Interactive application response times and batch processing runtimes generally improved.

• Future Proof your JD Edwards EnterpriseOne Investment Moving to 64-bit enables you to adopt future technology and future-proof your environments. If you do not move to 64-bit, you incur the risk of facing hardware and software obsolescence. The move itself to 64-bit is the cost benefit.

• Third-party Components Many vendors of third-party components, such as database drivers and Java, which JD Edwards EnterpriseOne requires, are delivering only 64-bit components. They also have plans in the future to end or only provide limited support of 32-bit components.

• Future Innovation. Moving to 64-bit enables JD Edwards to deliver future product innovation and support newer versions of the required technology stack.

Transitioning to 64-bit processing is a technical uplift that is managed with the JD Edwards Tools Foundation. There is no impact to business processes or business data.

We completed a comprehensive performance, stability and reliability (PSR) test on JD Edwards EnterpriseOne for 64-bit processing. The PSR test was performed on four supported Platform and Database combinations:

Operating System Database Oracle Linux Oracle Database Microsoft Windows Microsoft SQL Server Microsoft Windows Oracle Database IBM i on Power Systems IBM DB2 Database

We tested a standard set of use cases on corresponding 32-bit and 64-bit tools releases with JD Edwards EnterpriseOne Applications 9.2. After completing our tests, we state the following conclusions:

• There is an overall improvement in total average interactive response time in the 64-bit version of EnterpriseOne.

• There is an overall improvement in UBE runtime in the 64-bit version of EnterpriseOne.

• There is an overall decrease in Enterprise Server CPU usage in the 64-bit version of EnterpriseOne.

• There is an overall decrease in average C Business Function (BSFN) response time in the 64-bit version of EnterpriseOne.


• There is an overall increase in Enterprise Server memory consumption when moving from 32-bit EnterpriseOne to the 64-bit version.

• The IBM I on Power Systems platform is not discernibly impacted by 64-bit EnterpriseOne processing because this operating system is natively 128-bit.

• Package builds run longer in an EnterpriseOne install which maintains both 32-bit and 64-bit Business Functions.


Introduction

Oracle JD Edwards EnterpriseOne is an integrated applications suite of comprehensive enterprise resource

planning (ERP) software that combines business value, standards-based technology, and deep industry experience

into a business solution. The JD Edwards solution architecture can exist on multiple platforms and on multiple

database architectures. This document describes performance characterization testing performed with 64-bit

processing for JD Edwards EnterpriseOne. The target audience of this document are individuals involved in the

design, planning, and implementation of EnterpriseOne

What is a JD Edwards EnterpriseOne 64-bit processing?

Prior to the JD Edwards Tools Release 9.2.3.x, JD Edwards EnterpriseOne product has been built to support a 32-bit ecosystem, which means its foundation code accesses memory with 32-bit addresses. This limits the total amount of memory accessible by a single process.

A 32-bit memory model means that a maximum of 2 32 bits (about 4GB of address space) can be accessed. This is reduced further by reserved operating system address space. For example, on Microsoft Windows only about 3.5 GB can be used by a process.

This was not a limiting problem when the product was first developed and implemented, but software usage has changed over the years, and JD Edwards’ customers are using increasingly larger datasets. Larger queries are being run within batch jobs and Enterprise Server Call Object Kernels, and the results are being stored and utilized within these processes. This has per-process memory requirements that can push the limits of the current 32-bit infrastructure.

Theoretically, a 64-bit memory model can address 264 bits (16.8 million terabytes) of memory. Most 64-bit processors and operating systems do not fully support memory addresses to this level. For example, Microsoft Windows Server 2012 Datacenter allows addressing of 4TB of memory. The 64-bit application memory model does allow for future adoption of exponentially larger memory models as operating system and CPU designs catch up.

Additionally, all the supported JD Edwards EnterpriseOne operating systems are natively 64-bit, meaning the current JD Edwards product runs in a 32-bit compatibility mode, adding overhead to CPU usage and runtimes. Running a 64-bit version of the JD Edwards code eliminates this overhead.

It is important to understand just which parts of the JD Edwards EnterpriseOne product are impacted by 64-bit processing. The simple answer is that the code running on the Enterprise Server has been upgraded:

• The Foundation or “Tools” component running on the Enterprise Server. This code is the technical “back end” part of the product and is written in C and C++. This code is stored in the system/bin32 directory in an EnterpriseOne installation. This becomes system/bin64 in the 64-bit processing.

• The C-coded Business Functions (which contains application business logic used by both interactive and batch applications) – also runs on the Enterprise Server. These are the libraries stored in the PATH_CODE/bin32 directory. This becomes PATH_CODE/bin64 in the 64-bit processing.

The HTML and Web server part of the JD Edwards EnterpriseOne product (Java Application Server or JAS server) are not impacted by the 64-bit processing. These consist primarily of Java and Javascript code. Other JD Edwards modules such as the Application Interface Services (AIS) and Application Development Framework (ADF) Java servers are not impacted.

Other components that are impacted by 64-bit processing include:

• Database Drivers


When Oracle is the Database Management System (DBMS) used on either the Oracle Linux or Microsoft Windows platforms, the database drivers must be upgraded to 64-bit versions not previously used by 32-bit releases of JD Edwards EnterpriseOne.

• Java Virtual Machine (JVM)

Used on the Enterprise Server must also be upgraded to a 64-bit version. Note that this is NOT the JVM used on the Java Application Server (JAS). Rather, this is the JVM loaded in-processes by kernel jobs which run on the Enterprise Server, such as the Metadata kernel.

• Development Client Machine

This Implementation of JD Edwards EnterpriseOne contains a full set of Business Functions as well as a client version of the foundation code. A 64-bit version of the JD Edwards EnterpriseOne development client will be available, but that is not addressed in this paper.

Why should I upgrade to 64-bit processing? The upgrade to 64-bit has numerous benefits and implications you should consider:

The software now runs natively in the 64-bit operating systems, eliminating the need for 32-bit compatibility overhead.

• The same JD Edwards EnterpriseOne applications will consume fewer CPU cycles in the 64-bit case.

• Shorter runtimes for batch applications and faster response times for interactive applications.

• Faster interactive response times and reduced batch runtimes are largely due to faster runtimes of C Business Functions which run most of the business logic.

• Larger per-process memory capacity means that larger datasets can be run by single UBE jobs or in single call-objects kernels. Fewer out-of-memory errors that process large datasets may result.

The memory footprint will increase with 64-bit due to padding and the increased size of the 64-bit pointers. Machines which run JD Edwards EnterpriseOne will have increased memory requirements. The increased factor may vary, but appears to be in the 15-20 percent range.

Package build runtimes will increase due to dual maintenance of 32-bit and 64-bit objects. This will cease once an install is migrated entirely to 64-bit.

On the IBM I on Power Systems platform JD Edwards 64-bit processing will not reflect the gains seen on Oracle Linux and Microsoft Windows. Following an upgrade to 64-bit, the runtimes and response times from the same applications will largely be at parity with the 32-bit product because the IBM I on Power Systems is natively 128-bit.

The IBM I on Power Systems platform is minimally impacted by 64-bit processing.


Test Configuration / Methodology The tests in this study involve running the same DIL kit use cases in both 64-bit and 32-bit configurations.

Both the 32-bit and 64-bit run against the same database on each platform, so neither the data or the tables change in the move from 32-bit to 64-bit. Only the tools release code is changed.

Respective JD Edwards 32-bit and 64-bit Enterprise Servers were installed and running on the same virtual machines in a multi-foundation architecture.

JD Edwards EnterpriseOne Applications Release 9.2 was identical for both 32-bit and 64-bit configurations:

• The metadata specifications were identical.

• The same C Business Functions were used. however, for 64-bit case they were run through the established conversion process which modifies the C code for 64-bit compatibility. (This is part of the 64-bit upgrade process). There were no functional differences in the code. The 64-bit changes were technical only.

The same use cases were tested on corresponding 32-bit and 64-bit tools releases with JD Edwards EnterpriseOne Applications 9.2.

The following tests were run on each of the platform / DBMS combinations:

• Unit test for each UBE.

• One-hour load test containing a mix of all 17 interactive DIL kit use cases for the following user levels:

» 100 users » 250 users » 500 users

• An 8-hour stability test containing a mix of all 17 interactive DIL kit use cases on Oracle Linux + Oracle Database only.

• The interactive use cases were implemented as scripts created from the Oracle Application Test Suite (OATS) and executed using the Oracle Load Testing (OLT) utility.

The mix of users of each JD Edwards EnterpriseOne interactive use case for the 100, 250, and 500 user scenarios was as follows. The iteration delay indicates the time between iterations for each use case:

JDE use case / application

100 Users 250 Users 500 Users Iteration Delay (secs)

Apply Receipts (P03B102) 10 30 60 180

Supplier Ledger Inquiry (P0411) 10 30 60 220

Daily Time Entry (P051141) 2 5 10 30

Case Management Add (P17500) 5 10 20 610

W.O. Completion (P31114) 3 7 14 250

MRP Msg - WO Orders (P3411A) 2 5 10 150

MRP Msg - OP Orders (P3411) 2 5 10 135

MRP Msg - OT Orders (P3411) 2 5 10 170

Inventory Transfer (P4113) 5 10 20 370

S.O. Entry - 10 line items (P42101) 25 60 120 90

S.O. Update (P42101) 5 10 20 270

P.O. Entry - 10 line items (P4310) 20 50 100 250


The following are the UBEs tested:

• Order Processing (R31410)

• MRP Master Planning Schedule - Multiple Plant (R3483)

• Invoice Print (R42565)

• Purchase Order Print (R43500)

• General Ledger Post (R09801)

• Print Pick Slips (R42520)

• Sales Update (R42800)

• Manufacturing Accounting Journal Entries (R31802)

For the 100, 250, and 500 user levels, the only change in hardware and software configuration is the number of Call Object Kernels on the Enterprise Server. The level of 10 users per kernel was used in each case.

For Microsoft Windows and Oracle Linux tests, virtual machines built from hypervisors were used. The total amount of RAM, CPUs, JVMs, and JVM heap sizes were all constant.

Hardware / Software Configuration for Interactive Tests

Parameter 100 Users 250 Users 500 Users

Enterprise Server RAM 16GB 16GB 16GB

Enterprise Server CPU 4 4 4

JAS RAM 16GB 16GB 16GB

JAS CPU 4 4 4

Database Server RAM 32GB 32GB 32GB

Database Server CPU 8 8 8

# Call Object Kernels 10 25 50

# Security Kernels 10 10 10

JAS JVMs 2 2 2

JAS JVM heap size per JVM 4GB 4GB 4GB

P.O. Receipts (P4312) 2 5 10 540

Voucher Match (P4314) 2 5 10 470

Ship Confirm - Approval only (P4915) 3 7 14 270

Ship Confirm - Confirm/Ship only (P4915) 1 3 6 220

Ship Confirm - Confirm and change entry (P4915) 1 3 6 240


Diagnostics

The following data was collected in these tests:

Interactive Use Cases

• Enterpriser Server CPU

Microsoft Windows – PerfMon utility

Oracle Linux -– top utility / Linux bash script

• Enterprise Server Memory

Microsoft Windows – PerfMon utility

Oracle Linux – top utility / Linux bash script – Proportional Set Size (PSS)

• Response Times

Collected from Oracle Load Test (OLT) Reports

• Business Function

Metrics collected from EnterpriseOne Server Manager

UBE

• Enterpriser Server CPU

o Microsoft Windows – PerfMon utility

o Oracle Linux -– top utility / Linux bash script

• Enterprise Server memory

o Microsoft Windows – PerfMon utility

o Oracle Linux – top utility / Linux bash script – Proportional Set Size (PSS)

• Runtimes

Interactive Results – Load Tests

Response Times

The average interactive response times in the 64-bit case was modestly improved from the 32-bit case, largely due to the more efficient runtimes of C Business Function logic.

The IBM I on Power Systems platform did not show consistent improvement in response time due to its 128-bit nature; the results showed largely parity with the 32-bit case.


The average runtime of C-language business functions was consistently improved in the 64-bit cases due to the increased efficiency of the 64-bit code running natively in the 64-bit operating systems:

Average Business Function Runtime Improvement (32-bit vs 64-bit) (Percent) Platform + Database 100 Users 250 Users 500 Users

Oracle Linux + Oracle Database 14.6 7.0 9.0

Microsoft Windows + Oracle Database 4.3 7.2 1.0

Microsoft Windows + Microsoft SQL Server 2.5 2.1 21

IBM I on Power Systems + IBM DB2 Database -0.2 4.8 -1.1

The IBM I on Power Systems platform did not show consistent improvement in Business Function runtime due to its 128-bit nature; there is no benefit of the low-level 64-bit nature of the code.

Drilling down into three individual representative use cases, the runtimes of the major Business Functions were measured and analyzed.

These three use cases were analyzed:

• P42101 - S.O. Entry (10 line items) • P31114 - W.O. Completion • P4113 - Inventory Transfer

The following Business Functions in each use case had runtimes measured and averaged:

S.O. Entry - 10 line items (P42101) W.O. Completion (P31114) Inventory Transfer (P4113) GetSalesOrderPOEX B3100770CompletionsEditDoc F4111GetNextNumber GetSalesRelatedProcessVersionsEX B3100770CompletionsEndDoc F4113FSBeginDoc S421001E_InitializeSOHeader CacheLicensePlateTransHeader F4113FSClearWorkFile S421001E_SOHeaderViewController F00095RemoveReservation F4113FSEditLine S421002C_InitializeSODetail F00095ReserveObject F4113FSEndDoc S421002C_SOLineViewController F4801TGetTagRecord MPMVerifyProjectSpecificItem S421007A_InitializeSOHeader GetItemLocationDetail S421007A_SOHeaderViewController VerifyAndGetItemLocation SalesOrderApplCtrlEX W42101B_InitOrderInquiryEX W42101D_ConfirmSalesOrder W42101D_CreateSalesOrder

Average Interactive Response Time Improvement (32-bit vs 64-bit) (Percent) Platform + Database 100 Users 250 Users 500 Users


Microsoft Windows + Oracle Database

3.6 6.8 4.3

Microsoft Windows + Microsoft SQL Server

5.4 2.0 12.3

IBM I on Power Systems + IBM DB2 Database

-4.2 1.3 0.2


W42101E_ConfirmHeaderRevisions

The results for the IBM I on Power Systems case are different because of 128-bit processing.

Memory Profiles The most notable result of the interactive testing is that the Oracle Linux and Microsoft Windows scenarios showed an expected increase in steady state memory usage.

The memory increase is expected due to the increased padding the 64-bit compatibility brings to critical JD Edwards EnterpriseOne environmental data structures and Oracle database drivers. The 64-bit pointers themselves are also larger than the 32-bit pointers.

Note: IBM i on Power Systems uses memory pools on the OS/400 operating system,herefore, there are no memory profiles for the IBM I on Power Systems platform.

The scalability appeared very linear in all cases. Below are the memory profiles for 100, 250, and 500 users one-hour tests.

Average Business Function Runtime Improvement 32-bit vs 64-bit – Select Applications (Percent)

Application

Oracle Linux + Oracle Database

Microsoft Windows +

Oracle Database

Microsoft Windows +

Microsoft SQL Server

Avg across native 64-bit

IBM i on Power Systems + IBM DB2 Database

Sales Order Entry (P42101) 12.4 8.1 9.5 10.00 -0.8 Work Order Completion (P31114) 13.6 10.2 4.3 9.37 -8.8 Inventory Transfer (P4113) 9.5 0.3 9.5 6.43 -5.2

Average Enterprise Server Memory Increase (32-bit vs 64-bit)

Platform + DBMS 100 Users 250 Users 500 Users Oracle Linux + Oracle Database 20.7 19.2 19.4 Microsoft Windows + Oracle Database 9.7 9.1 7.6 Microsoft Windows + Microsoft SQL Server 4.2 6.0 9.1 IBM I on Power Systems + IBM DB2 Database N/A


Oracle Linux + Oracle Database

Scalability appears very linear

Scalability appears very linear 500 user – 64-bit 500 user – 32-bit

250 user – 64-bit 250 user – 32-bit 100 user – 64-bit 100 user – 32-bit

Microsoft Windows + Microsoft SQL Server: Enterprise Server – 64-bit v 32-bit

500 user – 64-bit 500 user – 32-bit

250 user – 64-bit 250 user – 32-bit 100 user – 64-bit 100 user – 32-bit

Scalability appears very linear

Microsoft Windows + Oracle Database: Enterprise Server – 64-bit v 32-bit

time

time

500 user – 64-bit

500 user – 32-bit

250 user – 64-bit

250 user – 32-bit 100 user – 64-bit

100 user – 32-bit

Oracle Linux + Oracle Database: Enterprise Server – 64-bit v 32-bit

time


Here is a very basic memory test run on the Oracle Linux + Oracle Database configuration:

The total memory usage (Proportional Set Size – “PSS”) was profiled on the Enterprise Server for fifteen minutes on both the 64-bit and 32-bit instances.

Both servers were identically configured with no activity during the test duration. The ambient memory usage of the kernel jobs was measured with no application code running.

Result: 15 percent base increase in memory usage due to 64-bit:

CPU Profiles

The CPU profiles of the non- IBM I on Power Systems platforms showed expected decreases in CPU consumption. This is due to the JD Edwards foundation code and converted application code running natively in 64-bit operating systems rather than in 32-bit compatibility mode

Average Enterprise Server CPU Percent Improvement (32-bit vs 64-bit) Platform + DBMS 100 Users 250 Users 500 Users

Oracle Linux + Oracle Database 5.4 8.7 7.1 Microsoft Windows + Oracle Database 4.3 0.1 7.8 Microsoft Windows + Microsoft SQL Server 2.6 3.6 7.3 IBM I on Power Systems + IBM DB2 Database -1.8 -1.2 -0.4

The primary areas of gains with 64-bit processing are:

• String manipulation routines such as jdestrcmp(), memcpy(), and jdeStrlen() are all more efficient at low levels of the code.

• 64-bit Oracle database drivers

• Running in native 64-bit mode is more efficient than 32-bit compatibility mode. This explains the lower CPU usages.

The IBM I on Power Systems platform is already a native 128-bit platform, so 64-bit processing has little impact on code running in the OS/400 operating system.

64-bit v 32-bit mem (PSS) / no activity

32-bit mem 64-bit mem


The callgrind utility below was used to profile the foundation code on the Oracle Linux platform.

See: Appendix A for the CPU profiles for the 100, 250, and 500 user levels for all four operating system / database configurations.

BATCH JOB RESULTS UBE runtimes were consistently improved in 64-bit versus 32-bit. This is due to the fact that UBEs consist mostly of C Business Function logic, which is made more efficient by the 64-bit processing.

The following table summarizes the results of the eight UBEs tested:

OS + DBMS Runtime UBE

Improvement (Percent)

UBE Memory Footprint Increase (Percent)

CPU Improvement (Percent)


Microsoft Windows + Oracle Database 2.0 15.0 2.2

Microsoft Windows + Microsoft SQL Server 3.0 15.8 12.0

IBM i on Power Systems + IBM DB2 Database -1.8 N/A N/A


Average UBE memory usage increased in the 64-bit case by about 22 percent for Oracle Linux + Oracle Database, and by about 15 percent for the Microsoft Windows platforms. Runtime deltas are not as pronounced on the Microsoft Windows configurations.

Shown below are the results for three representative UBEs in the Oracle Linux + Oracle Database case:

Order Processing (R31410) - (Percent)

• Runtime: 4.1 improvement

• CPU usage: 12.1 improvement

• Memory usage: 21.3 increase

Invoice Print (R42565) - (Percent)




The decreased width in 64-bit indicates a shorter runtime.

The increased height in 64-bit indicates a larger memory footprint.

The decreased width in 64-bit indicates a shorter runtime. The increased height in 64-bit indicates a larger memory footprint.

0

10

20

30

40

50

60

70

80

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

156

CPU

Order Processing- LInux/Oracle - 64-bit v 32-bit CPU

R31410 32-bit CPU R31410 64-bit CPU

0

50000

100000

150000

200000

250000

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

156

MB

Order Processing - LInux/Oracle - 64-bit v 32-bit Memory (PSS)

R31410 32-bit mem R31410 64-bit mem


64-bit v 32-bit CPU Invoice Print 64-bit v 32-bit memory


Invoice Print


MRP Master Planning Schedule - Multiple Plant (R3483) - (Percent)




See Appendix B for the metrics of the three representative UBEs in the Microsoft Windows + Oracle Database and Microsoft Windows + Microsoft SQL Server cases.

The decreased width in 64-bit indicates a shorter runtime.

The increased height in 64-bit indicates a larger memory footprint.

0

10

20

30

40

50

60

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97 101

CPU

R3483 - LInux/Oracle - 64-bit v 32-bit CPU


64-bit v 32-bit memory (PSS)


MRP MRP


STABILITY TEST

An eight-hour stability test was performed for the Oracle Linux + Oracle Database configuration only.

For both the 32-bit and the 64-bit case:

• The 250-user scenario was used with the same mix of 17 DIL Kit scripts as the load test.

• The same set of configurations as the 250 Load test was used:

» Twenty-Five Call Object Kernels » Same DBMS and server settings as the Load tests

There was an 11.6 percent decrease in CPU usage in the 64-bit case:

There was a 16 percent increase in memory usage in the 64-bit case. A known memory leak occurs in system code 42 and 43 applications in both 32-bit and 64-bit cases.

The average Business Function runtime improved by 8.7 percent in the 64-bit case

There was an 11.4 percent improvement in average response time in the 64-bit case.

8-hour

32-bit CPU – 8-hour stability 64-bit CPU– 8-hour stability

32-bit memory (PSS) 64-bit memory (PSS)

8-hour


Package Build

JD Edwards EnterpriseOne Client and Server Package builds (Oracle Linux + Oracle Database) were baselined and measured for the purpose of determining the impact of the 64-bit processing.

The average of four builds was used as the measurement in each use case

• 64-bit Server Package Build (Initial Conversion Case)

Server package builds will run 164 percent longer for the initial 64-bit conversion. This amounted to about 3hours 24minutes being added to package build in the testing.

The reason for this is the conversion of all C Business Functions to 64-bit. Part of the 64-bit upgrade process is a program which scans all the C Business Function source files and applies a set of standard conversion rules to make technical modifications rending the functions 64-bit compatible. This is time consuming but needs to be only once; the base objects will then be 64-bit compatible for all subsequent builds.

• 64-bit Server Package Build (Post Initial Conversion)

After the initial overhead of the conversion is performed, subsequent server package will run about 17 percent longer than 32-bit. In this testing 24 minutes were added to the build duration.

The difference is due to the pulling down of both 32-bit objects (include & source) and 64-bit objects (include64 & source64) to the server package check-in directory in the 64-bit case:

» The 32-bit package build downloads one set of objects: include & source » The 64-bit package build downloads two sets of objects: include & source / include64 & source64

There will likely be an increased package build runtime between historical 32-bit installs and 64-bit installs due to dual maintenance of 64-bit source & include objects.

This overhead will disappear when 32-bit dual maintenance ends.

• Client Package Build

There was negligible impact in client package builds with 64-bit processing.

Note: Package Builds will be much longer for the first build in the 64-bit case. Subsequent 64-bit builds will have an overhead of about 17 percent due to dual maintenance of 32-bit and 64-bit business function objects.


CONCLUSIONS

The 64-bit upgrade impacts processing on the Enterprise Server, and not the JAS server or other EnterpriseOne components.

For 64-bit implementations of EnterpriseOne installations which contain the Enterpriser Server on Oracle Linux and Microsoft Windows you will see:

• An increase in the memory footprint due to the overhead inherent in a 64-bit memory model as compared to the 32-bit.

• A decrease in CPU consumption due to the 64-bit code running more efficiently in 64-bit operating systems.

• A decrease in interactive application response time.

• A decrease in the runtime of C business functions due to the increased efficiency of the 64-bit code running in a 64-bit operating system.

• A decrease in the UBE runtime, which for large batch windows can amount to significant improvements.

On the IBM I on Power Systems platform, there will be little discernable difference in runtime and response of JD Edwards EnterpriseOne applications, as the operating system is 128-bit, and there is no inherent advantage when upgrading the 32-bit code 64-bit code.

No apparent stability issues occurred during testing, and the scalability appeared quite linear.

Server Package builds will run about 17 percent longer due to dual maintenance of 32-bit and 64-bit Business Function objects. For installations which move entirely to 64-bit, this delta will no longer exist. Client Package builds have similar runtimes in both 32-bitand 64-bit environments.

The reasons one would move to the 64-bit version of Oracle JD Edwards EnterpriseOne would be:

• Achieve gains in interactive response times and UBE runtimes due to more efficient processing as native 64-bit code

• Achieve a reduction of CPU cycles on existing servers due to elimination of 32-bit compatibility mode

• These both come with the cost increased memory requirements.


APPENDIX A: LOAD TEST CPU PROFILES Notice how similar the graph shapes are between the 32-bit and 64-bit cases, indicating that 64-bit has not affect the way the code runs.

0

10

20

30

40

50

60

70

1 13 25 37 49 61 73 85 97 109

121

133

145

157

169

181

193

205

217

229

241

253

265

277

289

301

313

325

337

349

361

373

385

% CP

U

500 user Load - Linux/Oracle - 64-bit v 32-bit Ent Server CPU

32-bit Ent Server CPU 64-bit Ent Server CPU

0

5

10

15

20

25

30

35

40

45

1 15 29 43 57 71 85 99 113

127

141

155

169

183

197

211

225

239

253

267

281

295

309

323

337

351

365

379

393

407

421

435

449

463

477

% CP

U

250 user Load - Linux/Oracle - 64-bit v 32-bit Ent Server CPU


0

5

10

15

20

25

30

35

40

45

1 23 45 67 89 111

133

155

177

199

221

243

265

287

309

331

353

375

397

419

441

463

485

507

529

551

100user Load - Linux/Oracle - 64-bit v 32-bit Ent Server CPU


8.7% CPU REDUCTION in 64-bit



%C

PU





64-bit v 32-bit Ent

32-bit Ent Server CPU


64-bit v 32-bit Ent



64-bit v 32-bit Ent


Server CPU

100 user





64-bit v 32-bit Ent Server CPU








1.8% CPU INCREASE in 64-bit









APPENDIX B: MICROSOFT WINDOWS + ORACLE DATABASE & MICROSOFT WINDOWS + MICROSOFT SQL SERVER - UBE STATS

0

200000000

400000000

600000000

800000000

1E+09

1.2E+09

1 34 67 100

133

166

199

232

265

298

331

364

397

430

463

496

529

MB

R3483 - Win/Oracle - 64-bit v 32-bit Mem


0102030405060708090

1 54 107

160

213

266

319

372

425

478

531

584

637

690

743

796

849

902

955

1008

1061

1114

% C

PU

R31410 - Win/Oracle - 64-bit v 32-bit CPU


0100000000200000000300000000400000000500000000600000000700000000

1 61 121

181

241

301

361

421

481

541

601

661

721

781

841

901

961

1021

1081

MB

R31410 - Win/Oracle - 64-bit v 32-bit mem


0102030405060

1 28 55 82 109

136

163

190

217

244

271

298

325

352

379

406

433

460

487

514

% C

PU

R3483 - Win/Oracle - 64-bit v 32-bit CPU


0

20

40

60

80

1 61 121

181

241

301

361

421

481

541

601

661

721

781

841

901

961

1021

1081

1141

% C

PU

R42565- Win/Oracle - 64-bit v 32-bit CPU


0

200000000

400000000

600000000

1 76 151

226

301

376

451

526

601

676

751

826

901

976

1051

1126

MB

R42565- Win/Oracle - 64-bit v 32-bit Mem



01020304050607080

1 61 121

181

241

301

361

421

481

541

601

661

721

781

841

901

961

1021

1081

1141

%CP

U

R31410 - Windows/SQL - 64-bit v 32-bit CPU


0

100000000

200000000

300000000

400000000

500000000

600000000

1 75 149

223

297

371

445

519

593

667

741

815

889

963

1037

1111

MB

R31410 - Windows/SQL - 64-bit v 32-bit memory


0

20

40

60

80

1 33 65 97 129

161

193

225

257

289

321

353

385

417

449

481

513

545

577

609

% C

PU


R3483 32-bit CPUR3483 64-bit CPU

0

500000000

1E+09

1.5E+09

1 35 69 103

137

171

205

239

273

307

341

375

409

443

477

511

545

579

MB

R3483 - Windows/SQL - 64-bit v 32-bit Mem


0

20

40

60

80

1 68 135

202

269

336

403

470

537

604

671

738

805

872

939

1006

1073

1140

% C

PU



0

100000000

200000000

300000000

400000000

500000000

1 57 113

169

225

281

337

393

449

505

561

617

673

729

785

841

897

953

1009

1065

MB

R42565 - Windows/SQL - 64-bit v 32-bit Memory



APPENDIX C: TEST CONFIGURATION

Below are the specifications for major hardware and software resources used in the 64-bit performance testing.

Machines and Platforms

Enterprise Server – Microsoft Windows + Microsoft SQL Server & Microsoft Windows + Oracle Database

• Microsoft Windows Server 2012 R2 • 4 VCPUs x Intel® Xeon® CPU E5-2690 @ 2.90 GHz • 16 GB RAM

Enterprise Server – Oracle Linux + Oracle Database

• Oracle Enterprise Linux 6.9 • 4 VCPUs x Intel® Xeon® CPU E5-2690 @ 2.90 GHz • 16 GB RAM

Enterprise Server / Database Server / HTML Server IBM I on Power Systems + IBM DB2 Database

• OS/400 V7R3 • Model 8205-E6B / 3 VCPU • 5.8 TB • IBM WebSphere 8.5.5.9; Java JDK (1.8)

Database Server – Oracle Linux + Oracle Database:

• Oracle Enterprise Linux 6.9 • Oracle Database12c (12.1.0.2) Enterprise Edition 64-bit • 8 VCPUs Intel® Xeon® CPU E5-2690 @ 2.90 GHz • 32 GB RAM

Database Server – Microsoft Windows + Oracle Database:


Database Server – Microsoft Windows + Microsoft SQL Server:


HTML Server - Microsoft Windows + Oracle Database:

• Oracle Enterprise Linux 6.9 • 4 VCPUs x Intel® Xeon® CPU E5-2690 @ 2.90 GHz • 16 GB RAM • 2 JVM – 4GB Heap each • WebLogic Server 12c; Java JDK (1.8)

HTML Server - Microsoft Windows + Microsoft SQL Server & Microsoft Windows + Oracle Database:

• Microsoft Windows Server 2012 R2 • 4 VCPUs x Intel® Xeon® CPU E5-2690 @ 2.90 GHz • 16 GB RAM • 2 JVM – 4GB Heap each • WebLogic Server 12c; Java JDK (1.8)


Deployment Server - Oracle Linux + Oracle Database & Microsoft Windows + Microsoft SQL Server & Microsoft Windows + Oracle Database:

• Microsoft Windows 2012 R2 Enterprise Edition • 2 VCPUs x Intel Xeon CPU E5-2690 @ 2.90 GHz • 8 GB RAM

Deployment Server - IBM I on Power Systems + IBM DB2 Database

• Microsoft Windows 2012 R2 Enterprise Edition • 1 VCPUs x Intel Xeon CPU E5-2697 @ 2.69 GHz • 6.25 GB RAM

Server Manager Console - Oracle Linux + Oracle Database & Microsoft Windows + Oracle Database & Microsoft Windows + Microsoft SQL Server

• Oracle Enterprise Linux 6.9 • 1 VCPUs x Intel Xeon CPU E5-2690 @ 2.90 GHz • 8 GB RAM

Server Manager Console – IBM I on Power Systems + IBM DB2 Database :

• Microsoft Windows 2012 R2 Enterprise Edition • 1 VCPUs x Intel Xeon CPU E5-2697 @ 2.69 GHz

• 6.25 GB

OATS Test Controller:

• Microsoft Windows 2012 R2 Enterprise Edition • 4 VCPUs x Intel Xeon CPU E5-2697 2.90 GHz • 16 GB RAM • Oracle Application Testing Suite 12.3.0.1.0.376

Software

• 32-bit configuration: JD Edwards EnterpriseOne Application 9.2 with Tools 9.2.1.2 • 64-bit configuration: JD Edwards EnterpriseOne Application 9.2 with Tools 9.2.3.0


APPENDIX D: DATA COLLECTION SCRIPTS

The script used to collect memory and CPU usage on the Oracle Linux platform:

#!/bin/ksh

# JDE-CPU-MEM.sh

# This script captures CPU and memory data for all JDE Enterprise Server processes

# Simply run the script, and the output file will be a .csv which can be opened in Excel for graphing and

analysis

if [ ! -f $HOME/.toprc ]; then

echo "Id:Mode_irixps=0" > $HOME/.toprc

fi

# change these variables to chage smaple interval and number of samples

SAMPLE_INTERVAL=15

NUMBER_OF_SAMPLES=100000

DATE=$(date +"%Y%m%d%H%M")

tempfile=temp_${DATE}

outputfile=JDE-CPU-MEM-$1_${HOSTNAME}_${DATE}_procs.csv

ORA_TOTAL_SIZE=0;

ORA_TOTAL_RSS=0;

ORA_total_pss=0;

ORA_TOTAL_swap=0;

ORA_TOTAL_CPU=0;

JDE_TOTAL_SIZE=0;

JDE_TOTAL_RSS=0;

jde_total_pss=0;

JDE_TOTAL_swap=0;

JDE_JAVA_CPU=0

UBE_jde_total_pss=0

UBE_JDE_TOTAL_RSS=0

UBE_JDE_TOTAL_SIZE=0

UBE_JDE_TOTAL_swap=0

JDE_TOTAL_CPU=0

UBE_JDE_TOTAL_CPU=0

echo "Elapsed seconds", "$1_JAVA_CPU", "$1_JDE-CPU", "$1_UBE-CPU", "$1_free", "$1_PSS", "$1_RSS",

"$1_SWAP", "$1_TOTAL", "$1_UBE_PSS", "$1_UBE_RSS", "$1_UBE_SWAP", "$1_UBE_TOTAL", "ORA_CPU", "ORA_PSS",

"ORA_RSS", "ORA_SWAP", "ORA_SIZE" > $outputfile


chmod 777 $outputfile

for i in {1..$NUMBER_OF_SAMPLES}

do

freemem=$(free -k -t | grep Total | awk -v secs="$i" -v samp="$SAMPLE_INTERVAL" '{printf("%s\n",$3) }')

totalCPU=$(top -b -n2 -d 0.5 |grep "Cpu(s)"| tail -1 | awk '{printf("%s", $5);}' | awk -F% '{printf("%s",

100-$1);}')

COLUMNS=1000 top -c -bn 1 | egrep -i "jdenet|runbatch|java|ora" | awk '{ printf("%d %s %s\n",$1, $9,

$12$13); }' > $tempfile

while IFS=" " read PID CPU COMMAND

do

case $COMMAND in

*emagent*) ;;

*sshd*) ;;

*lframe*) ;;

*perl*) ;;

*egrep*) ;;

*java-server*)

let JDE_JAVA_CPU=$(echo $JDE_JAVA_CPU + $CPU | bc)

;;

*jdenet*)

size=$(sudo awk 'BEGIN {i=0} /^Size/ {i = i + $2} END {print i}' /proc/$PID/smaps)

rss=$(sudo awk 'BEGIN {i=0} /^Rss/ {i = i + $2} END {print i}' /proc/$PID/smaps)

pss=$(sudo awk 'BEGIN {i=0} /^Pss/ {i = i + $2 + 0.5} END {print i}' /proc/$PID/smaps)

swap=$(sudo awk 'BEGIN {i=0} /^Swap/ {i = i + $2} END {print i}' /proc/$PID/smaps)

let JDE_TOTAL_SIZE=JDE_TOTAL_SIZE+size

let jde_total_pss=jde_total_pss+pss

let JDE_TOTAL_RSS=JDE_TOTAL_RSS+rss

let JDE_TOTAL_swap=JDE_TOTAL_swap+swap

let JDE_TOTAL_CPU=$(echo $JDE_TOTAL_CPU + $CPU | bc)

;;

*runbatch*)





let UBE_JDE_TOTAL_SIZE=UBE_JDE_TOTAL_SIZE+size

let UBE_jde_total_pss=UBE_jde_total_pss+pss

let UBE_JDE_TOTAL_RSS=UBE_JDE_TOTAL_RSS+rss

let UBE_JDE_TOTAL_swap=UBE_JDE_TOTAL_swap+swap

let UBE_JDE_TOTAL_CPU=$(echo $UBE_JDE_TOTAL_CPU + $CPU | bc)

;;

*ora*)






let ORA_TOTAL_SIZE=ORA_TOTAL_SIZE+size

let ORA_total_pss=ORA_total_pss+pss

let ORA_TOTAL_RSS=ORA_TOTAL_RSS+rss

let ORA_TOTAL_swap=ORA_TOTAL_swap+swap

let ORA_TOTAL_CPU=$(echo $ORA_TOTAL_CPU + $CPU | bc)

;;

esac

done < $tempfile

echo "$(($i*$SAMPLE_INTERVAL)), ${JDE_JAVA_CPU}, ${JDE_TOTAL_CPU}, ${UBE_JDE_TOTAL_CPU}, ${freemem},

${jde_total_pss}, ${JDE_TOTAL_RSS}, ${ORA_TOTAL_swap}, ${JDE_TOTAL_SIZE}, ${UBE_jde_total_pss},

${UBE_JDE_TOTAL_RSS}, ${UBE_JDE_TOTAL_swap}, ${UBE_JDE_TOTAL_SIZE}, ${ORA_TOTAL_CPU}, ${ORA_total_pss},

${ORA_TOTAL_RSS}, ${ORA_TOTAL_swap}, ${ORA_TOTAL_SIZE}" >> $outputfile

jde_total_pss=0

JDE_TOTAL_RSS=0

JDE_TOTAL_SIZE=0

JDE_TOTAL_swap=0

UBE_jde_total_pss=0

UBE_JDE_TOTAL_RSS=0

UBE_JDE_TOTAL_SIZE=0

UBE_JDE_TOTAL_swap=0

JDE_TOTAL_CPU=0

UBE_JDE_TOTAL_CPU=0

JDE_JAVA_CPU=0

ORA_TOTAL_SIZE=0

ORA_TOTAL_RSS=0

ORA_total_pss=0

ORA_TOTAL_swap=0

ORA_TOTAL_CPU=0

sleep $SAMPLE_INTERVAL

done

rm $tempfile

exit


Business Function timings on all platforms were collected via JD Edwards Enterprise One Server Manager

ORACLE CORPORATION

Worldwide Headquarters 500 Oracle Parkway, Redwood Shores, CA 94065 USA

Worldwide Inquiries TELE + 1.650.506.7000 + 1.800.ORACLE1 FAX + 1.650.506.7200 oracle.com

CONNECT WITH US

Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at oracle.com/contact.

blogs.oracle.com/oracle facebook.com/oracle twitter.com/oracle

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 1218

https://www.oracle.com/

http://www.oracle.com/contact

Oracle JD Edwards EnterpriseOne Notifications …...AIS Server, Orchestrator and other Java-based...

Documents

Transcript of Oracle JD Edwards EnterpriseOne Notifications …...AIS Server, Orchestrator and other Java-based...