Add staggered --demo mode to null pyworker client
Three concurrent /reserve calls 30s apart, then cancel the first to show the early-release path. The remaining two run until their duration cap. Useful for watching scale-up/scale-down behaviour in the autoscaler dashboard. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
+16
-4
@@ -135,14 +135,26 @@ authentication on it.
|
||||
|
||||
## Client example
|
||||
|
||||
Single reservation:
|
||||
|
||||
```bash
|
||||
python -m workers.null.client --endpoint <ENDPOINT_NAME> --duration 600
|
||||
```
|
||||
|
||||
This POSTs once to `/reserve`, which causes exactly one worker to be
|
||||
provisioned (if none is free) and held busy. To exercise the full flow,
|
||||
shell into the worker and run `curl -X POST http://127.0.0.1:18999/release`
|
||||
— the client will return with `{"released": "explicit", ...}`.
|
||||
To exercise the full flow, shell into the worker and run
|
||||
`curl -X POST http://127.0.0.1:18999/release` — the client returns with
|
||||
`{"released": "explicit", ...}`.
|
||||
|
||||
Staggered demo:
|
||||
|
||||
```bash
|
||||
python -m workers.null.client --endpoint <ENDPOINT_NAME> --demo
|
||||
```
|
||||
|
||||
Starts three reservations 30s apart (all held concurrently), waits another
|
||||
30s, then cancels the first by dropping its HTTP connection. The remaining
|
||||
two run until their duration cap. Useful for watching scale-up and
|
||||
scale-down behaviour in the autoscaler dashboard.
|
||||
|
||||
## Notes and caveats
|
||||
|
||||
|
||||
Reference in New Issue
Block a user