this should fix #23.

As the Attack method is now sending messages to the 'metricsCh', and it looks at the Context being complete (completely stopping the attack), I simply removed the channel send that was being done to metricsCh in gui/keybinds.go . This fixed the panic and the Ctrl-C issue for me.

I noticed this when installing:

$ brew install nakabonne/ali/ali
==> Tapping nakabonne/ali
Cloning into '/usr/local/Homebrew/Library/Taps/nakabonne/homebrew-ali'...
remote: Enumerating objects: 39, done.
remote: Counting objects: 100% (39/39), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 39 (delta 13), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (39/39), 6.26 KiB | 6.26 MiB/s, done.
Resolving deltas: 100% (13/13), done.
Tapped 1 formula (26 files, 33.6KB).
Error: No available formula or cask with the name "nakabonne/ali/ali".
==> Searching for similarly named formulae...
This similarly named formula was found:
ali
To install it, run:
  brew install ali
~ ⌚ 9:02:48
$ brew install ali              
==> Installing ali from nakabonne/ali
==> Downloading https://github.com/nakabonne/ali/releases/download/v0.3.3/ali_0.3.3_darwin_amd64.tar.gz
==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/294836885/d0365a80-0
######################################################################## 100.0%
🍺  /usr/local/Cellar/ali/0.3.3: 5 files, 6.2MB, built in 2 seconds
```
`

Hey,

please add the feature to add cli options for the http(s) requests like ali --targeturl=http://www.foo.bar --duration=10 --timeout=30 an so on. Thank you.

Docs suggest brew install nakabonne/ali/ali however Homebrew responds with an error, I believe the correct series of commands is brew tap nakabonne/ali followed by brew install ali

brew install nakabonne/ali/ali
==> Tapping nakabonne/ali
Cloning into '/usr/local/Homebrew/Library/Taps/nakabonne/homebrew-ali'...
Error: No available formula or cask with the name "nakabonne/ali/ali".
==> Searching for similarly named formulae...
This similarly named formula was found:
ali
To install it, run:
  brew install ali
brew install ali
==> Installing ali from nakabonne/ali

It would be nice if it's able to press Ctrl-i to switch between charts.

• [x] Plot 50th, 90th, 95th, and 99th percentiles #66
• [ ] Bytes In and Bytes Out
• [ ] Status Codes
• [ ] Histogram #63
• [ ] ~Workers running in concurrent~

First of all: Thanks heaps for this wonderful tool. I am absolutely loving it. Great work, thanks!

I just noticed headers are declared as StringSliceVarP:

flagSet.StringSliceVarP(&c.headers, "header", "H", []string{}, "A request header to be sent. Can be used multiple times to send multiple headers.")

Why allow comma separated values within the --header flag? I think for header values it's a common use case to have them contain a comma separated list of values (i.e. user groups).

Solution: Switch to StringArrayVarP and force users to supply multiple --header flags to define all header fields.

So instead of:

ali --header "key1:value1,key2:value2"

Use this:

ali --header "groups:group1,group2,group3" --header "user:username"

What do you think?

What's happened

ali -r 0 -d 2s http://host.xz

Then:

Possible Causes

It's probably due to the time it takes to draw to all the charts. Maybe we should each spawn goroutine. https://github.com/nakabonne/ali/blob/2711e42b6d038296c100fd2e8a0fdf0ce84996af/gui/drawer.go#L66-L84

This PR adds percentiles chart support, which can be enabled with Ctrl-(P) ercentiles.

You can change to latencies chart again Latencies chart with Ctrl-(L) atencies.

As I'm not sure we're "hiding" this functionality under a shortcut, I did not update the README yet.

Added a utility function to create charts with legends. (preparing for bytes-in/bytes-out or any other metric) Added a utility type so we can easily create charts with legends (chartLegend)

Although it's working correctly, I few like there are a few improvements that can be made (specially in gui/gui.go).

This PR also fixes a few issues I noticed while using ali:

• Percentiles (text) where not being updated correctly. This was happening because vegeta.Metrics only set P50/90... when (*vegeta.Metrics).Close() is called. I modified newMetrics to calculate quantiles as newMetrics is called.
• Also fixed the handling of chartCh and metrics. The way it was, it could not calculate floating point values (as when appending it calculated value/time.Millisecond. As time.Millisecond is an int64, it means everything was being rounded to either 0s or 1.0s), not allowing us to calculate 500ms as 0.5s.

It also allows texts to be customized (with cellColors - this is necessary because of Legends, which we want to have the same color as its own Series).

This is how it looks:

I feel like adding values to charts is way too manual, at the moment. Perhaps adding a type that holds a function which extracts metrics (from vegeta.Metrics) to a lineChart is a good idea?

This is my current workaround I am using for the issue #111 (fatal error: concurrent map iteration and map write) to guard against concurrent access to the shared map StatusCodes accross ali and its library tsenart/vegeta

This PR makes it possible to switch to send HTTP/2 requests when supported by the server. Also found that connections is not passed to the attacker.Options struct while rebasing, fixed that as well :smiley:

Added a flag --http2 for switching to HTTP/2

mayadata:ali$ ./ali --help
Usage:
  ali [flags] <target URL>

Flags:
  -b, --body string         A request body to be sent.
  -B, --body-file string    The path to file whose content will be set as the http request body.
  -c, --connections int     Amount of maximum open idle connections per target host (default 10000
      --debug               Run in debug mode.
  -d, --duration duration   The amount of time to issue requests to the targets. Give 0s for an infinite attack. (default 10s)
  -H, --header strings      A request header to be sent. Can be used multiple times to send multiple headers.
      --http2               Issue HTTP/2 requests to servers which support it. (default true) (default true)
  -k, --keepalive           Use HTTP persistent connection. (default true)
  -M, --max-body int        Max bytes to capture from response bodies. Give -1 for no limit. (default -1)
  -W, --max-workers uint    Amount of maximum workers to spawn. (default 18446744073709551615)
  -m, --method string       An HTTP request method for each request. (default "GET")
  -r, --rate int            The request rate per second to issue against the targets. Give 0 then it will send requests as fast as possible. (default 50)
  -t, --timeout duration    The timeout for each request. 0s means to disable timeouts. (default 30s)
  -v, --version             Print the current version.
  -w, --workers uint        Amount of initial workers to spawn. (default 10)

Examples:
  ali --duration=10m --rate=100 http://host.xz

Author:
  Ryo Nakao <[email protected]>

Took me sometime to notice we can undo a Zoom with the mouse scroll (why? Not sure. Perhaps documentation in the README will do), but I thought that we can simulate zoom-outs with a mouse right click.

Does it make sense to you? (Zoom in with selection; zoom out with right click)

Hello! https://github.com/nakabonne/ali/blob/e3f49a43534500bac198f5dc9172bf2723e37bbe/attacker/attacker.go#L25

After performing several tests, I found that if this parameter "--max-workers" is not passed, there is some severe performance penalty.

How I discovered the performance issue: Without passing the "-W" as a parameter and benchmarking a powerful web server on my own local machine, I gradually increased the requests per second until I was limited to around 10k req/s due to performance issues: Ali crashed and the graphs showed that my server's latency was only going up! However... On the other hand the "wrk" tool was handling more than 80k req/s so the problem was not in my web server.

I decided start the ali benchmark again by setting the "-W" to 10 and gradually increased both the rate (-r) and the max-workers until I understood that on my machine the maximum request that each worker could handle was around 1000 req / worker. So I tested it and in every time that I didn't set the max-workers the benchmark crashed after 10k/sec and in every time that I set the max-workers ali ran smoothly.

Then, using the command: ali -r 25000 -d 15s -W 25 http://localhost:8080/

The 10k/sec bottleneck was avoided until reaching the intended 25k/sec in the command.

The tip performance then is:

1. Never run ali without defining the -W param and gradually increase the max number of workers so you can understand the rate of requests / worker needed to reach the rate you want and avoid this bug..
2. To max performance set --redraw-interval 1000ms too.

For the dev team: Set max-workers as required in params or min 10 max-workers and max -> if rate > 1000 then max-workers = rate / 1000 (rounded).

A way to give it a Step Period and Step Rate. Example:

--step-period 30m --step-rate-increase 1000 --max-requests 20000

So you can increase the rate every 30 minutes by 1000 requests. Metrics can settle during the step period and the slow increase of requests can let you know the tipping point of you application. The max requests can have no ceiling by default.

When the request number is very big, Ali shows graph of partial data. See the below screenshot, it's showing 14707 requests out of 75000 in histogram.

Also, how to make ali wait for requests to finish after the duration? Seems like ali just exits as soon as the duration ends.