max concurrency can not be greater than 300

I use a benchmark tool called “hey” to do the performance test.

The target of the test if just a nginx serve static small files about 30 bytes.

here is the command, which means 1000 request with 300 concurrent client.

hey -n 1000 -c 300 https://${myapp}.fly.dev/hello

However, I got many “connection reset by peer”.

And, when I decrease the “-c” paramter to smaller, like 200, then all the requests is succesfull.

I don’t know why, could you help me to figure it out? Many thanks to you guys.

Can you share your fly.toml file? I’m curious what concurrency values you have set.

Thank you for your quick response.
It may be caused by https. The benchmark for http://$myapp.fly.dev works well, however, if I replace “http” with “https”, the server can only serve at most 200 concurrent connections.

kill_signal = “SIGINT”

kill_timeout = 5

processes =

[env]

PORT = “3000”

[experimental]

allowed_public_ports =

auto_rollback = true

[[services]]

http_checks =

internal_port = 3000

processes = [“app”]

protocol = “tcp”

script_checks =

[services.concurrency]

hard_limit = 100

soft_limit = 50

type = “connections”

[[services.ports]]

force_https = false

handlers = [“http”]

port = 80

[[services.ports]]

handlers = [“tls”, “http”]

port = 443

[[services.tcp_checks]]

grace_period = “1s”

interval = “15s”

restart_limit = 0

timeout = “2s”

Try changing the concurrency type to requests. Connections concurrency means our proxy is opening a new connecting to your VM each time. nginx does not like that and tends to behave better when we pool connections.

type="requests" lets us pool connections.

1 Like

This is expected behavior — there’s concurrency limits on TLS handshakes (max concurrent handshakes per IP). You’ll need to spread your test across several IPs to make it look more like organic traffic to get meaningful numbers.

1 Like