solid_queue_autoscaler 1.0.20 → 1.0.21
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +9 -0
- data/README.md +46 -0
- data/lib/solid_queue_autoscaler/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 4d595bb4e0a25ed4dee60b1356275872000b56845d574a2df7251a3c49f51a2c
|
|
4
|
+
data.tar.gz: 3fa34bfdbd30991096ceba918548660b955ab882ca050bae2e03be94f19c0967
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 52e7e13ad3261de3ca958e5e5468b9fde784c1573a4e3865022331c07e21ce74d047646cb68f7d9376df1b3863ffded3a2dcd649655047ca240db074050f65c0
|
|
7
|
+
data.tar.gz: ce1ad6a0ab0eb9205cf73db618d0363afeedc449c9527b0187f634aa320ec0735e4c216990f0dc3aae760f47936ab48abd5ab278aafd845b4e3d0ecd48f9a923
|
data/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,15 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
7
7
|
|
|
8
8
|
## [Unreleased]
|
|
9
9
|
|
|
10
|
+
## [1.0.21] - 2025-02-02
|
|
11
|
+
|
|
12
|
+
### Added
|
|
13
|
+
- **Scale-from-zero documentation** - Updated README and docs/configuration.md with:
|
|
14
|
+
- New "Faster Scale-from-Zero" section explaining the v1.0.20 optimizations
|
|
15
|
+
- Configuration reference for `scale_from_zero_queue_depth` and `scale_from_zero_latency_seconds`
|
|
16
|
+
- Example configuration showing how to customize scale-from-zero behavior
|
|
17
|
+
- Explanation of cooldown bypass and grace period for other workers
|
|
18
|
+
|
|
10
19
|
## [1.0.20] - 2025-02-02
|
|
11
20
|
|
|
12
21
|
### Added
|
data/README.md
CHANGED
|
@@ -80,6 +80,41 @@ end
|
|
|
80
80
|
|
|
81
81
|
Total cold-start time is typically **30-90 seconds** depending on your configuration and dyno startup time.
|
|
82
82
|
|
|
83
|
+
### Faster Scale-from-Zero (v1.0.20+)
|
|
84
|
+
|
|
85
|
+
As of **v1.0.20**, the autoscaler includes optimizations for faster cold starts when scaling from zero:
|
|
86
|
+
|
|
87
|
+
1. **Lower thresholds at zero**: When workers are at 0 (with `min_workers = 0`), the autoscaler uses separate, more aggressive thresholds:
|
|
88
|
+
- `scale_from_zero_queue_depth` (default: 1) - Scale up when there's at least 1 job
|
|
89
|
+
- `scale_from_zero_latency_seconds` (default: 1.0) - Job must be at least 1 second old
|
|
90
|
+
|
|
91
|
+
2. **Cooldown bypass**: Cooldowns are skipped when scaling from 0 workers, ensuring the fastest possible response.
|
|
92
|
+
|
|
93
|
+
3. **Grace period for other workers**: The `scale_from_zero_latency_seconds` setting (default: 1 second) ensures that if you have multiple worker types, other workers have a brief chance to pick up the job before a new dyno is spun up.
|
|
94
|
+
|
|
95
|
+
**Example configuration:**
|
|
96
|
+
|
|
97
|
+
```ruby
|
|
98
|
+
SolidQueueAutoscaler.configure(:batch_worker) do |config|
|
|
99
|
+
config.adapter = :heroku
|
|
100
|
+
config.heroku_api_key = ENV['HEROKU_API_KEY']
|
|
101
|
+
config.heroku_app_name = ENV['HEROKU_APP_NAME']
|
|
102
|
+
config.process_type = 'batch_worker'
|
|
103
|
+
|
|
104
|
+
# Enable scale-to-zero
|
|
105
|
+
config.min_workers = 0
|
|
106
|
+
config.max_workers = 5
|
|
107
|
+
|
|
108
|
+
# Normal scaling thresholds (used when workers > 0)
|
|
109
|
+
config.scale_up_queue_depth = 100
|
|
110
|
+
config.scale_up_latency_seconds = 300
|
|
111
|
+
|
|
112
|
+
# Scale-from-zero thresholds (used when workers == 0)
|
|
113
|
+
config.scale_from_zero_queue_depth = 1 # Scale up with just 1 job
|
|
114
|
+
config.scale_from_zero_latency_seconds = 2.0 # Wait 2 seconds for other workers
|
|
115
|
+
end
|
|
116
|
+
```
|
|
117
|
+
|
|
83
118
|
**Where to run the autoscaler**: The autoscaler job **must run on a process that's always running** (like your web dyno), NOT on the workers being scaled. If the autoscaler runs on workers and those workers scale to zero, there's nothing to scale them back up!
|
|
84
119
|
|
|
85
120
|
```yaml
|
|
@@ -326,6 +361,17 @@ Scaling down triggers when **ALL** thresholds are met:
|
|
|
326
361
|
| `scale_down_cooldown_seconds` | Integer | `nil` | Override for scale-down cooldown |
|
|
327
362
|
| `persist_cooldowns` | Boolean | `true` | Save cooldowns to database |
|
|
328
363
|
|
|
364
|
+
### Scale-from-Zero Optimization
|
|
365
|
+
|
|
366
|
+
These settings control the faster cold-start behavior when `min_workers = 0` and workers are currently at 0:
|
|
367
|
+
|
|
368
|
+
| Option | Type | Default | Description |
|
|
369
|
+
|--------|------|---------|-------------|
|
|
370
|
+
| `scale_from_zero_queue_depth` | Integer | `1` | Jobs in queue to trigger scale-up when at 0 workers |
|
|
371
|
+
| `scale_from_zero_latency_seconds` | Float | `1.0` | Job must be at least this old (gives other workers a chance) |
|
|
372
|
+
|
|
373
|
+
**Note:** When scaling from 0 workers, cooldowns are automatically bypassed for the fastest possible response.
|
|
374
|
+
|
|
329
375
|
### AutoscaleJob Settings
|
|
330
376
|
|
|
331
377
|
| Option | Type | Default | Description |
|