BukManiac/Scaling on multiple servers

CS290F Fall 2006 - UCSB Computer Science - Thorsten von Eicken

---

Contents 1 Why scaling to Multiple Servers? 2 Multiple Server Setup 3 Results 3.1 Reply Rate 3.2 Response Time 3.3 Conclusion

Why scaling to Multiple Servers?

We observed that the performace was limited when scaling on a Single server - max 20 replies/sec. So, our next step was to shift our deployment setup to Multiple servers , where a web server would act as Load balancer and forward the user requests to one of Application server. Also, we would be using a separate EC2 instance for storing the Database.
Note : We tested the following setup with > 250k records.

Multiple Server Setup

We have scaled the application servers up to 10 servers for Project 4.
The setup is shared database.

• One Web Server: We have one server running the Apache reverse proxy that forwards requests to the Rails Apps servers
  
• One or more App servers: One or more identical application servers running Ruby code. These servers have 4 instances of mongrel server running on four different ports on the app server (Ports 8000-8003). These mongrel instances forward the requests recieved from Apache reverse proxy to the Ruby engine. The Ruby instances make connections into the database server.
  
• One Database server: The shared database is hosted in this server. The ruby engines access the database in this server. Our books table has approximately 107,976 records right now. The orders and orderlines tables both have ~50,000 records (at the end of tests)
  

Results

Reply Rate

The graph shows the effect of adding multiple application servers to the reply rate. More replies are handled per second by the site when we add multiple application servers. The increase is linear with the number of application servers

Response Time

The graph show the effect of adding multiple application servers to the response time. When there are large number of app servers, the response time is fairly small. It increases linearly with the number of users hitting the website. When we have a small number of app servers, we see the response time is fairly large. It means slow response to the end user. The user might hit refresh button again and again, further increasing the load on the already loaded app server.

Conclusion

The Reply Rate scales quite linearly with the number of application servers for a realistic load on the system. We did not observe any particular bottlenecks in the database even with 270,000 records.

The response time is quite reasoable with multiple application servers. Bad response time is observed with 1 and 2 application servers at high loads. This is an expected behavior.