stac-api-load-testing 0.3.0__tar.gz → 0.3.1__tar.gz

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.
Files changed (19) hide show
  1. {stac_api_load_testing-0.3.0/stac_api_load_testing.egg-info → stac_api_load_testing-0.3.1}/PKG-INFO +35 -1
  2. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/README.md +34 -0
  3. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/pyproject.toml +1 -1
  4. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/cli.py +1 -1
  5. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/data_loader/setup_data/collection.json +1 -0
  6. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1/stac_api_load_testing.egg-info}/PKG-INFO +35 -1
  7. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/LICENSE +0 -0
  8. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/setup.cfg +0 -0
  9. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/__init__.py +0 -0
  10. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/config_files/locustfile.py +0 -0
  11. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/config_files/taurus_locust.yml +0 -0
  12. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/data_loader/__init__.py +0 -0
  13. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/data_loader/data_loader.py +0 -0
  14. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing/data_loader/setup_data/sentinel-s2-l2a-cogs_0_100.json +0 -0
  15. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing.egg-info/SOURCES.txt +0 -0
  16. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing.egg-info/dependency_links.txt +0 -0
  17. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing.egg-info/entry_points.txt +0 -0
  18. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing.egg-info/requires.txt +0 -0
  19. {stac_api_load_testing-0.3.0 → stac_api_load_testing-0.3.1}/stac_api_load_testing.egg-info/top_level.txt +0 -0
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: stac-api-load-testing
3
- Version: 0.3.0
3
+ Version: 0.3.1
4
4
  Summary: Load testing for stac compliant apis
5
5
  Author-email: Jonathan Healy <jonathan.d.healy@gmail.com>
6
6
  License: MIT
@@ -110,5 +110,39 @@ Compare multiple backends in one command (comma-separated addresses):
110
110
 
111
111
  ```$ stac-api-load-testing --benchmark --api-address http://localhost:8085,http://localhost:8087 --users 10,50,100 --run-time 1m -o results.csv```
112
112
 
113
+ ## Example benchmark: stac-fastapi-os vs stac-os-rs
114
+
115
+ Methodology used for the comparison below:
116
+
117
+ 1. Start each backend with its own dedicated OpenSearch 3.8.0 instance (2GB heap each):
118
+
119
+ ```$ docker compose up -d opensearch opensearch-rs app-opensearch app-stac-os-rs```
120
+
121
+ 2. Ingest the same dataset into both backends — 1 collection (`test-collection`) with 100 Sentinel-2 L2A items:
122
+
123
+ ```$ stac-api-load-testing --ingest --api-address http://localhost:8085```
124
+ ```$ stac-api-load-testing --ingest --api-address http://localhost:8087```
125
+
126
+ 3. Run the benchmark sweep against both in one command (10/50/100 users, spawn rate 10 users/s, 1 minute per run):
127
+
128
+ ```$ stac-api-load-testing --benchmark --api-address http://localhost:8085,http://localhost:8087 --users 10,50,100 --run-time 1m -o results.csv```
129
+
130
+ Environment: AMD Ryzen 7 8845HS (16 threads), 28GB RAM, Docker 29.8.0, locust 2.47.0, stac-fastapi-os v8.1.1, stac-os-rs 0.2.0. The locustfile drives a read/search workload — landing page, collections, collection items, single items, and GET/POST `/search` with bbox, intersects, and sortby queries; write tasks are disabled.
131
+
132
+ ### Results
133
+
134
+ | api | users | requests | failures | median (ms) | p95 (ms) | p99 (ms) | req/s |
135
+ | --- | --- | --- | --- | --- | --- | --- | --- |
136
+ | stac-fastapi-os (:8085) | 10 | 48,672 | 0 | 9 | 24 | 32 | 822 |
137
+ | stac-fastapi-os (:8085) | 50 | 51,659 | 0 | 48 | 88 | 110 | 864 |
138
+ | stac-fastapi-os (:8085) | 100 | 47,758 | 0 | 100 | 170 | 210 | 800 |
139
+ | stac-os-rs (:8087) | 10 | 75,601 | 0 | 6 | 19 | 36 | 1,276 |
140
+ | stac-os-rs (:8087) | 50 | 75,769 | 0 | 33 | 62 | 190 | 1,264 |
141
+ | stac-os-rs (:8087) | 100 | 72,621 | 0 | 64 | 120 | 360 | 1,220 |
142
+
143
+ ### Summary
144
+
145
+ stac-os-rs sustained ~45-55% higher throughput than stac-fastapi-os at every concurrency level (peaks of ~1,270 vs ~860 req/s) with lower median latency, and zero failures on either backend. stac-fastapi-os saturates near 50 users — median latency climbs 9→48→100ms while throughput stays flat — whereas stac-os-rs plateaus at a higher request rate. Caveat: locust reported >90% CPU on the load generator during all stac-os-rs runs, so its true ceiling is likely higher than measured; distributed locust workers would give a more precise figure. These numbers reflect a small (100-item) dataset on a single machine and should be treated as relative comparison, not absolute capacity.
146
+
113
147
  ## Debugging Locust tasks using a single simulated user
114
148
  ```$ python stac_api_load_testing/config_files/locustfile.py```
@@ -91,5 +91,39 @@ Compare multiple backends in one command (comma-separated addresses):
91
91
 
92
92
  ```$ stac-api-load-testing --benchmark --api-address http://localhost:8085,http://localhost:8087 --users 10,50,100 --run-time 1m -o results.csv```
93
93
 
94
+ ## Example benchmark: stac-fastapi-os vs stac-os-rs
95
+
96
+ Methodology used for the comparison below:
97
+
98
+ 1. Start each backend with its own dedicated OpenSearch 3.8.0 instance (2GB heap each):
99
+
100
+ ```$ docker compose up -d opensearch opensearch-rs app-opensearch app-stac-os-rs```
101
+
102
+ 2. Ingest the same dataset into both backends — 1 collection (`test-collection`) with 100 Sentinel-2 L2A items:
103
+
104
+ ```$ stac-api-load-testing --ingest --api-address http://localhost:8085```
105
+ ```$ stac-api-load-testing --ingest --api-address http://localhost:8087```
106
+
107
+ 3. Run the benchmark sweep against both in one command (10/50/100 users, spawn rate 10 users/s, 1 minute per run):
108
+
109
+ ```$ stac-api-load-testing --benchmark --api-address http://localhost:8085,http://localhost:8087 --users 10,50,100 --run-time 1m -o results.csv```
110
+
111
+ Environment: AMD Ryzen 7 8845HS (16 threads), 28GB RAM, Docker 29.8.0, locust 2.47.0, stac-fastapi-os v8.1.1, stac-os-rs 0.2.0. The locustfile drives a read/search workload — landing page, collections, collection items, single items, and GET/POST `/search` with bbox, intersects, and sortby queries; write tasks are disabled.
112
+
113
+ ### Results
114
+
115
+ | api | users | requests | failures | median (ms) | p95 (ms) | p99 (ms) | req/s |
116
+ | --- | --- | --- | --- | --- | --- | --- | --- |
117
+ | stac-fastapi-os (:8085) | 10 | 48,672 | 0 | 9 | 24 | 32 | 822 |
118
+ | stac-fastapi-os (:8085) | 50 | 51,659 | 0 | 48 | 88 | 110 | 864 |
119
+ | stac-fastapi-os (:8085) | 100 | 47,758 | 0 | 100 | 170 | 210 | 800 |
120
+ | stac-os-rs (:8087) | 10 | 75,601 | 0 | 6 | 19 | 36 | 1,276 |
121
+ | stac-os-rs (:8087) | 50 | 75,769 | 0 | 33 | 62 | 190 | 1,264 |
122
+ | stac-os-rs (:8087) | 100 | 72,621 | 0 | 64 | 120 | 360 | 1,220 |
123
+
124
+ ### Summary
125
+
126
+ stac-os-rs sustained ~45-55% higher throughput than stac-fastapi-os at every concurrency level (peaks of ~1,270 vs ~860 req/s) with lower median latency, and zero failures on either backend. stac-fastapi-os saturates near 50 users — median latency climbs 9→48→100ms while throughput stays flat — whereas stac-os-rs plateaus at a higher request rate. Caveat: locust reported >90% CPU on the load generator during all stac-os-rs runs, so its true ceiling is likely higher than measured; distributed locust workers would give a more precise figure. These numbers reflect a small (100-item) dataset on a single machine and should be treated as relative comparison, not absolute capacity.
127
+
94
128
  ## Debugging Locust tasks using a single simulated user
95
129
  ```$ python stac_api_load_testing/config_files/locustfile.py```
@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
4
4
 
5
5
  [project]
6
6
  name = "stac-api-load-testing"
7
- version = "0.3.0"
7
+ version = "0.3.1"
8
8
  description = "Load testing for stac compliant apis"
9
9
  readme = "README.md"
10
10
  requires-python = ">=3.11"
@@ -234,7 +234,7 @@ def run_benchmark(
234
234
  help="Write aggregated --benchmark results to a CSV file.",
235
235
  type=click.Path(),
236
236
  )
237
- @click.version_option(version="0.3.0")
237
+ @click.version_option(version="0.3.1")
238
238
  def main(
239
239
  ingest: bool,
240
240
  locust: bool,
@@ -1,5 +1,6 @@
1
1
  {
2
2
  "id":"sentinel-s2-l2a-cogs",
3
+ "type":"Collection",
3
4
  "stac_version":"1.0.0",
4
5
  "description":"Sentinel-2a and Sentinel-2b imagery, processed to Level 2A (Surface Reflectance) and converted to Cloud-Optimized GeoTIFFs",
5
6
  "links":[
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: stac-api-load-testing
3
- Version: 0.3.0
3
+ Version: 0.3.1
4
4
  Summary: Load testing for stac compliant apis
5
5
  Author-email: Jonathan Healy <jonathan.d.healy@gmail.com>
6
6
  License: MIT
@@ -110,5 +110,39 @@ Compare multiple backends in one command (comma-separated addresses):
110
110
 
111
111
  ```$ stac-api-load-testing --benchmark --api-address http://localhost:8085,http://localhost:8087 --users 10,50,100 --run-time 1m -o results.csv```
112
112
 
113
+ ## Example benchmark: stac-fastapi-os vs stac-os-rs
114
+
115
+ Methodology used for the comparison below:
116
+
117
+ 1. Start each backend with its own dedicated OpenSearch 3.8.0 instance (2GB heap each):
118
+
119
+ ```$ docker compose up -d opensearch opensearch-rs app-opensearch app-stac-os-rs```
120
+
121
+ 2. Ingest the same dataset into both backends — 1 collection (`test-collection`) with 100 Sentinel-2 L2A items:
122
+
123
+ ```$ stac-api-load-testing --ingest --api-address http://localhost:8085```
124
+ ```$ stac-api-load-testing --ingest --api-address http://localhost:8087```
125
+
126
+ 3. Run the benchmark sweep against both in one command (10/50/100 users, spawn rate 10 users/s, 1 minute per run):
127
+
128
+ ```$ stac-api-load-testing --benchmark --api-address http://localhost:8085,http://localhost:8087 --users 10,50,100 --run-time 1m -o results.csv```
129
+
130
+ Environment: AMD Ryzen 7 8845HS (16 threads), 28GB RAM, Docker 29.8.0, locust 2.47.0, stac-fastapi-os v8.1.1, stac-os-rs 0.2.0. The locustfile drives a read/search workload — landing page, collections, collection items, single items, and GET/POST `/search` with bbox, intersects, and sortby queries; write tasks are disabled.
131
+
132
+ ### Results
133
+
134
+ | api | users | requests | failures | median (ms) | p95 (ms) | p99 (ms) | req/s |
135
+ | --- | --- | --- | --- | --- | --- | --- | --- |
136
+ | stac-fastapi-os (:8085) | 10 | 48,672 | 0 | 9 | 24 | 32 | 822 |
137
+ | stac-fastapi-os (:8085) | 50 | 51,659 | 0 | 48 | 88 | 110 | 864 |
138
+ | stac-fastapi-os (:8085) | 100 | 47,758 | 0 | 100 | 170 | 210 | 800 |
139
+ | stac-os-rs (:8087) | 10 | 75,601 | 0 | 6 | 19 | 36 | 1,276 |
140
+ | stac-os-rs (:8087) | 50 | 75,769 | 0 | 33 | 62 | 190 | 1,264 |
141
+ | stac-os-rs (:8087) | 100 | 72,621 | 0 | 64 | 120 | 360 | 1,220 |
142
+
143
+ ### Summary
144
+
145
+ stac-os-rs sustained ~45-55% higher throughput than stac-fastapi-os at every concurrency level (peaks of ~1,270 vs ~860 req/s) with lower median latency, and zero failures on either backend. stac-fastapi-os saturates near 50 users — median latency climbs 9→48→100ms while throughput stays flat — whereas stac-os-rs plateaus at a higher request rate. Caveat: locust reported >90% CPU on the load generator during all stac-os-rs runs, so its true ceiling is likely higher than measured; distributed locust workers would give a more precise figure. These numbers reflect a small (100-item) dataset on a single machine and should be treated as relative comparison, not absolute capacity.
146
+
113
147
  ## Debugging Locust tasks using a single simulated user
114
148
  ```$ python stac_api_load_testing/config_files/locustfile.py```