Handout #5 - Project 4

• A lot of resources are available on-line and in the library. It is great to use these, but please always cite them in your projects.

Objective

In this project you will run your auction site on three front-end machines, all using the same database on bugatti (4th machine). We will load-balance incoming requests round-robin to your 3 servers. Provide the best performance you can, and make your service resilient to server and machine failures, i.e. we will kill your processes and/or halt the machines, yet your site should remain available.

Configuration

The test configuration for your service will be as follows:

Persistency

Your system must commit each new auction and each bid entered into the web site to persistent store, i.e. the database on bugatti, before returning the HTTP response. That is, if all three web servers failed simultaneously, all new auctions and bids for which a response was received before the crash must be stored in one form or another in the database.

Testing

We will provide the following test aids:

• roadrunner will run special networking software to perform round-robin load balancing across the three web servers (and to stop sending requests to a dead server)
• client - a C program that reads a list of auctions and bids from a file and issues them as fast as possible to the web servers
• a number of sample auction and bid sequences to test your servers

Benchmark scenarios

We will benchmark your system under the following conditions:

1. Random test: all 3 servers operational, 100 auctions, bidding with random distribution.
2. Auction test: all 3 servers operational, 1 auction, bidding for that single auction.
3. Failure test: same as random test, except that we will fail up to two web servers at a time, and then restart them.

Each of the benchmarks will have requests to display auctions and users in addition to the bidding requests. Probably around 4x to 10x as many display requests as bidding requests.

With each benchmark we will verify that all the auctions were performed correctly and we will measure the total time taken to execute the auctions.

Project write-up

The write-up should expand on the write-up of project 3. The write-up should contain the following sections:

• Project overview: description of the overall project (1 page max)
• Web Pages: description of each web page, specially its functionality (2 pages max)
• Database: structure of the database (tables, fields, etc), and types of locks/transactions used (1 page max)
• Servlets: list of servlets, beans, etc comprising the system with brief description of each (2 pages max)
• Distribution: describe how your system performs auctions on all three servers simultaneously, yet maintains consistency (3 pages max)
• Failure handling: describe how your system handles the failure of a server (2 pages max)
• Selected code: include the source code of your favorite servlet/bean/class that illustrates the coolest part of your system

Overall, keep it brief, and focus on the description of the distribution and failure handling.

Schedule

Wednesday March 13th, after class: we will perform an initial round of benchmarking. This will give you an initial idea of what to expect.

Wednesday March 20th: we will perform the real benchmarking. At this point your system must perform well on the 3 benchmarks.

Friday March 22nd: we will perform a catch-up round of benchmarking. Project write-ups are due by noon in the class homework box.