SWE 622 Final Project Presentation – Team 1

SWE 622 Final Project Presentation – Team 1

Yanyan ZhuVirat Kadaru

Koji HashimotoStephanie Buchner

What we planned to do• Support both RMI and PToP communication

simultaneously during operation• Middleware component handles

communication• Application component handles application

logic• Flexible configuration• Testing over a VPN• Evaluation using AspectJ

Exchange

List of GoodsList of Traders

Project Design Overview

RMI

Send(async.)

Receive(callback)

List of OrdersList of Exchanges

SendingThread

ConnectionThread

Trader

Middleware

PToP

HeartbeatThread

ProcessingThread

ReceivingThread

ConnectionFailed(callback)

: rmi/p2p: msg

What we have done!Support both RMI and PToP communication

simultaneously during operationMiddleware component handles communicationApplication component handles application logicFlexible configurationTesting over a VPN

Problems with RMI and VPN PToP works perfectly over VPN

Evaluation using AspectJ

Configuration

• RMI – Pure RMI communication• Ex – Exchange Override• Tr – Trader Override• Mix – Mixed Config (Message Override)• PToP – Pure PToP communication• PToP-VPN – Pure PToP communication over

VPN

Report

• *Time taken to send orders and do other activities

• Roundtrip time• Latency & offsets (local)• Latency & offsets (remote)• Failure Detection time• Memory footprint

RMI Ex Tr Mix PToP PToP-VPN0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

265 218 194 266 234 276

747 757 753 781 725865

4102

4481 45334702

3675 3716

Roundtrip

Min_RoundTripAvg_RoundtripMax_Roundtrip

RMI Ex Tr Mix PToP PToP-VPN

-5

0

5

10

15

20

25

30

35

40

45

3

12 2

1 1

23

15

23

39

8 8

2

0

-1 -1

0 0

23

8 8 8 8 8

Latency & offsets (local)

avg_latencymax_latencyavg_offsetmax_offset

RMI Ex Tr Mix PToP PToP-VPN

-500

0

500

1000

1500

2000

2500

359 62 62

111 12415

179 195 195 234320

-1 -6 -10 -8

-370

17

18771963

1894 19261995 2003

Latency & Offsets (Remote)

avg_latencymax_latencyavg_offsetmax_offset

RMI Ex Tr Mix PToP PToP-VPN0

5000

10000

15000

20000

25000

16551156 1125 906 899 911

11748

6716 6693 6381

1246 1067

21873 22038 2215021658

16881195

Failure Detection

min_timeAvg_timemax_time

Memory Footprint Measurements

• How many Traders can an Exchange keep track of without running out of memory? – Size of NodeInfo object

• How many Order Echoes can a Trader store before running out of memory?– Size of Order object

Memory FootprintMethodology

1. Obtain estimate of object size. Use programs that measure object sizeObjectSizer from Java Practices -

http://www.javapractices.com/topic/TopicAction.do?Id=83Sizeof from Javaworld, Vladimir Roubtsov

http://www.javaworld.com/javaworld/javatips/jw-javatip130.html

2. Validate the estimate. Create objects until memory runs out. Calculate the size of the objects based on the number of objects created before OutOfMemory error occurs.

Program approach:• Run finalizers and gc• freeMemory = Runtime.totalMemory() – Runtime.freeMemory();• heap1 = freeMemory before creating objects;• Create n objects• heap2 = freeMemory after creating objects;• Create a number of objects• Size of object = (heap2 - heap1) / object count

Program differences:Different tactics to force garbage collection.

Memory FootprintMethodology cont’d

ObjectSizer gc approach: private static long getMemoryUse(){ putOutTheGarbage(); long totalMemory = Runtime.getRuntime().totalMemory(); putOutTheGarbage(); long freeMemory = Runtime.getRuntime().freeMemory(); return (totalMemory - freeMemory); } private static void putOutTheGarbage() { collectGarbage(); collectGarbage(); } private static void collectGarbage() { try {

System.gc(); Thread.currentThread().sleep(fSLEEP_INTERVAL); System.runFinalization(); Thread.currentThread().sleep(fSLEEP_INTERVAL);}

Memory FootprintMethodology cont’d

Sizeof gc approach: private static void runGC () throws Exception { // for whatever reason it helps to call Runtime.gc() // using several method calls: for (int r = 0; r < 4; ++ r) _runGC (); } private static void _runGC () throws Exception { long usedMem1 = usedMemory (), usedMem2 = Long.MAX_VALUE; for (int i = 0; (usedMem1 < usedMem2) && (i < 1000); ++ i) { s_runtime.runFinalization (); s_runtime.gc (); Thread.currentThread ().yield (); usedMem2 = usedMem1; usedMem1 = usedMemory (); } } private static long usedMemory () {

return s_runtime.totalMemory () - s_runtime.freeMemory (); }

Memory FootprintMethodology cont’d

Memory Footprint Estimate Object Size

• ObjectSizer results using different sample sizes:

• Sizeof results using different sample sizes:

Class Sample 10

Sample100

Sample1000

Sample10000

Averagebytes

Order Echo 137 122 120 119 124.5NodeInfo 139 122 121 120 125.5

Class Sample10

Sample100

Sample1000

Sample10000

Averagebytes

Order Echo 128 128 128 128 128

NodeInfo 128 128 128 127 127.75

Memory FootprintMemory Use Estimates

Estimated memory threshold:Total Memory - Base Heap Size / Estimated Size = Estimated Total Objects

Average Base Heap Size = 107,888 + 107,528 / 2 = 107,558

Estimated memory thresholds for Order Echo objects:• 524288000 – 107558 / 124.5 = 4,210,284 According to ObjectSizer• 524288000 – 107558 / 128 = 4,095,159 According to Sizeof

Estimated memory thresholds for Trader NodeInfo objects on the Exchange:

• 524288000 – 107558 / 125.50 = 4,176,736 According to ObjectSizer• 524288000 – 107558 / 127.75 = 4,103,173 According to Sizeof

Memory FootprintValidate Estimate

Approach:

• Measure the number of objects that can be created before getting an OutOfMemory error at a particular max heap size setting: 500 MB

• Set JVM max heap size to -Xmx500M • Create numbers of Order Echo and Trader NodeInfo objects, using the

estimates as a baseline.• Actual Object Size = Total Memory – Base Heap Size / Actual Total Objects

Results for Order Echoes on TraderExpected threshold = 4,095,159 - 4,210,284 Actual = 4,195,019

Actual size of Order Echo Objects:

524288000 – 107558 / 4,195,019

419501 = ~ 125 bytes

Memory FootprintValidate Estimate cont’d

Order Objects

ExpectedResults

Results

4,100,000 No Error No Error

4,200,000 Out of Memory Out of Memory

4,195,000 ? No Error

4,196,000 ? Out of Memory

… … …

4,195,015 ? No Error

4,195,020 ? Out of Memory

4,195,019 ? No Error

Memory FootprintValidate Estimate cont’d

Memory FootprintValidate Estimate cont’d

Results for Trader NodeInfo on ExchangeExpected threshold = 4,103,173 - 4,176,736 Actual = 4,195,520

Actual size of Order Echo Objects:

524288000 – 107558 / 4,195,020

419501 = ~ 125 bytes

Memory FootprintValidate Estimate cont’d

Order Objects

ExpectedResults

Results

4,100,000 No Error No Error

4,170,000 ? No Error

4,200,000 Out Of Memory Out Of Memory

4,190,000 Out Of Memory No Error

4,195,100 Out Of Memory Out Of Memory

… … …

4,195,021 ? Out Of Memory

4,195,020

Memory FootprintValidate Estimate cont’d

Memory FootprintValidate Estimate cont’d

Memory FootprintConclusions

• The Sizeof program gave a consistent and conservative estimate of the object size.

Actual Objects – Sizeof Estimate / Actual Objects = Margin of Error of Sizeof Est

4,195,519 - 4,095,159 = 100,360100,360 / 4,195,519 = +.024%

• Outstanding question: Why is Sizeof result larger than measured actual size? Issue with Sizeof gc approach, or measurment of actual results?

• ObjectSizer garbage collection approach issues:Inconsistent results indicate problems with gc approach. Calling gc before getting total and also before getting free memory is a the

problem.

Level of Effort

Activity Hours

Requirements 8

Design 21

Implementation 96

Testing 28

Evaluation 63

Presentation Prep 27

Total 243

Lines of code

2633 lines (not including the GUI)

Demo

Questions