You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
plgm comes with a built-in default workload useful for immediate testing and get you started right away.
164
187
```bash
165
188
# Edit config.yaml to set your URI, then run:
@@ -176,7 +199,189 @@ If you wish to use a different default workload, you can replace these two files
176
199
./bin/plgm /path/to/some/custom_config.yaml
177
200
```
178
201
179
-
### 3. Additional Workloads
202
+
### 3. Raw Injector Mode (High Performance Hardware Test) Workload
203
+
204
+
The **Raw Injector** is a specialized, ultra-high-performance engine built directly into `PLGM`. Instead of using the standard MongoDB driver structs (which consume CPU and memory for BSON marshaling), the Raw Injector pre-compiles raw BSON byte arrays and performs zero-allocation bitwise mutations in a tight loop.
205
+
206
+
This mode is designed exclusively to **stress-test network throughput, disk I/O, and extreme CPU limits** of the MongoDB cluster. It can saturate high-end infrastructure significantly faster than standard workloads. This functionality was developed to mimic other benchmarking tools, enabling an apples-to-apples comparison between PLGM and alternative solutions.
207
+
208
+
Unlike the other workloads PLGM supports, this mode is not configurable. It was intentionally built solely for stress testing purposes and is not intended to function as a workload simulator, but instead, a simple benchmark stress test.
209
+
210
+
***Important Note on Ops/Sec: In Raw Injector mode, the printed Ops/Sec refers to the number of documents processed, not the number of network commands. For example, if your batch size is 1,000, and plgm reports 50,000 Ops/Sec, it is executing 50 bulk network commands per second.***
211
+
212
+
#### Configuration
213
+
214
+
You can configure the Raw Injector via `config.yaml` or directly via CLI flags/environment variables. These are the available options:
You will find additional workloads that you can use as references to benchmark your environment in cases where you prefer not to provide your own collection definitions and queries. However, if your goal is to test your application accurately, we strongly recommend creating collection definitions and queries that match those used by your application.
182
387
@@ -186,7 +391,7 @@ The additional collection and query definitions can be found here:
186
391
* [queries](./resources/queries/)
187
392
188
393
189
-
### 4. Workload Configuration & Loading
394
+
### 5. Workload Configuration & Loading
190
395
191
396
You can supply your own collections and queries using the `PLGM_COLLECTIONS_PATH` and `PLGM_QUERIES_PATH` environment variables (or the corresponding config file fields).
192
397
@@ -215,7 +420,9 @@ When using **Directory Mode**, the behavior depends on the `PLGM_DEFAULT_WORKLOA
215
420
***`false` (Custom):** Loads all JSON files **except**`default.json`.
216
421
**Use Case:* Set this to `false` to run your custom workload files while keeping `default.json`in the folder for reference (it will be ignored).
217
422
218
-
### 5. Kubernetes & Docker
423
+
---
424
+
425
+
## Kubernetes & Docker
219
426
Prefer running in a container? We have a dedicated guide for building Docker images and running performance jobs directly inside Kubernetes (recommended for accurate network latency testing).
220
427
221
428
[View the Docker & Kubernetes Guide](k8s_and_docker.md)
@@ -249,6 +456,7 @@ You can override any setting in `config.yaml` using environment variables. This
249
456
|`skip_seed`|`PLGM_SKIP_SEED`| Do not seed initial data on start (`true`/`false`) |`true`|
250
457
|`seed_batch_size`|`PLGM_SEED_BATCH_SIZE`| Number of documents to insert per batch during SEED phase |`1000`|
0 commit comments