Results

The focus of this page is to briefly demonstrate the performance of our proposed solution for a set of predefined use cases. We illustrate a possible outcome when a large peak of traffic is captured and the local infrastructure does not have a Cloud Bursting capable Load Balancer to handle the scheduling of jobs to avoid delays. We then compare the simplest version of our Load Balancer to the more advanced one, by running the predefined uses cases with both versions. We start by using synthetic traffic generated by Iperf with the simulation job to prove our concept and continue by analyzing real traffic with our signature matching job.

Peak without Load Balancer

We present the case where our local Hadoop cluster is processing a steady 12 Mbps stream and an unexpected peak of 58 Mpbs occurs during the capture time window started at tc+1. The brown portion of the jobs represent upload time, whereas the white portion represents execution time. We see from the figure and table above that without the Load Balancer, four jobs are delayed (including the job that processes the peak) because of the unexpected peak. Particularly, job four is delayed circa seven minutes. It becomes clear from this simple example that in order to avoid the possibility of delaying jobs, the need for a Cloud Bursting capable Load Balancer is evident.

Simple VS Advanced Load Balancer: Synthetic Traffic with the Simulation Job

The following set of tests are used to prove our Cloud Bursting capable Load Balancer concept. We conclude that our more advanced version is capable of bursting less jobs than our simpler version, maximizing local resource usage and minimizing job delays. While the number of bursts between simple and advanced version is the same in test cases four and five, notice that the advanced version is capable of bursting a shorter job in test case four, and avoids job delays unlike the simple version in test case five.

Test Case 1

Test Case 2

Test Case 3

Test Case 4

Test Case 5

Simple VS Advanced Load Balancer: Real Traffic with Signature Matching job

The following performance tests use the signature matching job on real traffic captured on our network labs' router. These tests were conducted with an upgraded network, where all links are GigabitEthernet. In addition, the number of worker nodes was reduced to four, allowing for a total of eight containers. We conclude that our solution performs as expected with real traffic and a real network analysis MapReduce job, and we show once again that our more advanced version outperforms our simpler version, bursting less jobs and maximizing local resource usage.