# A New Dynamic Game-Based Pricing Model for Cloud Environment
## 5 Experimental Results: Performance Evaluation of the Proposed Method  
The performance of the suggested pricing model has been assessed by comparing it to the approaches presented by [PERSON] et al. (2016) and [PERSON] et al. (2019). These two past works have been chosen as competitors due to their proximity in assumptions and goals. The proposed method in [PERSON] et al. (2016) seeks to increase the efficiency of cloud resources to guarantee the profit of the cloud provider in this way. At the same time, by reducing the price for customers whose requests for the cloud can easily be met, it also seeks to satisfy the user. In the method that has been suggested, users whose requests are not easily met will experience an increase in price. In this work, the relationship between supply and demand in the market has been considered. However, the impact of energy consumption on the price has not been taken into account in comparison to the suggested approach. The method presented in [PERSON] et al. (2019) seeks to increase the profit of the cloud provider by increasing resourceefficiency and reducing energy consumption. In this work, energy consumption has been considered an important factor in the current costs of the cloud. The method presented in this article only considers the problem from the point of view of the cloud provider and does not take into account user satisfaction, the relationship between supply and demand, and the effect of price on it, as well as the chance of success in executing a request.  
The proposed model was implemented using the NetBeans integrated development environment and the CloudSim 4.0 simulator [40]. In the simulation, the cloud provider has several physical machines with various hardware characteristics. One hundred user requests have been considered to be submitted to the system through the simulation period. The implementation parameters are considered the same as shown in Table 1.  
Each physical machine is a powerful server that consists of several computing elements. Therefore, multiple virtual machines can be assigned to one physical machine simultaneously. Physical machines are seen as diverse and therefore possess varying resource attributes, as illustrated in Table 1. The resource broker, which is in charge of constructing the game tree and resolving it, possesses comprehensive knowledge regarding the physical machines and their attributes. Furthermore, the broker maintains a continuously updated inventory of the resources accessible on each physical machine. Having such information helps the broker determine all the candidate virtual machines. An example of a user's request is shown in Table 2. During the simulation period, it is important to mention that none of the 100 user requests under consideration should be submitted to the system. A number of the requests that are submitted to the system follow a simple linear supply-and-demand model.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Value** & **Definition** & **Parameter (Symbol)** \\ \hline
1 & Number of Cloud providers & \(num_{providers}\) \\ \hline
100 & Number of Users’ requests & \(num_{users}\) \\ \hline
5 & Number of physical machines & \(num_{Hosts}\) \\ \hline
1 & Number of requests each & \(num_{requests}\) \\  & user submits & \\ \hline High Speed = 0.5 & & \\ Medium Speed = 0.3 & Resource quality coefficient for & \(rq\) \\ Low speed = 0.1 & various machine categories & \\ \hline
8 \(\sim\) 128 GB & The physical machine’s RAM & \(RAM\) \\ \hline
16 \(\sim\) 256 & Number of processing elements & \(CPU\) \\ \hline USD 10 & & \\ (per one simulation time unit) & Price for each processing element & \(Price_{CPU}\) \\ \hline USD 10 & & \\ (per one simulation time unit) & Price for each 256 MB RAM & \(Price_{RAM}\) \\ \hline
50 Time slot & Simulation run time & \(Time\_Slot\) \\ \hline
70 \(\sim\) 300 W &
\begin{tabular}{c} The power consumption rate of \\ the physical machine \\ \end{tabular} & \(Power_{PM}\) \\ \hline \hline \end{tabular}
\end{table}
Table 1: Implementation Parameters.