# JSSTR: A Joint Server Selection and Traffic Routing Algorithm for the Software-Defined Data Center
## 6 Evaluation
### Simulation Setup  
JSSTR and two compared algorithms were implemented and evaluated. The first compared algorithm calculates the destination server and routing path sequentially. Due to the simple implementation, reliable running and high universality, now the Weighted Least-Connection (WLC) scheduling method becomes one of the most popular server load balancing strategies used on web servers (e.g., nginx, which has served 24 percent of web sites in the world) and cloud computing platforms (e.g., RackSpace cloud platform). Therefore, in the first compared algorithm, the WLC scheduling method was used to choose the destination server. At the same time, considering that GA has been widely used for calculating the routing path in data centers [34; 35; 36; 37], the GA-based routing method is also employed in that compared algorithm. Hence, that compared algorithm is called WLC-GA for short. Meanwhile, due to the fact that the joint server selection and traffic routing problem is NP-hard, a traversal-based server selection and traffic routing algorithm (Travs for short) is also implemented to solve that problem. It uses DFS to find all routing paths between the user and each server. Then, the server and corresponding routing path that have the minimum value according to Equation (1) will be chosen as the destination server and routing path. The proposed JSSTR algorithm and the compared algorithms-WLC-GA and Travs-were implemented on the RYU controller in the evaluation [38]. The RYU controller was running on a computer (ThinkServer RD640) with an Intel E5 2609 CPU (the CPU frequency was 2.4 GHz), 64 GB main memory and a 1-TB disk. Meanwhile, Ubuntu (14.04 LTS) was used as the operating system of that computer. Mininet was employed to generate the evaluation network. In the evaluation, Mininet was running on another computer (Lenovo H5050) with an Intel Core i3 4160 CPU (the CPU frequency was 3.6 GHz), 8 GB main memory and a 500-GB disk. That computer also used Ubuntu 14.04 LTS as its operation system. The description of the software used in this work is shown in Table 3.  
Due to the fact that the JellyFish topology is a high-capacity and cost-efficient topology, in this evaluation, the JellyFish topology was employed as the evaluation network topology [39]. Using Mininet, a JellyFish topology containing twenty switches, sixteen servers and two hundred users was created and used as the network topology. The bandwidths of links in that JellyFish topology were set as 10 Mb. All servers in that topology compose a server cluster. The Network Address Translation (NAT) technology was used and implemented as a module of the RYU controller. Using that NAT module, all those servers served all users with the same IP address (10.0.0.201 in this evaluation). All of these servers ran a simple http server application written in Python. According to the previous works, the arriving process of users is approximately a Poisson distribution [40]. Considering that the interval of the arriving time of the Poisson distribution obeys an exponential distribution, the intervals of these users' arriving times were exponentially distributed with the mean parameter set as 1939.12 ms in this evaluation [40]. Meanwhile, each user sent http get requests using the t-distribution as the distribution of inter-request time according to the previous work [41]. The mean, standard deviation and degree of freedom of that t-distribution were set as 1.938 s, 0.245 s and 2.086 according to [41]. For each request, the length of response was about 350K bytes. A program that was written in Python was used to simulate and monitor the load change of these servers. In this evaluation, three kinds of servers were simulated in that program, which were a high-end server (Server 1), mid-end servers (Server 2 and Server 3) and low-end servers (Servers 4-16). In the evaluation, the high-end servers were designed to be able to provide service for at most 30 users, while the mid-end and low-end servers were designed to be able to serve at most 20 and 10 users, respectively.