Skip to content

Commit b504f56

Browse files
committed
Another test
1 parent 2a34243 commit b504f56

File tree

11 files changed

+258
-26
lines changed

11 files changed

+258
-26
lines changed

docs/backend/performance.md

Lines changed: 254 additions & 22 deletions
Large diffs are not rendered by default.

docs/backend/storm-architecture.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -61,8 +61,8 @@ Since the data from the Prepare Request bolt (a query and a piece of return info
6161
The topology set up this way scales horizontally and has some nice properties:
6262

6363
* If you want to scale for processing more data but the same amount of queries, you only need to scale the components that read your data (the spout reading the data or your custom topology) and the Filter bolts.
64-
* If you want to scale for more queries but the same amount of data, you only need to scale up the DRPC spouts, Prepare Request bolts, Join bolts and Return Results bolts (first order). These components generally have low parallelism compared to your data since the data is generally much higher.
64+
* If you want to scale for more queries but the same amount of data, you need to scale up the DRPC spouts, Prepare Request bolts, Join bolts and Return Results bolts. These components generally have low parallelism compared to your data since the data is generally much higher.
6565

66-
!!! note "First order?"
66+
!!! note "More queries and Filter bolts"
6767

68-
If you send more queries to the Filter bolt, it will be limited by at most how many queries a Filter bolt can store and still process data efficiently. Factors like CPU, memory allocations etc for the Filter bolts come in to the picture in addition to the parallelism. Generally, if you have allocated enough Filter bolts to process your data with enough head room, this should let you run hundreds of queries simultaneously before you run into these issues.
68+
If you send more queries to the Filter bolt, it will be limited by at most how many queries a Filter bolt can store and still process data efficiently. Factors like CPU, memory allocations etc for the Filter bolts come in to the picture in addition to the parallelism. Generally, if you have allocated enough Filter bolts to process your data with enough head room, this should let you run hundreds of queries simultaneously before you run into these issues. In practice, since most usage is expected to be on large data volumes and 100s of queries simultaneously, you will need to scale the the Filter bolts out so that they are not slowed down by the large number of queries in each.

docs/img/raw-perf-2-cpu.png

648 KB
Loading

docs/img/raw-perf-2-gc.png

665 KB
Loading

docs/img/raw-perf-2-heap.png

1.16 MB
Loading

docs/img/raw-perf-2-queries.png

50.1 KB
Loading

docs/img/raw-perf-cpu.png

413 KB
Loading

docs/img/raw-perf-gc.png

435 KB
Loading

docs/img/raw-perf-heap.png

683 KB
Loading

docs/img/raw-perf-queries.png

45.6 KB
Loading

0 commit comments

Comments
 (0)