Performance and Scalability Benchmark: Oracle ... · PDF filePerformance and Scalability...

An Oracle and IBM White Paper

January 2009

Performance and Scalability Benchmark: Oracle Communications Billing and Revenue Management on IBM Power System 570 Server, IBM System Storage DS8300, and AIX 6.1


Introduction ....................................................................................... 2

Executive Overview........................................................................... 4

Key Takeaways ............................................................................. 5

Application and Hardware Overview.................................................. 6

Oracle Communications Billing and Revenue Management .......... 6

The Applications Tier.............................................................................. 7

Oracle Communications Billing and Revenue Management

Server Tier .............................................................................................. 7

The Data Tier.......................................................................................... 8

Scalability ............................................................................................... 8

IBM Power Systems: Power System 570 Server ........................... 9

IBM System Storage DS8000 Turbo Series................................. 11

Performance and Benchmarking Environment................................. 12

Software and Hardware Overview ............................................... 12


Software Release ................................................................................. 12

Oracle Database and Oracle RAC Software Release.......................... 12

Application Server for 100 Million Subscribers..................................... 12

Database Server for 100 Million Subscribers ....................................... 13

AIX 6.1 Operating System.................................................................... 13

System Architecture for 100 Million Subscribers.................................. 13

Results ........................................................................................ 16

Key Performance Numbers .................................................................. 16

Rating and Discounting ........................................................................ 17

Billing .................................................................................................... 23

Conclusion ...................................................................................... 24


2

Introduction IBM and Oracle have been working together for more than a decade to optimize Oracle

Database on the IBM POWER™ architecture running the AIX® operating system. Oracle

Database 10g and Oracle Real Application Clusters (Oracle RAC) 10g are well proven to

take advantage of IBM’s POWER6™ architecture and high I/O bandwidth, Together they

provide the response time needed to achieve breakthrough throughput to deliver a highly

scalable Oracle Communications Billing and Revenue Management and IBM POWER

solution on Oracle RAC architecture with the lowest total cost of ownership.

The Oracle Communications Billing and Revenue Management application is a Tier 1,

fully convergent prepaid and postpaid solution that is architected for leading service

providers and employs an architecture that enables convergent models to coexist and

offer integrated services. Following are a few key features of Oracle Communications

Billing and Revenue Management:

• Delivers a converged billing solution for the communications and media markets

• Enables charging for any service or event based on any payment type, network,

geography, or resource

• Provides industry-leading pricing, rating, discounting, promotions, and sharing

capabilities

• Demonstrates linear scalability to support any business model and scenario

• Integrates with other applications through a SOA-based enterprise-grade integration

architecture with built-in features for optimal performance

Over the years and through regularly scheduled releases, the Oracle Communications

Billing and Revenue Management application has grown into a robust convergent billing

solution that is architecturally stable, offers predictable performance, scales horizontally,

runs on several leading operating systems, and can be configured for specific needs. As


3

a result, there is a continuous need to perform benchmark and scalability analysis to

ensure that the application outperforms the needs of Tier 1 service providers.

This white paper describes the performance and scalability results of Oracle

Communications Billing and Revenue Management 7.3.1 from a recent benchmark

conducted at IBM laboratories in Beaverton, Oregon, USA. The Oracle Communications

Billing and Revenue Management benchmark was done on IBM Power™ System 570

servers running AIX 6.1 and IBM DS8300™ storage subsystems.


4

Executive Overview Oracle Communications and IBM recently completed an extensive performance and

scalability benchmark exercise for Oracle Communications Billing and Revenue

Management 7.3.1 running on IBM Power System 570 servers with the IBM AIX 6.1

operating system and IBM PowerVM™ virtualization technology. For this benchmark,

Oracle Database 10g Enterprise Edition with Oracle RAC was used for the database

system, hosted by IBM DS8300 storage subsystems. The benchmark included various

workloads such as rating and discounting, billing, invoicing, and customer service

representative (CSR) activities using a variety of plans modeled after real-life enterprise

customer scenarios.

The environment simulated represents a production Oracle Communications Billing and

Revenue Management environment capable of sustaining 100 million subscribers

distributed across 12 RAC nodes. Results are based on two mobile price plans and

workloads. Descriptions of the plans are provided in subsequent sections of this

document. The benchmark results demonstrate outstanding performance and scalability

by both Oracle Communications Billing and Revenue Management and IBM Power

System 570 servers, using PowerVM technology for optimal flexibility, server

consolidation, and cost reduction.

The overall system configuration consisted of six Power System 570 sixteen-core servers

configured with 128GB of RAM used for the database servers; six Power System 570

sixteen-core servers configured with 256GB of RAM used for the Oracle Communications

Billing and Revenue Management application servers; and two DS8300 storage

subsystems, one with 128GB cache and 512K disks and the other with 64GB cache and

128K disks. The hardware configuration details and lab infrastructure environment are

described in detail in the “Performance and Benchmarking Environment” section (see

page 12).

The Oracle Communications Billing and Revenue Management performance benchmark

was performed for several key workloads and subscriber volumes to reflect linear

scalability and throughput.

The key workloads evaluated were


5

• Rating and discounting

• Billing

• Invoicing

They were performed for multiple-subscriber configurations, with volumes of 33 million,

66 million, and 100 million subscribers.

TABLE 1. THROUGHPUT RESULTS FOR DIFFERENT BENCHMARK WORKLOADS

SUBSCRIBER NUMBERS BENCHMARK

WORKLOAD

33 MILLION 66 MILLION 100 MILLION

DETAILS

Rating and Discounting

(end-to-end)

12,451 call data

records (CDRs)

per second

23,230 CDRs

per second

34,866 CDRs

per second

For 100 million subscribers, the

system setup can process 126 million

CDRs per hour.

Rating

(end-to-end)

17,810 CDRs

per second

33,713

CDRs

per second

48,896 CDRs

per second


system setup can process 176 million

CDRs per hour.

Billing

683 bills

per second

1,342 bills

per second

2,027 bills

per second


system setup can process 7.3 million

bills per hour. Total time to process

100 million subscribers is 13.7 hrs.

Invoicing of

100 events

per account

887 invoices

per second

1,742 invoices

per second

2,315 invoices

per second


system setup can process 8.3 million

invoices per hour.

Key Takeaways

The benchmark tests demonstrated near-linear scalability with volumes of 33 million, 66

million, and 100 million subscribers:

• For 33 million subscribers, 45 million CDRs per hour were processed.


6



Per-hour processing numbers are dependent on the performance of the storage, and the

throughput can vary. The use of a high-end storage area is important in order to achieve

optimal results.

• 100 million subscribers can be billed in approximately 14 hours. This demonstrates that

for all 100 million subscribers, billing can be performed in a single day or single billing

cycle.

The Oracle Communications Billing and Revenue Management benchmark for 100

million subscribers was recently performed by the Oracle Communications and IBM

teams. Joint operational activities included product installation; benchmark execution;

and documentation, analysis, and reporting of the results.

Application and Hardware Overview

The following section provides a description of the applications and hardware systems that

comprised the 100-million-subscriber benchmark.


The Oracle Communications Billing and Revenue Management architecture provides the

foundation for the end-to-end Oracle Communications Billing and Revenue Management

solution. Functionality is segregated into layers using well-defined interfaces, enabling each to be

modified and enhanced without disruption of functionality at the platform level.

At the same time, this design enables the platform to evolve without adverse effects on

functional capabilities. As a result, Oracle is able to develop and advance Oracle

Communications Billing and Revenue Management’s capabilities rapidly while enabling service

providers to easily extend the system to meet unique business requirements.


7

Figure 1. Oracle Communications Billing and Revenue Management architecture

The Oracle Communications Billing and Revenue Management platform utilizes a modern n-tier

architecture, which is typically deployed with the following three-tier configuration:

The Applications Tier

The applications tier consists of programs and processes that use the object-oriented API as an

interface to the Oracle Communications Billing and Revenue Management system. This tier

includes the Oracle Communications Billing and Revenue Management client applications such

as Customer Center, Pricing Center, and other native as well as third-party applications

developed by customers and partners using the same documented API. All enterprise as well as

network applications can integrate and interact with the Oracle Communications Billing and

Revenue Management system through the applications tier.

Oracle Communications Billing and Revenue Management Server Tier

Oracle Communications Billing and Revenue Management server tier consists of three

components: the Real-Time Revenue Management Server, the Batch Processing Server, and the

Object Server.

• The Real-Time Revenue Management Server enforces business policies. It consists of

Connection Managers (CMs) and discount, rerating, zoning, and facilities modules. The CMs

manage connections between the application tier and the functional modules, process data

collected by Oracle Communications Billing and Revenue Management client applications, and


8

enforce the business rules. This architecture allows easy customization of the Oracle

Communications Billing and Revenue Management system to meet unique business

requirements.

• The Batch Processing Server is optimized to handle large volumes of transactions (e.g.

hundreds of millions of transactions per day) in terms of preprocessing, enrichment, duplicate

checking, aggregation, and rating - among other functions.

• The Object Server provides an abstraction of the stored data. This layer consists of Data

Managers (DMs) that translate requests from CMs into a language recognized by the Oracle

Communications Billing and Revenue Management database or other data access systems. The

Oracle Communications Billing and Revenue Management system provides a DM for the

Oracle database server, as well as DMs for other external systems, such as the credit card and

tax processing applications.

The Data Tier

The data tier consists of Oracle Database and other data access systems. The Oracle

Communications Billing and Revenue Management application currently supports Oracle

Database Enterprise Edition as well as Oracle RAC as the primary database system. Oracle

Communications Billing and Revenue Management is also pre-integrated with other data access

systems in this tier; for example, credit card processing, LDAP and taxation systems.

Scalability

The Oracle Communications Billing and Revenue Management application achieves high

scalability in several ways. First, its multi-tier architecture is designed to run all Billing and

Revenue Management processes on the same computer or distributed among several computers.

Distributed processing allows for maximum flexibility and optimal load distribution for

configuring an Oracle Communications Billing and Revenue Management system as the number

of users expands. As a result, service providers can add as many servers as required in the

application, Oracle Communications Billing and Revenue Management server, and data tiers.


9

Figure 2. Oracle Communications Billing and Revenue Management scalability architecture

A second factor that contributes to the high scalability of Oracle Communications Billing and

Revenue Management is the combination of transactional real-time and near real-time batch

processing that utilizes a multi-threaded, pipelined architecture and in-memory processing.

Integrated support for both types of rating makes extremely high performance possible.

To further improve scalability, Oracle Communications Billing and Revenue Management lets

providers easily balance load processing by reconfiguring client and database connections. This

enables providers to smooth out usage spikes at the front-end and avoid bottlenecks at the

database level.

Finally, transaction management functions have been built into the object layer, enabling Oracle

Communications Billing and Revenue Management to fully scale and take advantage of the

underlying hardware. Without this capability, load balancing would be limited beyond a certain

transaction level.

IBM Power Systems: Power System 570 Server

Figure 3. Power System 570 modular building block

Twelve IBM Power System 570 servers, as represented by Figure 3, were used for the

performance measurements conducted in this scalability test. The IBM POWER6 processor-


10

based servers used in this test deliver outstanding price and performance, mainframe-inspired

reliability and availability features, flexible capacity upgrades, and innovative virtualization

technologies. Enterprise systems based on POWER6 technology, such as the ones used for the

database servers in this test, can be used for database and application serving, as well as server

consolidation.

The Power System 570 server is a modular system designed for resource optimization, secure and

dependable performance, and the flexibility to change with business needs.

The Power System 570 server was the first server delivered with POWER6 processors, resulting

in performance and price/performance advantages while ushering in a new era in the

virtualization and availability for the AIX operating system. POWER6 processors can run 64-bit

applications, while concurrently supporting a 32-bit-applications environment to enhance

flexibility. They feature simultaneous multithreading, enabling two application threads to run at

the same time, which can significantly reduce the time to complete tasks.

The Power System 570 is more than an evolution of technology wrapped into a familiar package;

it is the result of thinking outside the box. The IBM modular symmetric multiprocessor (SMP)

architecture means that the system is constructed using four-core building blocks. This design

enables clients to address their current requirements and allow for growth by adding more

building blocks, all without the disruption and expense of replacing the complete system.

For server consolidation, the Power System 570 provides the flexibility to simultaneously run any

combination of AIX, IBM Linux for Power, and x86 Linux applications, all on the same system.

In addition, the PowerVM available on the Power System 570 enables dynamic resource

adjustments across all of these environments to optimize performance and efficiency while

minimizing energy usage, for better control of your IT environment.

For complete business system needs, the Power System 570 provides a unique combination of

performance across multiple workloads and availability features to keep your business running.

In addition, PowerVM virtualization helps maximize your efficiency and non-disruptive growth

options, designed to keep your costs in line with your business. The configuration highlighted in

this performance test makes use of the PowerVM virtualization technology to serve the Oracle

RAC 10g cluster servers.

IBM AIX 6.1 Operating System

For the performance tests conducted in this project, all servers ran the AIX 6.1 operating system,

the newest release of the operating system. This version introduces a new, software-based

virtualization approach called Workload Partitions (WPAR) that complements existing logical

partitioning capabilities of IBM Power Systems by reducing the number of operating system

images to be managed during workload consolidation.


11

In addition, this new version of the AIX operating system offers new security; file system;

network data administration; tracing; maintenance; and Reliability, Availability and Serviceability

(RAS) features.

IBM System Storage DS8000 Turbo Series

Figure 4. IBM System Storage DS8000

The IBM System Storage DS8000 series is designed for the most demanding, mission-critical

environments requiring the highest level of availability for both the open systems arena and the

enterprise space supporting both IBM System z and IBM Power Systems. This, combined with

its world-class resiliency features, make it an ideal storage platform for supporting today’s

around-the-clock, global business environment. Moreover, with its tremendous scalability, broad

server support, and flexible virtualization capabilities, the DS8000 Turbo can help simplify the

storage environment and consolidate multiple storage systems onto a single DS8000 system.

The DS8000 can help lower the total cost of ownership and reduce the complexity of managing

storage environments. Physical capacity can range from 1.1TB up to 460TB on a single system

without disruption, providing scalability on which to grow or consolidate data. A consolidated

system such as this can help customers address their cost, performance, and capacity

requirements more effectively, while simplifying their storage environments. RAID-5, RAID-6,

and RAID-10 configurations can be intermixed within a single DS8000 series system, which adds

to its outstanding flexibility. And the DS8000 now supports Dynamic Volume Expansion, where

open systems LUNs and System z disks can be increased in size while online to the host servers.

The DS8000 supports several varieties of FlashCopy, including Incremental FlashCopy and

Space-Efficient FlashCopy. The DS8000 also supports both synchronous and asynchronous

Remote Copy as well as a hybrid synchronous/asynchronous three-site Remote Copy capability.


12

The IBM SAN Volume Controller can extend the DS8000’s powerful capabilities to offer

additional advanced functions, such as thin provisioning, as well as heterogeneous storage

virtualization and online data migration.

Two DS8300 series systems were used in this performance test. The IBM DS8300 can be used to

sustain up to 4.9 million I/O per second (IOPS).1

Moreover, the DS8000 system can stripe data across multiple RAID arrays to help minimize disk

“hot spots” and reduce the need for manual tuning.

Performance and Benchmarking Environment

This section describes the system architecture and configuration environment for the Oracle

Communications Billing and Revenue Management benchmark.

Software and Hardware Overview

The software and hardware components and their configuration for the system used in the

Oracle Communications Billing and Revenue Management benchmark were as follows:

Oracle Communications Billing and Revenue Management Software Release

• Oracle Communications Billing and Revenue Management 7.3.1 for AIX

Oracle Database and Oracle RAC Software Release

• Oracle Database 10g Enterprise Edition Release 10.2.0.4.0—64-bit production, with

Partitioning and Oracle RAC options

Application Server for 100 Million Subscribers

Six IBM Power System 570 servers were used for the Oracle Communications Billing and

Revenue Management application. Each system was used with all resources in a dedicated logical

partition (LPAR) to host the Oracle Communications Billing and Revenue Management

application workload, with the following configuration:

• Eight 4.7GHz POWER6 processor chips, totaling 16 cores

1 “The IBM DS8000 Enterprise Class Performance and Functionality,” Enterprise Strategy Group, February 2008


13

• 256GB of RAM

• 4 x IBM 2-Port Gigabit Ethernet-SX

• 12 x 146GB 15K-RPM SAS disk drives

Database Server for 100 Million Subscribers

Six IBM Power System 570 servers were used for Oracle Database. Each system was configured

with two LPARs, with even resources between the two, for a total of 12 LPARs hosting 12

Oracle RAC nodes.

The six IBM Power System 570 servers had the following configuration:

• Eight 4.7GHz POWER6 processor chips, totaling 16 cores

• 128GB of RAM

• 4 x IBM 2-Port Gigabit Ethernet-SX

• 12 x 146GB 15K-RPM SAS disk drives

• 6 x 4-Gigabit PCI Express Dual Port Fibre Channel Adapter

AIX 6.1 Operating System

All active LPARs hosting both the Oracle Communications Billing and Revenue Management

application components and Oracle Database server nodes used the following AIX version:

• AIX Version 6.1 TL1 (application servers)

• AIX Version 6.1 TL1 SP1 (database servers)

System Architecture for 100 Million Subscribers

This section outlines the systems and plan types used in the benchmark.

Plan Types

The mobile price plans used in this performance benchmark are standard performance

configurations used by Oracle Communications performance engineering. The two price plans

described below were used in the benchmark evaluation:

• The benchmark comprised mobile price plans that were representative of customer cases for

telephony and SMS services. The plan incorporates two resources ― free minutes and

currency ― and two types of discounts that are applied during usage rating and billing. A flat

fee is applied to two services.

• The second benchmark used a similar plan, but it did not apply the discounts.


14

Oracle Communications Billing and Revenue Management Application Layout

The 100-million-subscriber accounts were split into groups of approximately 8 million

subscribers over 12 schemas. Each schema was handled by one Oracle RAC node. Together, the

12 schemas (Oracle RAC nodes) made up a single Oracle RAC database instance. Oracle RAC

was installed on Power System 570 servers, as detailed in the “Configuration Layout” section of

“Rating and Discounting” on page 17.

Subscriber growth is managed by distributing subscriber information across multiple schemas in

Oracle RAC. This distribution allows linear subscriber growth. As more subscribers are added to

the Oracle Communications Billing and Revenue Management system, they can be distributed

across existing or new schemas. Similarly, new schemas can be added on demand to expand

Oracle Communications Billing and Revenue Management subscriber growth beyond 100 million

subscribers.

Hardware Layout

The Oracle Communications Billing and Revenue Management benchmark environment

consisted of a private Gigabit Ethernet network that connected the Oracle Communications

Billing and Revenue Management application servers (Application Server No. 1 through

Application Server No. 6) and the Oracle RAC server nodes (Database No. 1 through Database

No. 12) Power System 570 servers.

Each Oracle Database server node consisted of a Power System 570 LPAR configured as

follows:

• Eight 4.7GHz processor cores, two logical nodes per server

• 64GB of RAM

• Four configured Gigabit Ethernet adapters (one for VPN login purposes, two dedicated

exclusively to cluster communication, and one for database/application communication)

• One internal disk installed for the operating system, database software, and paging space

• One internal disk (on one database server node only) for storing shared files required by the

test environment, NFS mounted by all other database nodes, and application servers

All database nodes used a dedicated Gigabit Ethernet switch for the cluster communication on a

separate network. The Oracle Database and Oracle Communications Billing and Revenue

Management application server used a separate Gigabit Ethernet switch and network for the

workload communication. Figure 5 illustrates the systems network configuration.


15

Figure 5. Hardware layout for Oracle Communications Billing and Revenue Management benchmark

The DS8300 storage subsystems were configured in the following manner:

• DS8300 No. 1: 128GB cache, 16 host adapters, and one 512K disk used for database data and

redo logs (480 data disks plus 32 spares).

• DS8300 No. 2: 64GB cache, 8 host adapters, and one 128K disk used for database data (120

data disks plus 8 spares).

• All database data and redo logs are managed by Oracle Automatic Storage Management.

Each of the 12 database nodes were connected by use of three Fibre Channel ports on two dual-

port host bus adapters (HBAs) attached to DS8300 No. 1 and two Fibre Channel ports on one

dual-port HBA attached to DS8300 No. 2.

The six Power System 570 servers were configured in the following manner for the Oracle

Communications Billing and Revenue Management workloads—rating and discounting, billing,

and invoicing:

• Application Server No. 1: 4 x (pipeline processes + Rated Event Loader [RE Loader]), 4 x

Oracle Communications Billing and Revenue Management real-time

• Application Server No. 2: Router, 4 x Oracle Communications Billing and Revenue

Management real-time

• Application Server No. 3: 4 x (pipeline processes + RE Loader), 4 x Oracle Communications

Billing and Revenue Management real-time)


16

• Application Server No. 4: 4 x Oracle Communications Billing and Revenue Management real-

time

• Application Server No. 5: 4 x (pipeline processes + RE Loader), 4 x Oracle Communications

Billing and Revenue Management real-time

• Application Server No. 6: 4 x Oracle Communications Billing and Revenue Management real-

time

Oracle Communications Billing and Revenue Management workloads—rating and discounting,

billing, and invoicing—were all evaluated independently for performance results. Each

application server was set up with chains of processes to evaluate Oracle Communications Billing

and Revenue Management workloads. Each of these chains of processes collaborates for a given

workload to provide optimal throughput.

Application servers Nos. 1, 3, and 5 each had four NFS exports, each of which is a file system on

one local disk. The pipeline router process on Application Server No. 2 uses these 12 mounts to

distribute files for the RE Loader to process.

Results

The Oracle Communications Billing and Revenue Management performance benchmark was

performed for several key workloads and subscriber volumes to test linear scalability and

throughput. The key workloads evaluated were:

• Rating and Discounting

• Billing

• Invoicing

The benchmark was performed for multiple-subscriber configurations, with volumes of 33

million, 66 million, and 100 million subscribers.

Key Performance Numbers

The benchmark tests demonstrated near-linear scalability with volumes of 33 million, 66 million,

and 100 million subscribers.




• 100 million subscribers can be billed in approximately 14 hours, demonstrating that for all 100

million subscribers, billing can be performed in a single day or a single bill cycle.


17

Rating and Discounting

The rating and discounting workloads perform evaluations of service usage and associated rating

and discounting. This involves processing of CDR files and updating of subscriber balances.

During the performance evaluation, batch processing for 33-million-, 66-million-, and 100-

million-subscriber accounts was performed, with emphasis on evaluating Oracle

Communications Billing and Revenue Management system scalability. The following sections

provide insight into the configuration layout, multi-schema end-to-end results, batch processing

architecture, scalability chart, and CPU and I/O utilization.

Configuration Layout

Figure 6 identifies the Oracle Communications Billing and Revenue Management components

involved in batch processing:

Figure 6. Batch processing configuration layout for 100 million subscribers

For the Oracle Communications Billing and Revenue Management rating and discounting

workload, the following was the configuration layout setup:

• Four application servers were set up to process the workload—each application server was

represented by an IBM Power System 570 server with eight 4.7GHz POWER6 processor

chips, totaling 16 cores and 256GB of RAM.

• On one application server, the router was set up to route CDR files for rating. The router used

16 cores.

• Three application servers were used by the Pipeline Manager (for rating and discounting) and

by the RE Loader (for loading the data into the database). Forty-eight total cores were assigned

to the pipeline and RE Loader combination.

• Each application server had four pipeline processes. Because the configuration is represented

by three application servers, a total of 12 pipeline processes existed. Each rating engine was

mapped to one Oracle RAC node.

• Twelve Oracle RAC nodes were set up in a multi-schema architecture to handle 100 million

subscribers. Two nodes per physical Power System 570 server was the setup—a total of six


18

servers. Each server was represented by eight 4.7GHz POWER6 processor chips, totaling 16

cores and 128GB of RAM. Ninety-six total cores were used by the Oracle RAC node setup.

Table 2 summarizes the configuration layout for the rating and discounting workloads.

TABLE 2. RATING AND DISCOUNTING CORES AND RAM USAGE

NODE ROLE CORES MEMORY

Rating Server 1 Pipeline

Processes

16 256GB


Processes

16 256GB


Processes

16 256GB

Pipeline Router Router 16 256GB

RAC Node 1 Database Server 8 64GB





The total hardware layout available for benchmarking consisted of 192 cores. However, only a subset

number (160 cores) was used during the rating and discounting performance evaluation.

Table 3 summarizes end-to-end usage rating and discounting performance evaluation. End-to-

end rating implies the complete flow from initial routing, rating, discounting, and database

updates including event recording and balance updates.


19

TABLE 3. 100-MILLION-SUBSCRIBER END-TO-END RATING AND DISCOUNTING PROCESSING RESULTS

MULTISCHEMA RATING CDRS/SEC COMPLETE END-TO-END CDRS/SEC COMPLETE END-TO-END MILLION

CDRS / HOUR

Schema 1 3375 3243 11.67

Schema 2 3428 3292 11.85

Schema 3 3495 3351 12.06

Schema 4 3373 3238 11.66

Schema 5 3260 3143 11.31

Schema 6 3252 3139 11.30

Schema 7 3269 3153 11.35

Schema 8 3243 3127 11.26

Schema 9 3249 3137 11.29

Schema 10 3238 3120 11.23

Schema 11 3267 3153 11.35

Schema 12 3260 3153 11.35

Total 39,709 38,249 137.69

As Table 3 shows, the complete end-to-end CDRs/second for 100 million subscribers is 38,249.

However, this end-to-end number does not account for the process start time and the delay until

the final CDR is rated. The final end-to-end numbers are calculated after subtraction of these delays and are

shown in Table 4.

TABLE 4. RATING AND DISCOUNTING RESULTS

NO. OF

SUBSCRIBERS

NO. OF END-TO-

END CDRS /

SECOND

FINAL END-TO-END CDRS / HOUR

33 million 12,451 45 million CDRs/hour




20

Table 5 highlights the end-to-end rating results achieved using the price plan that did not include

discounting.

TABLE 5. RATING RESULTS

NO. OF

SUBSCRIBERS

NO.OF END-TO-

END CDRS /

SECOND

FINAL END-TO-END CDRS / HOUR

33 million 17,810 64M CDRs/hour



Scalability

Oracle Communications Billing and Revenue Management end-to-end batch processing shown

in Table 4 and Table 5 demonstrates near-linear scalability with respect to the number of

processed CDRs per second. The rating and discounting results are also charted in Figure 7:

Figure 7. Oracle Communications Billing and Revenue Management batch processing and linear scalability

The processing of end-to-end CDRs per second grew linearly from 33 million to 66 million to

100 million subscribers. The linear growth implies that the system can be configured to scale

even beyond 100 million subscribers and that the processing growth and time can be predicted.

This is important for service provider, because it means that they can forecast the hardware and


21

architecture needed to scale the Oracle Communications Billing and Revenue Management

system based on their projections.

Pipeline Manager

Oracle Communications Billing and Revenue Management provides a high-performance

processing engine, with an in-memory cache, whose functionality can be tailored to each

customer’s needs by choosing and assembling standard plug-ins, as well as supporting

customization using a powerful, flexible, and efficient scripting language. It also provides a

language for describing the format of the input/output files, mapping input/output fields onto

internal data structures called extended data records (EDRs), and describing the grammar of the

input/output files.

Rated Event Loader

The RE Loader uploads the events rated by the Pipeline Manager into the database. Oracle

Communications Billing and Revenue Management provides a multi-schema feature for

distributing subscriber accounts on multiple schemas. The multi-schema feature provides nearly

unlimited scalability and can be expanded for subscriber growth.

Figure 8. Conceptual data flow diagram for Oracle Communications Billing and Revenue Management pipeline rating

Following is the data flow during pipeline processing:

• CDR files are processed by a pipeline configured in “router mode.”

• When a CDR is processed, the A-number and the charging time stamp are used to find the

schema number on which the subscriber account resides.

• The CDR is then guided to the appropriate pipeline processes for rating. The sets of pipelines

process the incoming CDRs and produce a set of output files containing “rated” calls.

• The output files are then loaded into the Oracle Communications Billing and Revenue

Management database via the RE Loader processes.


22

• The three processes described above –- Routing Pipeline, Rating Pipeline and RE Loader –-

work in parallel.

• While the router is processing file i, the rating frameworks are processing files i-1, and RE

Loader processes are loading files i-2.

Figure 9. Pipeline process model

Application and Database Server CPU Utilization

An important metric for this rating and discounting processing workload was CPU utilization.

Figure 10 and Figure 11 show the CPU percentages of both the application and Oracle Database

server nodes during the benchmark tests.

Figure 10. Application servers’ CPU percentage for 100 million subscribers

Time

File i File i+1 File i+2

File i-1 File i File i+1

File i-2 File i-1 File i

Router

Rating

RE Loader

Application Servers CPU Utilization

0

10

20

30

40

50

60

70

80

90

100

Elapsed time

CPU%

Rating Server 1

Router Server

Rating Server 2

Rating Server 3


23

Figure 10 shows the CPU utilization during the 100-million-subscriber rating and discounting

workload.

Figure 11 shows the CPU utilization of each of the 12 LPARs used during the 100-million-

subscriber rating and discounting workload for the Oracle Database nodes, with an average 38

percent CPU utilization across all servers.

Figure 11. Database server nodes’ CPU percentage for 100 million subscribers

Billing

Oracle Communications Billing and Revenue Management billing is used to generate a bill for a

given subscriber account on a cyclical or on-demand basis. The generation of the bill is

dependent on the billing cycle of the account—monthly, bi-monthly, quarterly, semi-annually, or

annually. To generate a bill for a given customer account, a setup of applications is run that

finalizes the bill for a given period.

Billing was evaluated as a key workload during this performance and benchmark analysis.

Following are the billing results:

TABLE 6. BILLING RESULTS

NO. OF

SUBSCRIBERS

NO. OF BILLS /

SECOND

TIME NEEDED TO BILL GIVEN NO. OF

SUBSCRIBERS

33 million 603 15 hours to bill 33 million



Oracle RAC Nodes CPU Utilization

0

10

20

30

40

50

60

70

80

90

100

Elapsed Time

CPU%

Node 1

Node 2

Node 3

Node 4

Node 5

Node 6

Node 7

Node 8

Node 9

Node 10

Node 11

Node 12


24

These results show that it is possible to bill all the subscribers in a single billing cycle and in less

than 24 hours.

Scalability

Table 6 shows Oracle Communications Billing and Revenue Management’s excellent linear

scalability for billing across various numbers of subscribers. Figure 12 is a chart of the results:

Figure 12. Oracle Communications Billing and Revenue Management billing linear scalability

It is evident from the Oracle Communications Billing and Revenue Management billing chart

(Figure 12) that the number of bills per second grew linearly with the addition of hardware chains

to accommodate the increase in subscriber count and workload. These results also demonstrate

the architectural flexibility of Oracle Communications Billing and Revenue Management for

scaling independently of workloads and across subscriber growth boundaries.

Conclusion

As this document has shown, the results achieved by Oracle Communications Billing and

Revenue Management 7.3.1 with a 100-million-subscriber workload demonstrate unprecedented

performance and scalability. The results also demonstrate Oracle Communications Billing and

Revenue Management’s ability to handle the most stringent workload requirements of Tier 1

Service Providers and provide for substantial growth requirements as subscriber numbers grow.

Furthermore, the benchmark results prove the ability of all the application components of Oracle

Communications Billing and Revenue Management to scale independently, as well as together, to

track the requirements of the complete revenue management lifecycle with real-life production

workloads.


25

The performance numbers were higher than those achieved in previous Oracle Communications

Billing and Revenue Management benchmarks. These results demonstrate the capability of the

IBM Power System 570 server and the Oracle Communications Billing and Revenue

Management application running on the AIX 6.1 operating system to handle a real-life workload

in a high-end production environment with excellent performance. All of this, combined with the

use of IBM Power Systems and Oracle RAC 10g, provides an optimal performance platform with

near-linear scalability. It also facilitates deployment and business productivity.

Since 1986, IBM and Oracle have had a relationship revolving around business and technology

innovation. From application selection, purchase, and implementation to upgrades and

maintenance, IBM offers the services and systems to help you succeed at each stage of your

Oracle investment. IBM’s POWER Systems hold top performance benchmark positions for

many Oracle applications and, in some cases, the top first, second, and third benchmark

positions. IBM’s Global Business Services Oracle Practice is one of Oracle’s strongest

partnerships, with more than 10,000 skilled Oracle Applications consultants.

THIS DOCUMENT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY AND IS

NOT INTENDED TO BE, NOR SHALL IT BE CONSTRUED AS A COMMITMENT TO

DELIVER ORACLE PROGRAMS OR SERVICES. THIS DOCUMENT SHALL NOT

FORM THE BASIS FOR ANY TYPE OF BINDING REPRESENTATION BY ORACLE

AND SHALL NOT BE CONSTRUED AS CONTAINING EXPRESS OR IMPLIED

WARRANTIES OF ANY KIND. YOU UNDERSTAND THAT THE INFORMATION

CONTAINED IN THIS DOCUMENT WILL NOT BE A PART OF ANY AGREEMENT FOR

ORACLE PROGRAMS OR SERVICES. BUSINESS PARAMETERS AND OPERATING

ENVIRONMENTS VARY SUBSTANTIALLY FROM CUSTOMER TO CUSTOMER AND

AS SUCH NOT ALL FACTORS WHICH MAY IMPACT PERFORMANCE IN YOUR

ENVIRONMENT MAY HAVE BEEN ACCOUNTED FOR IN THE BENCHMARKS

EXECUTED.

Performance and Scalability Benchmark:

Oracle Communications Billing and Revenue

Management on IBM Power System 570, IBM

System Storage DS8300, and AIX 6.1

January 2009

Author: Dinesh Sardana, Tony Velcich, Brian

Pawlus

Contributing Author: Numi Castillo, IBM

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright © 2009, 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 is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective

owners.

0109

Date post:	18-Mar-2018
Category:	Documents
Upload:	duonghuong
View:	232 times
Download:	0 times

Performance and Scalability Benchmark: Oracle ... · PDF filePerformance and Scalability...

Documents