IntenseFinance/nosqlbench
3
0
Fork 0
mirror of https://github.com/nosqlbench/nosqlbench.git synced 2025-02-25 18:55:28 -06:00
Code Issues Packages Projects Releases Wiki Activity

minor doc fixes

Browse Source
This commit is contained in:
Jonathan Shook 2023-10-23 17:17:16 -05:00
parent 29c35cefb8
commit 871a1f2594
1 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
nb_521.md
View File

@ -3,19 +3,16 @@
__release notes preview / work-in-progress__
The 5.21 series of NoSQLBench marks a significant departure from the earlier versions. The platform
is rebased on top of [Java 21 LTS](https://openjdk.org/projects/jdk/21/). The core architecture
has been adapted to suit more advanced workflows, particularly around dimensional metrics, test
parameterization and labeling, and automated analysis. Support for the hierarchic naming methods of
graphite have been removed and the core metrics logic has been rebuilt around dimensional metric
labeling.
is rebased on top of Java 21 LTS. The core architecture has been adapted to suit more advanced
workflows, particularly around dimensional metrics, test parameterization and labeling, and
automated analysis. Support for the hierarchic naming methods of graphite have been removed and the
core metrics logic has been rebuilt around dimensional metric labeling.
## Java 21 LTS
The release of [Java 21](https://openjdk.org/projects/jdk/21/) is significant to the NoSQLBench
project for several reasons.
### Java 21 Performance & Threading Model
For systems like NoSQLBench, the runtime threading model in Java 21 is much improved. Virtual
threads offer a distinctly better solution for the kinds of workloads where you need to emulate
request-per-thread behavior efficiently. While virtual threads are not advised as a general
@ -57,8 +54,9 @@ Here are some of the basic features of the component tree:
within a parent component. Each component has a labels property which is the logical sum of all
the labels on it and all parents. This provides unique labels at every level which are compatible
with dimensional metrics, annotation, and logging systems.
* As a specific exception to the unique labels rule, some intermediate components may provide
an empty label set. A parent node may contain any number of these.
* As a specific exception to the unique labels rule, some intermediate components may provide
an empty label set. A parent node may contain any number of these. They are generally
structural shims or similar elements which will be factored out.
* Basic services, like metrics registration are provided within the component API
orthogonally and attached directly to components. Thus, the view of all metrics within the
runtime is simply the sum of all metrics registered on all components with respect to a
@ -105,9 +103,10 @@ Backstory and motivation for this change is captured in [^1].
Beginning in NoSQLBench 5.21, the primary metrics transport will be client-push using the
[openmetrics](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md)
exposition format. As well, the Victoria Metrics [community edition](https://victoriametrics.com/products/open-source/)
is open source and provides all the necessary telemetry features needed, it is the preferred
collector, database, and query engine which the NoSQLBench project will integrate with by default.
exposition format. As well, the Victoria
Metrics [community edition](https://victoriametrics.com/products/open-source/)
is open source and provides all the necessary telemetry features needed. It is the preferred
collector, database, and query engine which the NoSQLBench project will integrate with by default.
That doesn't mean that others will be or are not supported, but it does mean that they will not get
prioritized for implementation unless there is a specific user need which doesn't compromise the
basic integrity of the dimensional metrics system.