# Containerised Application Profiling and Classification Using Benchmarks
## 4 Profile Vector Creation  
Application profiling is essentially the creation of a multidimensional vector with each dimension representing a metric that regards the resource usage, and these dimensions are called features of the profile. We have  
\[\bar{V}=(V_{1},V_{2},V_{3},...,V_{m}).\]  
The application profile is presented in the equation above, where V\({}_{\text{m}}\) symbolises a specific feature of the profile. This features can be a simple metric such as network packets received or bytes written, or they can be complex metrics that require sample collection and computations in order to be computed. These kinds of features are Delta of CPU time, geometrical mean values, and other complex metrics. In order for a profile to have any value, it should be able to be classified and categorised based on the feature values. Features are required to have three attributes in order to be useful in the classification process  
1. Consistent values: Every feature computed by the extraction of hardware usage metric of a benchmark should produce relatively the same value (minimum deviation). This means that for every iteration of profile extraction for a specific benchmark and its workload the value of the feature should at least be in the same order of magnitude. 2. Value differentiation: Although the features should have the relatively same value for a specific benchmark and workload, they should also have different values for different sets of benchmark and workloads. In order for the classification algorithm to work properly and with high accuracy, it needs features that can differentiate one benchmark from another. Given that the algorithm used is random forest, this is taken care of by the algorithm itself. If the algorithm deems a feature unworthy because it  
Figure 3: Model trainer component internal processes flow. does not clearly indicate a differentiation, the binary tree that accesses this feature is discarded (as described in Section 5). 3. Hardware agnostic: If the features have the previous two attributes, they still need to be decoupled from the hardware configuration. Even if a feature has consistent values for a specific benchmark and workload, this consistency should also be kept with minimum deviation if the benchmark runs in a different hardware configuration. If the features do not have this attribute, the classification process would be only valuable and accurate if the application or benchmark are profiled in the exact same configuration, which reduces the goal of the research work performed. Taking under consideration all the attributes needed for the features, a preliminary selection process was conducted. It is important to mention that the features selected to represent the application or benchmark profile should also cover all the types of the typical resources an application can use. These resources are CPU, RAM, hard disk IO, and network. The GPU was not included because it was not feasible to obtain the resource usage in a container environment without the use of specific drivers that, even if they were installed would produce inconsistent results. Moreover, due to the fact that benchmarks can run for different periods of time depending on their type and that many features are time sensitive, in order to maintain consistency across this heterogeneity, profile metric extraction is performed for approximately 10 min for both benchmarks and applications. The initial population of features was 50 before they were narrowed down to 16. Before conducting a statistical analysis to select the best features, some of them were eliminated because they were flawed by design. For instance, CPU utilisation (or other features that represent other utilisation) is tightly coupled with the computation capacity of a given CPU, thus producing very different and inconsistent values if the same benchmark and workload was profiled in different hardware configurations.