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

More documents

Recommendations

Info

102 CHAPTER 5. BENCHMARKING OF EVENT-BASED SYSTEMS 16 GB of main memory. The server was run in a 64-bit JRockit 1.5 JVM using 8 GByte of heap space. A RAID 0 disk array comprised of four disk drives was used for maximum performance. The WebLogic JMS Server was configured to keep persistent messages in a file-based store on the disk array and to use a 3.8 GByte message buffer to store message bodies in memory. The SPECjms2007 controller and satellite drivers were distributed across five machines, four one-way dual-core Opteron at 2.4 GHz and one four-way dual-core Intel Xeon at 3.5 GHz. All machines were connected to a 1 Gbit network. To further increase the network capacity, a separate Gbit link was installed between the server and the four-way driver machine. The latter was configured to always use this link when accessing the server. The satellite drivers were distributed across the machines in such a way that the network traffic was load-balanced between the two networks. 5.2.2 Horizontal and Vertical Scaling We first ran some experiments in the horizontal and vertical topologies in order to show the behavior of the server when scaling the workload in the two alternative ways 4 . Figure 5.20 shows the server CPU utilization and the CPU processing time per message (counting both sent and received messages) for the horizontal topology. Figure 5.21 shows the same data for the vertical topology. In both cases, there is a clear linear correlation between the scaling factor (i.e., the BASE) and the server utilization. However, the server utilization grows much faster in the horizontal mode. For a given value of the scaling factor, the CPU consumption of the horizontal topology is between 2.2 and 2.3 times higher than the CPU consumption of the vertical topology. This is expected given that the number of messages injected per second in the horizontal topology is about two times higher than in the vertical topology (see the message traffic analysis in Sections 5.1.4). It is interesting to compare the average CPU time per message (counting both sent and received messages). The latter is about 10% lower for the horizontal topology. The reasons for this will become clear in the next section. CPU Utilization 100 80 60 40 20 0 CPU Time Per Message (ms) 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0 BASE (horizontal) BASE (horizontal) Figure 5.20: Measurement Results for Horizontal Experiments 5.2.3 Customized Vertical Workloads We now consider two customized workloads based on the vertical topology. The goal is to break down the workload into its P2P and pub/sub components and analyze the server performance when running them in isolation. To this end, the first workload runs only P2P interactions (i.e., 4 SPECjms2007 is a trademark of the Standard Performance Evaluation Corporation (SPEC). The results or findings in this chapter have not been reviewed or accepted by SPEC, therefore no comparison nor performance inference can be made against any published SPEC result. The official web site for SPECjms2007 is located at http://www.spec.org/osg/jms2007.
5.2. CASE STUDY I: SPECJMS2007 103 CPU Utilization 100 80 60 40 20 0 CPU Time Per Message (ms) 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0 BASE (Vertical) BASE (Vertical) Figure 5.21: Measurement Results for Vertical Experiments 100 12000 CPU Utilization 80 60 40 20 Messages Sent Per Sec 11000 10000 9000 8000 7000 6000 0 500 550 600 650 700 750 800 850 900 950 BASE (Customized Vertical) 5000 500 550 600 650 700 750 800 850 900 950 BASE (Customized Vertical) Messages Received Per Sec 12000 11000 10000 9000 8000 7000 6000 5000 500 550 600 650 700 750 800 850 900 950 BASE (Customized Vertical) CPU Time Per Message (ms) 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0 500 550 600 650 700 750 800 850 900 950 BASE (Customized Vertical) Figure 5.22: Measurement Results for Customized Vertical Experiments with P2P Messaging 1, 4 and 5), whereas the second one runs only pub/sub interactions (i.e., 3, 6 and 7) 5 . In both cases, the relative interaction mix for the considered interactions is the same as for the standard vertical topology. Figures 5.22 and 5.23 show the measurement results. We can see that, as expected, the pub/sub portion of the workload is by far much more light-weight than the P2P portion. This is due to two reasons. On the one hand, for a given value of the BASE, the P2P message traffic injected is much larger than the pub/sub traffic according to the definition of the vertical topology presented in Section 5.1.4. On the other hand, the server overhead per 5 Note that Interaction 2 is not part of these workloads since it contains a mix of both P2P and pub/sub messaging.
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: 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: 5.2. CASE STUDY I: SPECJMS2007 101
Page 119 and 120: 5.2. CASE STUDY I: SPECJMS2007 105
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

Create successful ePaper yourself

Delete template?

Save as template?