Search

This report reflects on the best way to implement a software component which defines the balancer module, that is a specific module meant to spread the traffic a web-platform receives over multiple back-end servers. In particular, the discussion will be centered on which load-balancing algorithm and tool is the best by the point of view of a high-demand throughput system in order to avoid the overload of some compute nodes, considering that many open-source load-balancers can be found in the market in a great variety of forms, implementations and features; the focus will be over the needs of a Demand Side Platform, where performances are put at first place and the internals of the platform itself change constantly (such as the number of servers and the addresses of the servers itself). This research will be conducted following best-practices in Software Engineering and Research field, with the purpose to aggregate the various learning contributions gathered during my Double Degree experience among Barcelona and Torino. First, a background over the topic is provided, with a glance to the RTB world and the main concept that this kind of system deploys and an insight over the internals of the balancer component by means of proxy models and load-balancing strategies. Second, a preliminary research over the main software solutions will be conducted, with the aim of filtering the ones that don't match the requirements provided by a professional tech company; the documentation supplied by each balancer will be analyzed with the objective to fill a software evaluation matrix, provided to highlight the various feature supplied by each balancer and to discard faulty solutions. Then, a testing environment will be built for every solution still under evaluation in order to effectively check that the component respects the declared features. Moreover, the testing environment is exploited to discover which is the best software product by means of overall performances, requirement considered crucial for a low-latency-high-throughput platform; the final goal of this step is to provide a winner to the software selection process that will be implemented in the final step by means of stressing the limit of the softwares under evaluation both by means of incoming total connections and requests per second. Finally, the ultimate candidate will be implemented inside the platform environment: it will be installed and configured over the Infrastructure as a Service that hosts the Demand Side Platform environment, mapping the agents described later in the discussion with the actual final component's configuration file. In conclusion, the final goal is to observe the effects that this analysis and the consequent implementation over the production environment metrics will cause, with the objective to improve the quality of service of the back-end by reducing the average response times from servers side and to show a possible decrease of the infrastructure costs.