sdayal / brutis Goto Github PK

Now we only have a metric: op/s or transaction/s.
How about the latency of the operations which means SLA ...

What steps will reproduce the problem?
1.Run brutis very simply against a non-memcache IP (./brutis -x 1.1.1.1 -v)

What is the expected output? What do you see instead?
You would expect to see all failures, yet the output seems to imply that gets 
are succeeding.

What version of the product are you using? On what operating system?
.93

Please provide any additional information below.
Attached screenshot of output when using above command.

What steps will reproduce the problem?
1. ./brutis -p Big -P -r 1:0 -a s:r -n 75000 -s 100 -x $server -v -f 1  -k
1000000
2. ./brutis -p Big -P -r 0:1 -a s:r -t 60 -s 100 -x $server -v -f 40 -m 100
-k 1000000 -c localhost -o output.txt
3.

What is the expected output? What do you see instead?

output.txt should contain:

1251950725.5624:0:0.000000:0:0.000000:0:0:0:0:0:0:0:0
END


Total Operations:        5707600
Total Sets:                0
Total Gets:          5707600
Total Hits:           429200
Total Misses:            5278400
Total Set Fails:               0
Total MD5 Fails:               0
Total Keys:                0
Total Transferred:      42920000

What is output is everything upto "END"

What version of the product are you using? On what operating system?

v0.91. Centos 5.4

Please provide any additional information below.

I have created a work around locally.

I find that you calculate the latency in collector using 
$set_latency = round((($totals['set_latency'] / $clients) / $elapsed_time), 2);
but I think we should use to get the average latecy.
$set_latency = round(($totals['set_latency']/$totals['total_sets']), 6);

What steps will reproduce the problem?
1.Run brutis without the '-v' flag and kill it with ctrl-c.  Notice that 
the 'collector' process is still running.
2.Alternately, run brutis with the '-v' flag and kill it immediately before 
it outputs "Starting the collector".  Notice that the collector is still 
running.

What is the expected output? What do you see instead?
You would expect that killing the main thread would kill all the processes 
underneath.  This doesn't seem to be the case.

What version of the product are you using? On what operating system?
.93

Please provide any additional information below.
It's rather unpleasant since I frequently forget the '-v' flag and want to 
kill and re-run the program.  It won't let me re-run until I manually kill 
the collector

As you see, S:G=0:1 & pattern = R:S 
I think the hits should be less than gets  
#timestamp  sets    gets    hits    misses  set_fails   md5_fails
    operations  transferred size
1240298311  0   5507    49018   6052    0   0   5507
    12548608    mixed
1240298313  0   57826   514702  63558   0   0   57826
    131763712   mixed
1240298315  0   55622   495266  60954   0   0   55622
    126788096   mixed
1240298317  0   55353   492682  60848   0   0   55353
    126126592   mixed
1240298319  0   56125   499210  62040   0   0   56125
    127797760   mixed
1240298321  0   55985   498207  61643   0   0   55985
    127540992   mixed
1240298323  0   56438   502238  62142   0   0   56438
    128572928   mixed

Create command line option to set level of compression.

The limit of 50 forks per client can be too low for some systems.. Raise
limit to 512 forks maximum.

Feature request from mingfan.lu

Display & save a summary of the test on test completion.


Example:

Test summary
---------------------------------------------------------
Elapsed time: 0000

Operations:
 Gets: 00000 /sec
 Sets: 00000 /sec
 Transferred: 0000MB /sec

Transactions:
 Hits:   00000 /sec
 Misses: 00000 /sec
 Fails:  00000 /sec

valid_host() rejects ip addresses.