## 5 Evaluation
### Performance Evaluation Experimentation  
Firstly, we have found an interesting system effect; with the increase in buffer timeout, both the throughput and latency start to proportionately increase as well, thus proving that both throughput and latency are directly proportional to buffering timeout. This fact details that Flink operators first gather the records in their buffers, before passing them on to the next operator. By specifying the buffer timeout, we notify Flink's runtime to empty the buffer after the stated time even if it is not full. A lower buffer timeout usually means lower latency, although at the expense of throughput as shown in \begin{table}
\begin{tabular}{c c} \hline \hline
**Algorithm** & **Model Building Time (s)** \\ \hline Naive Bayes & 5.3 \\ Multilayer Perceptron & 21.9 \\ SMO & 10.3 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Algorithms model building time. Figure 12: Workload analysis algorithms: Naive Bayes, multilayer perceptron, and SMO comparisons based on correctly classified instances, incorrectly classified instances, Kappa statistic, mean absolute error, root mean squared error, relative absolute error, and root relative squared error. Figure 13. For time-sensitive cases like fraud detection in financial applications or IT security, response time is critical; latencies higher than 30 ms usually lead to late detection of the problem, which defies the purpose of such applications. The latency boundaries show that both latency and throughput are inversely proportional to one another. We require a system that analyzes the workload and develops a potential ideal trade-off of the two. The second group of tests reveals that window correctness (as with the increase of allowed lateness, the window correctness increases as well) alter the productivity of the application. This experiment is also done under the same EMR cluster configuration of three m3.xlarge instances of Amazon. The setup uses the streaming application to read parallel streams of events form Apache Kafka [23] and checks the validity of it, like token authentication, service interaction, and login authentication. We also design to push some false late elements (elements with timestamp \(t^{\prime}<=t\)) to prominence the window correctness problem, meaning that it is unrealistic to postulate a time through which all elements of a definite event timestamp should have happened, leading to late elements in the data stream to be picked up and process with the original data. We collect and analyze the average job execution time, with differing values of allowed lateness ranging from 0 to 30 as published in Table 3. The experiment shows that the window correctness of the results rises at the cost of total job execution time. Here the increase in the allowed lateness is consistent with the window correctness, i.e., as the allowed lateness increases, it increases the chances of the window to be correct and more accurate in its calculations. This is due to the effect that allowed lateness decreases the chances of elements for the specified window to be late, whereas the increase in the gap for the execution time is a result of an increased delay, causing the Kafka stream to heighten its queue time, altering the overall capabilities of our proposed system. In an effort to emphasize our definition of latency, another set of experiments shows the event time and processing time latencies under the condition when the system is extremely overloaded. For this set of experiments, we overloaded the system with high input and disabled the system capability  
Figure 13: Throughput-latency tradeoff using varying task manager’s buffer timeout values (adapted from [12]). \begin{table}
\begin{tabular}{c c} \hline \hline
**Allowed Lateness (s)** & **Job Execution Time (s)** \\ \hline
0 & 420 \\
5 & 435 \\
10 & 467 \\
20 & 533 \\
30 & 579 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Job execution time with the varying value of allowed lateness.