NetProg Spring 2004 HW5
  Project Description     |    Concurrency     |    Written Report     |    Deliverables     |    Grading

Homework 5: Forking and Threaded Server Performance Testing
Due Date: April 13th
Remote Due Date: April 20

Submit to WebCT drop box.

Late Penalty: 10%/day

HW5 can be done in C/C++ or Java

Project Description

Your assignment is to write an HTTP server that returns a document whose size is determined by the request URI. Your server will support 2 different for methods of providing concurrency, and you will do some performance measurements to determine whether there is a noticable difference between the two methods of concurrency.

The contents of the document returned by your server can be any HTML document you want, the size of the document is determined by the requested URI. Your server should strip the leading slash '/' from the URI and interpret the resulting string as a integer (in decimal) that indicates the size of the document to be sent to the client.

If the request line looks like this:

GET /1234 HTTP/1.0

Your server should send back a document that contains exactly 1,234 bytes of text. You should send back a valid HTML document, but the content of the document can be anything. The minimum size requested will be 100 bytes, this minimum means that you can always create a valid document (with HTML, HEAD and BODY tags). For example, the following document is 100 bytes long:

<HTML>
<HEAD>
<TITLE>100 bytes of fun</TITLE>
</HEAD>
<BODY> a a a a a a a a a a a a </BODY>
</HTML>

This document is 250 bytes long:

<HTML>
<HEAD>
<TITLE>250 bytes of fun</TITLE>
</HEAD>
<BODY> a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a </BODY>
</HTML>

Note that your server must send back an HTTP response line, a Content-Type header and a Content-Length header. None of these count towards the size of the document.

Your server should send back an HTTP response line that indicates an error if the requested URI is not a number or is less than 100.

Concurrency

The focus of this project is on the development and testing of a concurrent server. Your server must be capable of providing concurrency in 2 different ways, either a forking server (new child per request), or a pre-threaded server. A command line option is used to select the threaded server and the number of threads that should be created when the server initially starts.

The first command line argument is the port number that your server should bind to. This is the only command line argument required for the forking server (if only one command line argument is used, your server should be a forking server).

If a second command line argument is found, your server should treat this as the number of threads to be used for a pre-threaded server.

Usage:  hw5 portnum [num_threads]

./hw5 1234    starts forking server on port 1234

./hw5 3333 100  starts pre-threaded server on port 3333 with 100 threads

NOTE: On solaris.remote.cs.rpi.edu you are restricted to a total of 64 processes, this includes your login shell and any other processes you may be running. You need to include code that can handle the possibility that fork will return an error (don't simply keep trying to fork, make your server quit if it wants to fork and is not able to!).

Performance Report

Once your server is working, you must test your server and make some measurements of the two methods of concurrency for various request sizes and degrees of concurrency. You do not need to provide timing or statistics gathering code in your server, instead you will use a client that can make lots of requests and report on the results. The ApacheBench program is available for making measurements - this program can generate multiple HTTP requests to your server with any desired level of concurrency. The program executable is installed on the CS Suns as ~hollingd/public.html/netprog/ApacheBench/ab, there is a copy of the formatted man page in the same directory. Below is sample usage of the ab program to give you an idea of what it does. The test run below sends 100 requests to www.cs.rpi.edu for the URI ~hollingd/foo.html, sending 10 requests at a time (10 clients at a time).

> ab -n 100 -c 10 www.cs.rpi.edu/~hollingd/foo.html
This is ApacheBench, Version 1.1
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998 The Apache Group, http://www.apache.org/

Server Software:        Apache/1.3.4                                       
Server Hostname:        www.cs.rpi.edu
Server Port:            80

Document Path:          /~hollingd/foo.html
Document Length:        19 bytes

Concurency Level:       10
Time taken for tests:   1.823 seconds
Complete requests:      100
Failed requests:        0
Total transfered:       26400 bytes
HTML transfered:        1900 bytes
Requests per seconds:   54.85
Transfer rate:          14.48 kb/s

Connnection Times (ms)
           min   avg   max
Connect:     0     0     5
Total:     133   178   265

You must write a brief (1-2 pages) report that describes your tests, summarizes the results, and provides some insight into what the results mean.

Your report should focus on a comparison of the 2 concurrency modes supported by your server. The general idea is to determine which mode works best and by how much. The requests per second numbers reported by ab are probably the most useful for this comparison, the transfer rate and total time may also be useful. You should try various request sizes and levels of concurrency in your tests (what works best for small requests? is it different than what works best for large requests? , etc.) DO NOT SEND US THE OUTPUT GENERATED BY ab! You are to write a report that summarizes your findings and includes enough information so that we could reproduce your tests. Convince us that you have thought about which model of concurrency is best for various patterns (size/concurrency) of requests.


Deliverables

You must submit all the source code necessary for us to build your system. Your submission must also include a README that includes your name and a desciption of each file submitted (and anything else you want to tell us).

You must also submit your report as part of your submission. Your report must be a file that can be easily read on the CS workstations, so either text, HTML or PDF (no Word files!).


Grading

50% of your grade will depend on your server code (we will build and test your server), the other 50% depends on your report.