Streaming with multiple tasks

[nathantypanski]

This implements streaming and multiple response tasks. Caching is not yet implemented. Solution for #4, #6.

The number of tasks is customizable at the CLI, e.g.:

±[●●●][streaming] ps3$ ./zhtta --tasks 6
Using 6 max response tasks.
Zhtta Version 0.5 listening on 127.0.0.1:4414 (serving from: www).

The debug messages aren't perfect when the server is idle, but it doesn't consume CPU resources during idle time. The following is shown at debug, even during idle:

New task started! 1 tasks are running.
New task started! 2 tasks are running.
New task started! 3 tasks are running.
New task started! 4 tasks are running.
New task started! 5 tasks are running.
New task started! 6 tasks are running.

Here is the benchmark, mentioned in #6 as reason for reverting the old caching/streaming code:

±[●●●][streaming] ps3$ tr "\n" "\0" < zhtta-test.txt > zhtta-test-NUL.txt
±[●●●][streaming] ps3$ httperf --server localhost --port 4414 --num-conns 100 --wlog=y,./zhtta-test-NUL.txt

httperf --client=0/1 --server=localhost --port=4414 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=1
Maximum connect burst length: 1

Total: connections 100 requests 100 replies 100 test-duration 8.190 s

Connection rate: 12.2 conn/s (81.9 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.3 avg 81.9 max 665.7 median 99.5 stddev 100.2
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 12.2 req/s (81.9 ms/req)
Request size [B]: 68.0

Reply rate [replies/s]: min 13.2 avg 13.2 max 13.2 stddev 0.0 (1 samples)
Reply time [ms]: response 61.3 transfer 20.6
Reply size [B]: header 53.0 content 19076986.0 footer 0.0 (total 19077039.0)
Reply status: 1xx=0 2xx=84 3xx=0 4xx=16 5xx=0

CPU time [s]: user 2.15 system 6.05 (user 26.3% system 73.8% total 100.1%)
Net I/O: 227459.6 KB/s (1863.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

There are some 404s, which I guess we'll need to look into, but it is otherwise very fast.

Debug messages during benchmark show the threaded execution:

Requested path: [/home/nathan/devel/rust/cs4414/ps3/www/80M.bin]
Requested path: [./80M.bin]
===== Static Page request =====
Waiting for queue mutex lock.
Got queue mutex lock.
A new request enqueued, now the length of queue is 1.
A new request dequeued, now the length of queue is 0.
Spawning static file transfer task.
=====Terminated connection from [127.0.0.1:49036].=====
Starting to read a file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
5 tasks are running.
New task started! 5 tasks are running.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
5 tasks are running.
New task started! 5 tasks are running.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Read 5242880 bytes from file.
Request:
GET /5K.bin HTTP/1.1
User-Agent: httperf/0.9.0
Host: localhost

Hopefully this makes up for my deadlocking cache code from earlier ;)

[Robert-Emerson]

For the 404 errors, check to see if you have index.htm in your www directory.

[nathantypanski]

Ah, didn't have it. That makes sense.

By the way, you got to this quickly - before I could include count the response tasks properly based on cli arg. The bug is pretty minor, but it's probably worth fixing so the debug messages make sense.

I could send a new pull request if you prefer or whatever, but it's a pretty simple fix.

[Robert-Emerson]

I'll fix that as soon as I get home and just commit it then. Haven't had a chance to run it yet, but it looks good.

[nathantypanski]

I resolved it in #17, since the fixups were a tad less trivial than I thought.