Handout #6 - 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 stock trading 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).

Configuration

The test configuration for your service will be as follows:

Persistency

Your system must commit each trade 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 orders 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
• genload - a C program that reads a list of trades from a file and issues them as fast as possible to the web servers
• a number of sample trade sequences to test your servers

Benchmark scenarios

We will benchmark your system under the following conditions:

1. Random test: all 3 servers operational, 100 accounts, trading in dozens of stocks, random distribution.
2. Company test: all 3 servers operational, 100 accounts, trading in one stock only ("company announced results and investors are panicking").
3. Account test: all 3 servers operational, 1 account ("gone wild"), trading in dozens of stocks.
4. 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 for quotes in addition to the stock trading requests. Probably around 4x to 10x as many quote requests as trading requests.

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

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 trading 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

Thursday May 31st, after class: we will perform an initial round of benchmarking. This will give you an initial idea of what to expect.

Thursday June 7th, after class: we will perform the real benchmarking. At this point your system must perform well on the first 3 benchmarks (i.e. those without failure scenarios).

Tuesday June 12th, morning: we will perform a catch-up round of benchmarking, running the failure test on any systems that failed it during the 2nd round. Project write-ups are due by noon in the class homework box.

Neither Josep nor Thorsten will be around after June 12th, so that will be the final deadline!