JADDOG

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