<commit_before># wrk-bench

`wrk-bench` is a library to make creating `wrk` jobs that recur immediately.
This is good for having tests that collect stats for a couple seconds, record
them, then does it again. This assumes you'll pipe the results into something
that makes sense.

## usage

Since this is just a light wrapper around `wrk` the node module, which is just a
light wrapper around `wrk` the command line tool. You'll just pass the options
that you'd normally pass to `wrk` to `wrk-bench` like so:

```javascript
var bench = require('wrk-bench')

var job = bench({
	url: 'http://localhost:3000',
	threads: 2,
    connections: 5,
	duration: '10s'
})

job.pipe(process.stdout)
```

Which might result in output that looks like the following:

```json
{
  "transferPerSec": "355.09KB",
  "requestsPerSec": 228.54,
  "requestsTotal": 2286,
  "durationActual": "10.00s",
  "transferTotal": "3.47MB",
  "latencyAvg": "17.62ms",
  "latencyStdev": "4.29ms",
  "latencyMax": "73.93ms",
  "latencyStdevPerc": 98.67,
  "rpsAvg": 115.89,
  "rpsStdev": 15.94,
  "rpsMax": 171,
  "rpsStdevPerc": 79.32,
  "options-threads": 2,
  "options-connections": 5,
  "options-duration": "10s",
  "options-url": "http://localhost:3000"
  "timestamp": 1413854725961
}
```

Notice how the options is merged into the object. This makes it so you don't
have to track each job yourself. Also if you add any other properties to the
option argument they will be merged in and if `wrk` doesn't know about them,
they wont be used. This is handy if you want to name jobs or add in any
interesting version data or something of that sort.

Also a timestamp of when the test finished is added to the object as well. I am
up for debate on this and could also see collecting start/end and reporting
them, or maybe not having a timestamp on at all and leaving that up to a user of
the API

## theoretical changes

* Possibly take an array of jobs
* Delay between jobs seems like a good idea but I don't have a use case yet.
* There are likely more settings in `wrk` that I'll want to expose.
* Standardize the output. So `KB`/`MB` values are always bytes. `ns`, `ms`, `s`,
  `m`, etc all changed to `ms`
<commit_msg>more readme updates<commit_after># wrk-bench

`wrk-bench` is a library to make creating `wrk` jobs that recur immediately.
This is good for having tests that collect stats for a couple seconds, record
them, then does it again. This assumes you'll pipe the results into something
that makes sense.

## usage

Since this is just a light wrapper around `wrk` the node module, which is just a
light wrapper around `wrk` the command line tool. You'll just pass the options
that you'd normally pass to `wrk` to `wrk-bench` like so:

```javascript
var bench = require('wrk-bench')

var job = bench({
	url: 'http://localhost:3000',
	threads: 2,
    connections: 5,
	duration: '10s'
})

job.pipe(process.stdout)
```

Which might result in output that looks like the following:

```json
{
  "transferPerSec": "355.09KB",
  "requestsPerSec": 228.54,
  "requestsTotal": 2286,
  "durationActual": "10.00s",
  "transferTotal": "3.47MB",
  "latencyAvg": "17.62ms",
  "latencyStdev": "4.29ms",
  "latencyMax": "73.93ms",
  "latencyStdevPerc": 98.67,
  "rpsAvg": 115.89,
  "rpsStdev": 15.94,
  "rpsMax": 171,
  "rpsStdevPerc": 79.32,
  "options-threads": 2,
  "options-connections": 5,
  "options-duration": "10s",
  "options-url": "http://localhost:3000"
  "timestamp": 1413854725961
}
```

Notice how the options is merged into the object. This makes it so you don't
have to track each job yourself. Also if you add any other properties to the
option argument they will be merged in and if `wrk` doesn't know about them,
they wont be used. This is handy if you want to name jobs or add in any
interesting version data or something of that sort.

Also a timestamp of when the test finished is added to the object as well. I am
up for debate on this and could also see collecting start/end and reporting
them, or maybe not having a timestamp on at all and leaving that up to a user of
the API

## theoretical changes

* Possibly take an array of jobs
* Delay between jobs seems like a good idea but I don't have a use case yet.
* Standardize the output. So `KB`/`MB` values are always bytes. `ns`, `ms`, `s`,
  `m`, etc all changed to `ms`

{'fraction_non_alphanumeric': 0.1042246982358403, 'fraction_numerical': 0.037604456824512536, 'mean_word_length': 4.075382803297997, 'pattern_counts': {'":': 36, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5901549', 'n_tokens_mistral': 1502, 'n_tokens_neox': 1354, 'n_words': 630}