# Dynamic Cost-Aware Routing of Web Requests
## 7 Testbed Evaluation  
We have conducted experiments on CloudLab [6]. The topology consists of six servers of type 220g1 as shown in Figure 7. All servers are equipped with two Intel E5-2630 v3 8-core central processing units (CPUs) at 2.40 GHz (Haswell EM64T), 128 GB error-correcting code memory (ECC), a dual-port Intel X520-DA2 10 Gbps network interface card (NIC) and two 1.2 TB disks. All machines run Linux Ubuntu 16.04. Apache2 web server was installed on the nodes \(s1,s2,s3,s4\) to operate as origin servers. All of the nodes provide power monitoring capabilities. We have obtained the power usage of origin  
Figure 5: Impact of memory weight parameter \(\alpha\).  
Figure 6: Cost impact of the number of servers; per node hourly cost (**left**); system hourly cost (**right**).  
servers using the Intelligent Platform Management Interface Tool (_ipmitool_). Apache Traffic Server 7.1.2 was installed on the node _proxy_, which serves as a reverse proxy server between client and the origin servers. To emulate Internet (wide area network) delays, we introduced the following random artificial delays to the links connecting origin servers to proxy using Network Emulator (Netem): \(10.0\pm 2.0\), \(0\) (no delay), \(20.0\pm 5.0\), and \(5.0\pm 2.0\) ms, respectively.  
We implemented our method for web request routing (CA-S) as a policy function with the balancer plug-in of the traffic server. The LA implemented as the policy function will measure the delay in serving responses, read the power utilization of servers and compute the total cost after each transaction. It then updates the selection probabilities of the servers and selects a server at random for the next incoming request. An application \((tx\_power)\) written in C++ at each origin server queries the power usage from _ipmitool_ at one-second intervals and sends the power values in watts to both _proxy_ and the client node \(cl\) using \(PUB/SUB\) messaging service of ZeroMQ. An application written in C++ \((rx\_power)\) running on the _proxy_ node subscribes to all the origin nodes and receives the power values. It then writes these values into a memory shared with the traffic server. The PUB/SUB messages are transmitted out of band with the HTTP requests. A python application running from the client node \(cl\) sends HTTP requests for static files of various sizes to the origin servers via _proxy_ node in Poisson distribution. The requests are sent from 20 requests/s to 300 requests/s in steps of 20 requests/s. Each experiment runs for a duration of 10 min and was repeated several times. The service times and power utilization are recorded at the client node for plotting the results.  
The probabilities are updated after each transaction based on the performance of servers when each of them has been selected for a transaction. The server which serves the requests with the minimum combined cost will have the highest probability in the long run. The server having the highest probability will have the most number of chances to serve the requests. However, once its performance starts deteriorating, it will not hold the highest probability and the probability of the server having the next best performance starts increasing. As the LA used in this work possesses ergodic Markovian properties, it does not lock itself into any one server, and optimal performance could be achieved in spite of dynamic changes in the electricity prices and with the variations in response times. To better illustrate the roles of the raw electricity costs and revenue loss due to high response times, we have introduced an additional parameter \(k\) into the objective function: \(z(t)=kx(t)+(1-k)y(t)\)  
Figure 7: Experimental topology deployed in CloudLab.  
Depending on the value selected for \(k\), the modified goal function simulates the use of different electricity rates (keeping \(\gamma\) fixed) or different choices for \(\delta\).