An Introduction to the MOCAng Architecture

Confidential 2009 RedPrairie Corporation. All rights reserved.

September 28, 2009

Introduction to MOCAng Archtecture

Friday, September 25, 2009


The Basics -- How We Got Here

Legacy MOCA has a scalability problem> MOCA is Centered around MOCA Server Processes> We spawn mocasrvprc, as needed, to support load> Each mocasrvprc contains

Single DB connection (traditionally) The MOCA engine Command configuration (via memory file) Loaded libraries for commands JVM (since 2005.2) Loaded Java classes and libraries Various ad-hoc caches, depending on what commands have been run

> Policies> Integrator metadata

> Process startup time has become a problem Weve implemented changes to the connection manager process limits to

avoid spawning too often.

2


Confidential 2009 RedPrairie Corporation. All rights reserved.3

Classic MOCA Structure

Images should align with the top of the red vertical bar.



Classic MOCA Structure -- mocasrvprc

4


Confidential 2009 RedPrairie Corporation. All rights reserved.5

Com

man

ds

JVM

DB

C

onne

ctio

n

Com

pone

nt

Libr

arie

s

Cac

hes

MO

CA

Eng

ine

Clients Connection Manager Server Processes

Com

man

ds

JVM

DB

C

onne

ctio

n

Com

pone

nt

Libr

arie

s

Cac

hes

MO

CA

Eng

ine

Com

man

ds

JVM

DB

C

onne

ctio

n

Com

pone

nt

Libr

arie

s

Cac

hes

MO

CA

Eng

ine



Classic MOCA Structure -- Problems

Implemented in C

Encourages C components

Proprietary Middleware

32-bit Limitation

Bloat Multiplier

6



Bloat Multiplier?

7



MOCAng Architecture

8



MOCAng Architecture

9

Commands

JVM

DB Connections

Java Libraries

Java-Based Caches

MOCA Engine

Clients MOCA Server Native Processes

JVM

C L

ibra

ries

C-B

ased

Cac

hes

JVM

C L

ibra

ries

C-B

ased

Cac

hes

JVM

C L

ibra

ries

C-B

ased

Cac

hes



Core Architecture -- what was changed

MOCA Parser and Execution Engine (srvlib)> Completely Rewritten in Java

Command file reader (mbuild)> Completely rewritten in Java

Network Communication Layer (mocaconmgr)> Delegated to HTTP and Jetty

Database Translation Layer (sqllib/dblib)> Has been Java-based for several releases> All db connections are pooled in the main server process

Logging and Tracing> Now using log4j

10



Implications

Some things that used to be fast in C are slower, due to interprocess communication> Tracing> Initiating commands> Executing SQL

Groovy and Java code is much faster> Method call vs JNI> Multithreaded vs Single

Local syntax commands are executed directly in Java> C libraries are only used to execute C commands

11



Side Effects

64/32-bit capability> C code can still be 32-bit, to avoid risk.> Java VM can run 64-bit, to increase scalability> JVM heap size can be quite large (many GB on server-class

hardware)

12



Performance Overhead - How Slow is Slow?

Two types of overhead should be considered> Calling SQL from C> Calling C components from C

Generally, SQL overhead is less than initiating C components> SQL execution involves an additional copy of the result data

over the native socket.> C component involves potentially many additional copies

13



SQL Performance Overhead

When calling SQL from C, one extra data copy must be made

Overhead varies with amount of data sent> Note: this test data was from a local database using a very fast

single-table SELECT statement.

14

Size (rows)

Overhead (ms)

Overhead (%)

0 0.646 265.82%

10 0.679 119.35%

100 1.039 32.78%

1000 1.57 5.64%0 250 500 750 1000

Overhead (ms) Overhead (%)



C Performance Overhead Explained

When a C component initiates another command, it talks to the MOCA server to do it

If that command invocation needs to execute C, it comes back around to the C process

15

MOCA Server Native ProcessCall C Function A

srvInitiate(...)

Call C Function B

sqlExec*

sqlExec Results

C Function B Results

srvInitiate(...) Results

C Function A Results



C Performance Overhead

Overhead varies with amount of data sent and depth of call stack

Test Case illustrates worst-case situation, but indicates a problem area

16

Overhead/10 (ms) Overhead/10 (%)Overhead/100 (ms) Overhead/100 (%)

Call Depth Rows Overhead (ms)

Overhead (%)

1 10 1.23 196.45%

2 10 1.969 295.39%

3 10 2.448 336.46%

1 100 4.184 134.06%

2 100 6.605 202.7%

3 100 9.418 299.24%



So What?

Despite appearances, those are not disastrous overheads

If a component is called only few times per day, a few milliseconds of overhead is not a huge problem.

However, when a component gets called several thousand times per hour, it becomes an issue.

Look For> Commands that get run a lot in day-to-day operations> Commands that expect to operate on larger data sets> Commands that initiate a lot of other commands

17


Documents

An Introduction to the MOCAng Architecture