Performance Modeling and Benchmarking of Event-Based ... - DVS

More documents

Recommendations

Info

108 CHAPTER 5. BENCHMARKING OF EVENT-BASED SYSTEMS CPU Utilization 100 80 60 40 20 0 0 20 40 60 80 100 120 140 160 # Consumers Messages per Sec 16000 14000 12000 10000 8000 6000 4000 2000 Mean Delivery Latency (ms) 16 14 12 10 0 0 20 40 60 80 100 120 140 160 8 6 4 2 # Consumers 0 0 20 40 60 80 100 120 140 160 Received Sent # Consumers Figure 5.27: Scenario 4: PTD Pub/Sub Messaging with Increasing Number of Consumers Scen. Int. # SMs # HQs Injection Rate Msg. Size Msg. Group Figure 1 5 variable variable unlimited 2 KByte c 5.29 2 4 variable na unlimited 2 KByte d 5.29 3 4 5 na unlimited variable d 5.30 Table 5.10: Configuration for P2P Scenarios type according to the classification in Table 5.3. Given that in both Interaction 4 and 5, each interaction execution results in sending a single message, the specified message injection rate is configured by setting the respective interaction rate. The interaction rate is specified on a per location basis. The analysis results for the three scenarios are presented in Figures 5.29 and 5.30. We now take a closer look at the results. The first two scenarios compare the performance of NPNT and PT P2P messaging (Figure 5.29). In both scenarios, the number of queues used is varied and the goal is to measure the maximum message traffic per second that can be processed. The first scenario uses Interaction 5 with multiple HQ instances each having its own queue for incoming statInfoSM messages sent by the SMs. In each test, both the number of HQ instances and the number of SMs are set to the desired number of queues. Thus, every SM has a HQ instance and a respective queue that receives its messages. SM agents have 5 producer (driver) threads each. HQ agents have 5 consumer threads each. In order to ensure that the number of producer and consumer threads remains constant, the number of agents per SM/HQ is set in such a way that the number of agents of each type does not change (Section 5.1.5). For example, in the test with 1 queue (1 SM and 1 HQ), there are 20 agents per SM/HQ, in the test with 2 queues, there are 10 agents per SM/HQ and so forth, in all cases leading to 20
5.2. CASE STUDY I: SPECJMS2007 109 CPU Utilization 100 80 60 40 20 Non-Persistent Persistent 0 0 20 40 60 80 100 120 140 160 # Consumers CPU Time Per Msg Sent (ms) 70 60 50 40 30 20 10 Messages Sent Per Sec 4500 4000 3500 3000 2500 2000 1500 1000 500 Non-Persistent Persistent 0 0 20 40 60 80 100 120 140 160 # Consumers Non-Persistent Persistent 0 0 20 40 60 80 100 120 140 160 # Consumers Figure 5.28: Scenario 5: NPNTND vs. PTD Pub/Sub Messaging agents in total. The second scenario is setup in exactly the same way with exception that it uses Interaction 4 and therefore only SM agents are involved. Each SM agent has 5 producer and 5 consumer threads. The two interactions are configured to use the same message size so that we can compare the results. As we can see in Figure 5.29, when moving from 1 queue to 2 queues, the message throughtput increases by about 5% for NPNT messaging and about 10% for PT messaging. Increasing the number of queues beyond 2, does not affect the message throughput, the server utilization or the CPU time per message/Kbyte. The server CPU utilization is slightly lower (6-10%) for PT messaging. The latter is expected given that persistent messaging involves disk I/O. The message throughput is about 2.5 times higher for NPNT messaging given that the CPU time used per message/KByte processed is over 2 times lower compared to PT messaging. Overall, the results show that using more than two queues does not lead to any noticable change in the system performance of our configuration. In the third scenario, we study the performance of PT P2P messaging with variable message size. We use Interaction 4 with a fixed number of SMs and 5 producer and 5 consumer threads per SM. The results are shown in Figure 5.30. As we can see, the CPU processing time per message increases linerarly with the message size whereas the CPU time per KByte quickly drops and stabilizes around 0.1ms per KByte. As we discussed earlier when evaluating pub/sub messaging, the reason for the drop in the overhead per KByte is that there is a constant overhead for parsing the message header which for small messages dominates the overall processing time. The mean delivery latency seems to increase quadratically with the message size.
Page 1:
Performance Modeling and Benchmarki
Page 4 and 5:
priorities. Finally, we validated o
Page 6 and 7:
4.3.4 Tool Extension . . . . . . .
Page 8 and 9:
5.7 Proportions of the Interactions
Page 11 and 12:
List of Acronyms Acronym λ t,k j A
Page 13 and 14:
Acronym SPEC-OSG SPE SPN SQL ST SUT
Page 15 and 16:
Chapter 1 Introduction 1.1 Motivati
Page 17 and 18:
PC Server 310 PC Server 310 PC Serv
Page 19 and 20:
1.3. APPROACH AND CONTRIBUTIONS OF
Page 21 and 22:
1.4. THESIS ORGANIZATION 7 • Stan
Page 23 and 24:
Chapter 2 Background In this chapte
Page 25 and 26:
2.1. EVENT-BASED SYSTEMS 11 is gene
Page 27 and 28:
2.2. TECHNOLOGY PLATFORMS OF EVENT-
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
2.3. INTRODUCTION TO QUEUEING PETRI
Page 37 and 38:
2.3. INTRODUCTION TO QUEUEING PETRI
Page 39 and 40:
Chapter 3 Related Work In this chap
Page 41 and 42:
3.2. BENCHMARKING OF EVENT-BASED SY
Page 43 and 44:
3.2. BENCHMARKING OF EVENT-BASED SY
Page 45 and 46:
3.4. CONCLUDING REMARKS 31 hierarch
Page 47 and 48:
Chapter 4 Performance Engineering o
Page 49 and 50:
4.1. MODELING METHODOLOGY FOR EBS 3
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
4.2. PERFORMANCE MODELING PATTERN 4
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72: 4.2. PERFORMANCE MODELING PATTERN 5
Page 87 and 88: 4.3. EXTENSIONS OF QPNS 73 ,-).$%&'
Page 89 and 90: 4.4. CONCLUDING REMARKS 75 Without
Page 91 and 92: Chapter 5 Benchmarking of Event-Bas
Page 93 and 94: 5.1. SPECJMS2007 - A STANDARD BENCH
Page 115 and 116: 5.2. CASE STUDY I: SPECJMS2007 101
Page 121: 5.2. CASE STUDY I: SPECJMS2007 107
Page 125 and 126: 5.3. JMS2009-PS - A PUBLISH /SUBSCR
Page 127 and 128: 5.3. JMS2009-PS - A PUBLISH /SUBSCR
Page 129 and 130: 5.4. CASE STUDY II: JMS2009-PS 115
Page 131 and 132: 5.4. CASE STUDY II: JMS2009-PS 117
Page 133 and 134: Chapter 6 Performance Modeling of E
Page 135 and 136: 6.2. MODELING SPECJMS2007 121 Scena
Page 137 and 138: 6.2. MODELING SPECJMS2007 123 BASE*
Page 139 and 140: 6.2. MODELING SPECJMS2007 125 1‘O
Page 141 and 142: 6.2. MODELING SPECJMS2007 127 Sc. 1
Page 143 and 144: 6.2. MODELING SPECJMS2007 129 Perce
Page 145 and 146: 6.2. MODELING SPECJMS2007 131 Serve
Page 147 and 148: 6.3. CONCLUDING REMARKS 133 the mod
Page 149 and 150: Chapter 7 Conclusions and Outlook W
Page 151 and 152: 7.1. ONGOING AND FUTURE WORK 137 JA
Page 153 and 154: 7.1. ONGOING AND FUTURE WORK 139 th
Page 155 and 156: Bibliography [1] J. Abbott, K. B. M
Page 157 and 158: BIBLIOGRAPHY 143 [29] BiCEP Researc
Page 159 and 160: BIBLIOGRAPHY 145 [61] G. Cugola and
Page 161 and 162: BIBLIOGRAPHY 147 [92] R. Henjes, M.
Page 163 and 164: BIBLIOGRAPHY 149 [128] S. Kounev an
Page 165 and 166: BIBLIOGRAPHY 151 [162] Object Compu
Page 167 and 168: BIBLIOGRAPHY 153 [197] K. Sachs, S.
Page 169 and 170: BIBLIOGRAPHY 155 [228] P. Tran, P.
Page 171: Erklärung Hiermit erkläre ich, di
show all

Performance Modeling and Benchmarking of Event-Based ... - DVS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?