JADDOG

I’m subscribed to John Piper’s blog in my Google reader. Today Piper writes “Today is John Stott’s first birthday in Heaven”. Naturally I consulted Wikipedia to confirm. Look at that, I share a birthday with a man referenced in considering how to be “ambitious to live an unwasted life for the glory of Christ”.

Happy Birthday John Stott

I did a PreUpgrade to F17 from F16 two days ago.
I was having a few issues, sound hardware wasn’t listed in the gnome-control-panel, I could see the wireless access point in my house but couldn’t connect to it, I couldn’t mount my external backup hard drive and the laptop has cut off abruptly a few times to the point of having to pull out the battery before being able to boot it again.

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.

Apparently I never announced the release of Nushus 0.13.0 back in august and never released 0.14.0.
Then I got a new job and I’ve not looked at Nushus for a while.

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.

yesterday I blogged about nginx, tornado and http_load
I finished the day running seige and wanted to share my results.

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 don’t have much experience with any of these three, this is me just fiddling with them, not trying to run any kind of official test.

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.

For those of you running a rhev 3.0 cluster. I just learned of the webadmin the other day. I use my cluster for testing so I don’t have very complicated needs. Turns out you can do most of the CRUD operations on VMs via the webadmin, no IE nessesary.

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.

I setup a couple VMs over the past day or two on my desktop machine I recently built. Had to use this MacVTap thing and I really like it.

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

A screencast I created  has landed on youtube. It demonstrates using audrey to launch a multi-instance deployment in EC2 using the Aeolus Project.

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

On my way to work this morning my car’s check engine light came on. This is not an uncommon event, my car eats batteries and when the battery starts to fail and the car has trouble starting the light will come on. A few days later it generally clears itself. The couple times that the light has not cleared itself I have actually had to take it in to have it looked at.

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)

I was working on updating some unit tests today at work and was wondering if there was a way to measure the unit test coverage on a set of code. A single google search returned the ability for you to tell the exact test coverage your unit tests achieve and the exact lines of code that are not included in your coverage.

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.