Author: ctang1

This week, I primarily finished outlining our testing suite so that Nakul can take over making JMeter testing scripts to pass into BlazeMeter. After taking care of the user side of testing, I also started to introduce variables to the VMs we are using for our video servers in order to create different use cases to compare our algorithms on. The VMs can be varied in two different ways: the region they are located in and their specifications such as storage, number of CPUs, and networking bandwidth. As such, I created 4 classes of video servers on AWS and deployed our video server code to them: same region + same specs, same region + different specs, different region + same specs, and different region + different specs. Each algorithm would be tested on all 4 server classes in order to draw meaningful conclusions on how the algorithms perform in different use cases. For example, we predict that our algorithms will perform similarly to RoundRobin when the region and specs of the VMs are similar, but our algorithms will pull ahead when the servers are more varied. In addition to this, I also deployed the code to our custom load balancers to AWS as well.

Next week, I plan on continuing to deploy code on AWS instances as our algorithms evolve. I will also work with Nakul to conduct tests on our algorithms and analyze the data that we gather.

This week, I primarily worked on creating a user testing suite that is suitable for sending realistic requests to our load balancer. Our previous approach of writing python scripts that send specific requests to our servers does not quite match the use case of our video application. We rely on the HTML5 video player element to load the video and request the next chunks accordingly, and simply making video chunk requests at set intervals does not simulate this behavior, especially since different videos will request different numbers of chunks in a certain interval. Therefore, another approach is required to generate load to our servers.

After asking Professor Eppinger for some tips on load testing tools, I was directed to Selenium as a way to script and simulate user actions in a browser. On top of this, I also found third-party tools such as dotcom-monitor, flood.io, and BlazeMeter that run said scripts on multiple machines and compile user data. However, after learning more and experimenting with the technology, I’ve found that while Selenium is excellent at locating and testing for HTML elements, it does not actually keep track of outgoing requests, incoming responses, and the corresponding data. I would need to pivot to another framework to properly simulate those requests.

Thankfully, while working with Selenium, I also noticed another tool called JMeter that deals more with HTML request/response scripts. Initially, I attempted to convert a Selenium script to a JMeter one using a Taurus proxy server tool. However, the resulting JMeter script did not run properly on BlazeMeter. Therefore, I am currently working on creating a JMeter script using the JMeter Proxy.

This week, I primarily worked on upgrading our implementation of the video server to make it more suitable for our testing environment. In the previous week, when I changed the server so that it started retrieving the video from an S3 bucket instead of local files, it lost the functionality of being able to retrieve the video in chunks instead of retrieving the entire video. I attempted to solve this problem by querying the video size from the S3 bucket, but it seemed like the video server lacked the permissions to properly query that information. Therefore, since the scalability of being able to query the video size isn’t important to the functionality of the video server in the context of the testing environment, I decided to instead hardcode the video size of the video into the code.

Another way I upgraded the application was by adding a catalog so that users can select multiple videos to play instead of just one. This means that the load on the load balancer can now be greatly varied by requesting videos of different types. A 360p video that is mostly static would not need many requests to fully load, whereas a 1080p video that features an action scene would send many requests to the server. This will make the testing environment much more robust and realistic.

Next week, after the testing environment has been set up, I plan on helping with implementing our own custom load balancing algorithm as well as taking the data that is collected from our user scripts and compiling it in a coherent manner.

This week, we mainly continued to develop and finalize our testing environment for the custom load balancer. First, we made our application more robust and appropriate for load balancing testing by implementing the delivery of the video in chunks. Furthermore, we also added a catalog of videos for users to choose from instead of just one so that the load to the server would be more varied.

As for user testing, we developed user scripts that continuously send video requests to the load balancer and logs metrics such as user response time and bit rate. We plan on deploying these scripts to AWS instances when running tests for our server.

Finally, we managed to obtain the two metrics from the video servers we intend on using, namely CPU utilization and server response time. With the CPU utilization metric, we implemented the load balancing algorithm that forwards requests to the server with the lowest CPU utilization, and next week, we plan on using server response time for our own custom load balancing algorithms.

This week, I primarily worked on deploying both the video server and load balancer on Amazon ec2 instances using AWS’s CodeDeploy module. The process was quite different from how I had previously deployed code on virtual machines, involving setting up configuration files and scripts in order to deploy code across multiple servers. However, after gaining some familiarity with the module with the first code deployment, I will now be able to use it to mass deploy code across multiple instances which will be helpful further on in the project as we update our implementation and also scale up operations to accommodate more load.

I also created an AWS S3 bucket to fetch our video files from which is already being used in our current implementation of the video server. Using the S3 bucket does currently remove scrubbing and returning the video in chunks from our application which could be a potential problem when load balancing incoming requests. Therefore, I am currently working on returning this functionality to the video servers while using S3.

This coming week, I will be working on obtaining the metrics that will be used for our custom load balancing algorithm: mainly CPU utilization and response time so we can also set up the monitor node. I may try to use Amazon’s own load balancers to gain insight into how these metrics can be obtained.

This week, we primarily continued our respective programming roles for the application. We successfully implemented a simple video streaming web application that works while locally deployed as well as began deployment of this application on AWS instances. While discussing our architecture, we decided to combine our backend and database server nodes due to the simplicity of our application. This will reduce some unnecessary complexity in our implementation as well as deployment costs.

Over the next week, we will begin implementing the backend/database nodes with MongoDB, supporting our front end with websockets, implementing our load balancer to fit into the server architecture, and simulating users using scripts running on additional instances

This week, with the basic front-end application implementation from Nakul, I was able to deploy the code and get it working on a few EC2 instances on AWS in our server architecture. I tested the functionality of the code that was deployed using my own browser, but in the coming weeks, I will work on implementing scripts in order to simulate users instead of having to manually test connections. Additionally, aside from the one video that the front-end video application currently uses, I also plan on finding additional videos from Youtube that our application will service in order to create a larger variety in load.

Another thing that was brought up to me by Mitul was condensing the back end and database server tiers into one comprehensive database access tier. After this suggestion, I looked into how to combine these instances in AWS and rework our architecture a little to accommodate this change.

In the coming week, I will continue to deploy any changes in code with our application as well as implement a monitor node to keep track of relevant metrics fro our project.

Over the past two weeks, on top of discussing the transition from Tornado to NodeJS for the implementation of our web application with the team, I mainly began to explore how we would be using AWS to service our application when we have achieved our basic implementation.

I did some research and found some tutorials in both website and video form on how to implement a multi-tier architecture on AWS, including what instances to use for different purposes. After setting up some basic connections between instances in the architecture, I started to send some test requests through these connections to check that they are functioning properly. While experimenting with the load balancer that AWS provides, I gained some insight into how it connects with the rest of the architecture and which values it monitors. I will be communicating these insights with Mitul to help with his implementation of our own load balancer.

In the coming week, I will be looking into how to set up a monitor node that receives and parses data from both the front end and the back end in order to gain a more comprehensive perspective on the performance of our load balancer.

While waiting to receive our AWS credits this week, I spent most of my time researching alternatives to Django as the web framework we would use for our web application since while the simplicity of Django allows for easier and rapid development, it is not as suitable for supporting long-lived connections such as a video stream since it is not asynchronous. Some alternatives to Django that I found include Nginx, Node.js, and Tornado. In particular, Tornado, while not having nearly as many powerful and robust abstractions as Django, can support many open connections that make it ideal for applications that require long-lived connections such as the video application we plan on implementing.

Since we received our requested AWS credits on Friday. This coming week I will start setting up test connections on AWS while also hashing out the details for the design review due on Wednesday. Then, over spring break, I will be setting up the backend of the web application in order to begin testing on our load balancer.

This week, I mainly performed research in order to work on the design presentation. Although I have a good idea of the general layout of the project, needing to quantify it with metrics and diagrams really solidified my understanding of the requirements our project is supposed to meet as well as how different parts of the project interact with each other.

One of the important things I researched was the basic benchmarks we want our web application to meet with the server architecture we are implementing. This includes bit rate, lag ratio, buffer fill, user latency, load balancer latency, and CPU usage. I looked into some industry standards for video streaming applications to determine our baseline bit rate, lag ratio, and buffer fill. Additionally, I also found common load balancer performance benchmarks that determine our ideal load balancer latency and CPU usage. Of course, the performance of the load balancer would vary with different algorithms, but we would like each algorithm to meet these loose benchmarks at the very least before comparing between them.

Another aspect of the design that I worked on was improving the specificity of our server architecture. We had a rough draft of the diagram of the architecture before and where our load balancer would fit in it but it required more refinement. Fleshing out this diagram in the design presentation helped us gain a better understanding of where to send requests to and receive responses from for each node in the architecture as well as determine where to obtain parameters necessary for the decision making of the load balancer.

Finally, I also had to find a way to obtain suitable videos for our web application without violating any copyright laws. I found that there’s a category of videos on Youtube with the Creative Commons license that allows for republishing the videos without the risk of copyright claims. We will be using these videos from Youtube, particularly ones that are 1080p and at 60 fps to produce a significant load for our server.

Once we obtain our AWS credit next week, I will be working on implementing the basic server architecture on AWS with the load balancer they provide just to check if the connections all work.