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