Happy Birthday John Stott

I found this bug https://bugzilla.redhat.com/show_bug.cgi?id=746470 and ran the `authconf –update –nostart` command in it and deleted the ~/.pulse directory. This fixed the sound and external hard drive issues. I’ll have to see if it fixes the other issues too.

https://fedorahosted.org/nushus
Release Notes: https://fedorahosted.org/nushus/wiki/Release

So 0.14.0 is uploaded.
I think for 0.15. I’d like to make some changes in how the yum repos are structured to try and be more standard with how other things release.

I got siege with yum install seige
This test was run on a Fedora 16 x86_64 RHEV VM.
Given 4G of RAM and 4 sockets across 4 3Ghz i7 cores

nginx is running at http://localhost/
tornado is running at  http://localhost:8888/

I tested each server with both 50 and 500 concurrent users for a minute at a time.

# siege -d1 -t1M -c50 http://localhost/
Transactions: 5670 hits
Availability: 100.00 %
Elapsed time: 59.59 secs
Data transferred: 20.01 MB
Response time: 0.00 secs
Transaction rate: 95.15 trans/sec
Throughput: 0.34 MB/sec
Concurrency: 0.31
Successful transactions: 5670
Failed transactions: 0
Longest transaction: 0.35
Shortest transaction: 0.00

# siege -d1 -t1M -c50 http://localhost:8888/
Transactions: 5871 hits
Availability: 100.00 %
Elapsed time: 59.62 secs
Data transferred: 0.07 MB
Response time: 0.00 secs
Transaction rate: 98.47 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.44
Successful transactions: 5871
Failed transactions: 0
Longest transaction: 0.96
Shortest transaction: 0.00

# siege -d1 -t1M -c500 http://localhost/
Transactions: 49412 hits
Availability: 100.00 %
Elapsed time: 59.74 secs
Data transferred: 174.35 MB
Response time: 0.04 secs
Transaction rate: 827.12 trans/sec
Throughput: 2.92 MB/sec
Concurrency: 29.68
Successful transactions: 49412
Failed transactions: 0
Longest transaction: 21.14
Shortest transaction: 0.00

# siege -d1 -t1M -c500 http://localhost:8888/
Transactions: 42345 hits
Availability: 100.00 %
Elapsed time: 59.80 secs
Data transferred: 0.48 MB
Response time: 0.17 secs
Transaction rate: 708.11 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 121.91
Successful transactions: 42345
Failed transactions: 0
Longest transaction: 3.88
Shortest transaction: 0.00

I was initially confused by the concurrency metric, this is from the siege manual:

Concurrency is average number of simultaneous connections, a number which rises as server performance decreases.

So it seems the siege results are consistent with the http_load results.

I was intregued by this post:  http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

It’s a little old so I figured I’d glean a few things from it and recreate some of the tests, first one I came up with was comparing bench marks of nginx to tornado. I eventually want to compare Django, Rails, Flask and Sinatra. This is an initial attempt to get headed in that direction.

This test was run on a Fedora 16 x86_64 RHEV VM.
Given 4G of RAM and 4 sockets across 4 3Ghz i7 cores

Tornado is running the Hello World code on  http://www.tornadoweb.org/
Nginx is running with the default install settings.

# rpm -q python-tornado nginx
python-tornado-2.1.1-1.fc16.noarch
nginx-1.0.10-1.fc16.x86_64

pulled http_load from: http://acme.com/software/http_load/http_load-12mar2006.tar.gz

Requests to Tornado are calling http://localhost:8888/ and to Nginx are calling http://localhost/

I started with 1 second tests alternating rate and parallel

# ./http_load -rate 1000 -seconds 10 tornado
9999 fetches, 2 max parallel, 119988 bytes, in 10 seconds
12 mean bytes/connection
999.899 fetches/sec, 11998.8 bytes/sec
msecs/connect: 0.089374 mean, 0.263 max, 0.082 min
msecs/first-response: 0.355484 mean, 0.828 max, 0.268 min
HTTP response codes:
code 200 — 9999
# ./http_load -parallel 1000 -seconds 10 tornado
33616 fetches, 1000 max parallel, 403392 bytes, in 10.0002 seconds
12 mean bytes/connection
3361.53 fetches/sec, 40338.4 bytes/sec
msecs/connect: 161.429 mean, 7019.76 max, 0.067 min
msecs/first-response: 44.4849 mean, 2268.71 max, 2.328 min
HTTP response codes:
code 200 — 33616
# ./http_load -rate 1000 -seconds 10 nginx
9999 fetches, 22 max parallel, 3.69963e+07 bytes, in 10 seconds
3700 mean bytes/connection
999.899 fetches/sec, 3.69963e+06 bytes/sec
msecs/connect: 0.0977219 mean, 0.198 max, 0.082 min
msecs/first-response: 0.128703 mean, 21.869 max, 0.05 min
HTTP response codes:
code 200 — 9999
# ./http_load -parallel 1000 -seconds 10 nginx
94970 fetches, 70 max parallel, 3.51389e+08 bytes, in 10.0001 seconds
3700 mean bytes/connection
9496.95 fetches/sec, 3.51387e+07 bytes/sec
msecs/connect: 0.420914 mean, 3.828 max, 0.061 min
msecs/first-response: 1.05835 mean, 7.353 max, 0.683 min
HTTP response codes:
code 200 — 94970

Next I added more time

# ./http_load -rate 1000 -seconds 30 tornado
http://localhost:8888/: Cannot assign requested address (69 Times)
28967 fetches, 291 max parallel, 347604 bytes, in 30.0007 seconds
12 mean bytes/connection
965.545 fetches/sec, 11586.5 bytes/sec
msecs/connect: 2.30785 mean, 1001.45 max, 0.084 min
msecs/first-response: 1.37267 mean, 153.792 max, 0.25 min
HTTP response codes:
code 200 — 28967
# ./http_load -parallel 1000 -seconds 30 tornado
102504 fetches, 1000 max parallel, 1.23005e+06 bytes, in 30 seconds
12 mean bytes/connection
3416.8 fetches/sec, 41001.6 bytes/sec
msecs/connect: 225.68 mean, 15091.6 max, 0.064 min
msecs/first-response: 44.3875 mean, 4201.99 max, 2.804 min
HTTP response codes:
code 200 — 102504
# ./http_load -rate 1000 -seconds 30 nginx
29999 fetches, 18 max parallel, 1.10996e+08 bytes, in 30 seconds
3700 mean bytes/connection
999.966 fetches/sec, 3.69988e+06 bytes/sec
msecs/connect: 0.111561 mean, 0.295 max, 0.083 min
msecs/first-response: 0.108637 mean, 17.916 max, 0.049 min
HTTP response codes:
code 200 — 29999
# ./http_load -parallel 1000 -seconds 30 nginx
302900 fetches, 168 max parallel, 1.12073e+09 bytes, in 30 seconds
3700 mean bytes/connection
10096.7 fetches/sec, 3.73577e+07 bytes/sec
msecs/connect: 0.639248 mean, 1004.55 max, 0.061 min
msecs/first-response: 1.01887 mean, 204.58 max, 0.672 min
HTTP response codes:
code 200 — 302900

At this point it looks like Nginx is a bit faster in response, but both can handle an similar rate of requests. When firing parallel requests it looks like nginx is handling apx 3 time the number of requests. I you could specify workers in the conf file, but it was configured with 1 worker by default.

Out of the box http_load seems to indicate nginx being a little more robust container, I’d be interested to see some use cases that turn the tables on this fairly naive evaluation.

I hope to post more tests as I get time to build them.

1. yum install rhevm-webadmin-portal
2. service jbossas restart
3. https://rhevm.example.com:8443/webadmin

To get a console, install spice-client and spice-xpi too. This will enable the console button in the webui to open a spice terminal for you.

To do this I used virt-manager in Fedora 16. Initially virt manager didn’t give me an option to bridge the network interfaces, it was greyed out. I wanted to be able to ssh into these VMs inside my home network without having to go through the virt host. Turns out there’s an option to customize settings in the details panel just before you start the installation. Select it and bring up the VM’s detail panel to take advantage of MacVTap.

When the details panel comes up you can monkey with the networking of course. I selected the macvtap that my bare metal uses and set it to bridge mode.

Using this method both VM’s got a dhcp address from my home router and are able to talk to each other now.

Word of warning, don’t use VEPA mode. It’s something special that most router’s don’t haveyet that, from what I can gather, let’s the swtich do the bridging instead of the virt host.

Learned about this stuff here: http://virt.kernelnewbies.org/MacVTap

More info at
https://www.aeolusproject.org/
https://www.aeolusproject.org/audrey.html

This morning when it came on I suggested to my carpool buddy that I wished a built in feature of cars was to tell me why the light came on. Seems ridiculous to make me take it to someone to tell me what’s wrong with my car. Imagine if we had to take our computers to someone any time there was an error message in /var/log/messages. What a pain.

Ha! Take that car analogies of computers! I just made a computer analogy of cars!

I know you can buy those readers that will tell you the error codes. Although, my car is a VW that takes a non-standard reader and is more expensive than the common ones. Ah, German engineering.

(For my non-linux cohorts, /var/log/messages is the system log in linux)

Enter coverage.py: http://nedbatchelder.com/code/coverage/

I’m on fedora so $ yum install python-coverage installed it for me.
To get the details suggested above you need only run two commands.

~/git/audrey git:(oauth*)➤ coverage run audrey_start/test_audrey_startup.py
……………
Ran 15 tests in 2.601s

OK

The coverage run command executes your code just as if you had executed it without coverage.py, but has generated data about the code it’s executing as it’s running. You can see here I’ve executed this code’s unit test script. Next you display the report data:

~/git/audrey git:(oauth*)➤ coverage report audrey_start/*.py
Name                               Stmts   Miss  Cover
——————————————————
audrey_start/audrey_startup          472    270    43%
audrey_start/test_audrey_startup     217     19    91%
——————————————————
TOTAL                                689    289    58%

~/git/audrey git:(oauth*)➤ coverage report -m audrey_start/*.py
Name                               Stmts   Miss  Cover   Missing
—————————————————————-
audrey_start/audrey_startup          472    270    43%   126-132, 186-216, 237, 241-243, 247, 288, 352, 379, 382, 388, 414, 456, 544, 558-559, 585-601, 609, 630, 640, 654-689, 700-730, 739, 747, 774-794, 837-847, 854-857, 907-936, 955-957, 975-1125, 1139, 1151, 1190-1195, 1203-1229, 1264-1340, 1344
audrey_start/test_audrey_startup     217     19    91%   65, 130, 384, 420-428, 505-526
—————————————————————-
TOTAL                                689    289    58%

The coverage report command will give you the percentages missing for each script. The coverage report -m command will give you the exact lines missing from the unit test coverage. I checked a few of these lines that it reported, a quick check seems to indicate these are all actual lines of code that were not executed during the unit test run. Pretty useful data for measuring the effectiveness of your unit tests.