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

Document update

Browse Source
This commit is contained in:
Yabin Meng
2021-03-10 12:18:15 -06:00
parent adf1ea03e6
commit 58a93bd7b0
4 changed files with 347 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
driver-pulsar/src/main/resources/activities/config.properties
View File

@@ -9,7 +9,7 @@
# 1) primitive types, including bytearray (byte[]) which is default, for messages without schema
# 2) Avro for messages with schema
schema.type = avro
schema.definition = file:///Users/yabinmeng/DataStax/nosqlbench/driver-pulsar/src/main/resources/activities/iot-example.avsc
schema.definition = file://<file/path/to/iot-example.avsc>
@@ -22,7 +22,7 @@ client.connectionTimeoutMs = 5000
### Producer related configurations (global) - producer.xxx
# http://pulsar.apache.org/docs/en/client-libraries-java/#configure-producer
producer.producerName =
producer.topicName = persistent://public/default/mynbtest
producer.topicName =
producer.sendTimeoutMs =
@@ -41,7 +41,7 @@ consumer.receiverQueueSize =
### Reader related configurations (global) - reader.xxx
# https://pulsar.apache.org/docs/en/client-libraries-java/#reader
# - valid Pos: earliest, latest, custom::file://<path>/<to>/<message_id_file>
reader.topicName = persistent://public/default/nbpulsar
reader.topicName =
reader.receiverQueueSize =
reader.readerName =
reader.startMessagePos = earliest

9
driver-pulsar/src/main/resources/activities/pulsar.yaml
View File

@@ -12,7 +12,7 @@ bindings:
reading_value: ToFloat(100);
topic: Template("topic-{}",Mod(TEMPLATE(tenants,10)L));
# global parameters that apply to all Pulsar client types:
# document level parameters that apply to all Pulsar client types:
params:
#topic_uri: "persistent://public/default/{topic}"
topic_uri: "persistent://public/default/nbpulsar"
@@ -49,7 +49,7 @@ blocks:
"ReadingTime": "{reading_time}",
"ReadingValue": {reading_value}
}
ratio: 5
ratio: 100
- name: s3
optype: batch-msg-send-end
ratio: 1
@@ -59,8 +59,8 @@ blocks:
phase: producer
statements:
- name: s1
# producer_name: {producer_name}
optype: msg-send
# producer_name: {producer_name}
msg_key: "{mykey}"
msg_value: |
{
@@ -82,12 +82,13 @@ blocks:
subscription_type:
consumer_name:
- reader:
- name: reader-block
tags:
phase: reader
statements:
- name: s1
optype: msg-read
reader_name:
# - websocket-producer:
# tags:

425
driver-pulsar/src/main/resources/pulsar.md
View File

@@ -1,13 +1,19 @@
- [1. NoSQLBench (NB) Pulsar Driver Overview](#1-nosqlbench-nb-pulsar-driver-overview)
- [1.1. Issues Tracker](#11-issues-tracker)
- [1.2. Global Level Pulsar Configuration Settings](#12-global-level-pulsar-configuration-settings)
- [1.3. Pulsar Driver Yaml File: Statement Blocks](#13-pulsar-driver-yaml-file-statement-blocks)
- [1.3.1. Producer Statement block](#131-producer-statement-block)
- [1.3.2. Consumer Statement block](#132-consumer-statement-block)
- [1.4. Schema Support](#14-schema-support)
- [1.5. Activity Parameters](#15-activity-parameters)
- [1.6. Pulsar NB Execution Example](#16-pulsar-nb-execution-example)
- [2. Advanced Driver Features -- TODO: Design Revisit](#2-advanced-driver-features----todo-design-revisit)
- [1.3. NB Pulsar Driver Yaml File - High Level Structure](#13-nb-pulsar-driver-yaml-file---high-level-structure)
- [1.3.1. NB Cycle Level Parameters vs. Global Level Parameters](#131-nb-cycle-level-parameters-vs-global-level-parameters)
- [1.4. Pulsar Driver Yaml File - Command Block Details](#14-pulsar-driver-yaml-file---command-block-details)
- [1.4.1. Pulsar Admin API Command Block](#141-pulsar-admin-api-command-block)
- [1.4.2. Batch Producer Command Block](#142-batch-producer-command-block)
- [1.4.3. Producer Command Block](#143-producer-command-block)
- [1.4.4. Consumer Command Block](#144-consumer-command-block)
- [1.4.5. Reader Command Block](#145-reader-command-block)
- [1.5. Schema Support](#15-schema-support)
- [1.6. NB Activity Execution Parameters](#16-nb-activity-execution-parameters)
- [1.7. NB Pulsar Driver Execution Example](#17-nb-pulsar-driver-execution-example)
- [1.8. Appendix A. Template Global Setting File (config.properties)](#18-appendix-a-template-global-setting-file-configproperties)
- [2. TODO : Design Revisit -- Advanced Driver Features](#2-todo--design-revisit----advanced-driver-features)
- [2.1. Other Activity Parameters](#21-other-activity-parameters)
- [2.2. API Caching](#22-api-caching)
- [2.2.1. Instancing Controls](#221-instancing-controls)
@@ -17,12 +23,10 @@
This driver allows you to simulate and run different types of workloads (as below) against a Pulsar cluster through NoSQLBench (NB).
* Producer
* Consumer
* (Future) Reader
* Reader
* (Future) WebSocket Producer
* (Future) Managed Ledger
**NOTE**: At the moment, only Producer workload type is fully supported in NB. The support for Consumer type is partially added but not completed yet; and the support for other types of workloads will be added in NB in future releases.
## 1.1. Issues Tracker
If you have issues or new requirements for this driver, please add them at the [pulsar issues tracker](https://github.com/nosqlbench/nosqlbench/issues/new?labels=pulsar).
@@ -36,15 +40,11 @@ When creating these objects (e.g. PulsarClient, Producer), there are different c
The NB pulsar driver supports these options via a global properties file (e.g. **config.properties**). An example of this file is as below:
```properties
### NB Pulsar driver related configuration - driver.xxx
driver.client-type = producer
### Schema related configurations - schema.xxx
schema.type = avro
schema.definition = file:///<path/to/avro/schema/definition/file>
### Pulsar client related configurations - client.xxx
client.serviceUrl = pulsar://<pulsar_broker_ip>:6650
client.connectionTimeoutMs = 5000
### Producer related configurations (global) - producer.xxx
@@ -54,10 +54,6 @@ producer.sendTimeoutMs =
```
There are multiple sections in this file that correspond to different groups of configuration settings:
* **NB pulsar driver related settings**:
* All settings under this section starts with **driver.** prefix.
* Right now there is only valid option under this section:
* *driver.client-type* determines what type of Pulsar workload to be simulated by NB.
* **Schema related settings**:
* All settings under this section starts with **schema.** prefix.
* The NB Pulsar driver supports schema-based message publishing and consuming. This section defines configuration settings that are schema related.
@@ -69,73 +65,283 @@ There are multiple sections in this file that correspond to different groups of
* This section defines all configuration settings that are related with defining a PulsarClient object.
* See [Pulsar Doc Reference](https://pulsar.apache.org/docs/en/client-libraries-java/#default-broker-urls-for-standalone-clusters)
* **Pulsar Producer related settings**:
* All settings under this section starts with **producer.** prefix.
* All settings under this section starts with **producer** prefix.
* This section defines all configuration settings that are related with defining a Pulsar Producer object.
* See [Pulsar Doc Reference](https://pulsar.apache.org/docs/en/client-libraries-java/#configure-producer)
* **Pulsar Consumer related settings**:
* All settings under this section starts with **consumer** prefix.
* This section defines all configuration settings that are related with defining a Pulsar Consumer object.
* See [Pulsar Doc Reference](http://pulsar.apache.org/docs/en/client-libraries-java/#configure-consumer)
* **Pulsar Reader related settings**:
* All settings under this section starts with **reader** prefix.
* This section defines all configuration settings that are related with defining a Pulsar Reader object.
* See [Pulsar Doc Reference](https://pulsar.apache.org/docs/en/client-libraries-java/#reader)
In the future, when the support for other types of Pulsar workloads is added in NB Pulsar driver, there will be corresponding configuration sections in this file as well.
## 1.3. Pulsar Driver Yaml File: Statement Blocks
## 1.3. NB Pulsar Driver Yaml File - High Level Structure
Just like other NB driver types, the actual Pulsar workload generation is determined by the statement blocks in the NB driver Yaml file. Depending on the Pulsar workload type, the corresponding statement block may have different contents.
### 1.3.1. Producer Statement block
An example of defining Pulsar **Producer** workload is as below:
At high level, Pulsar driver yaml file has the following structure:
* **description**: (optional) general description of the yaml file
* **bindings**: defines NB bindings
* **params**: document level Pulsar driver parameters that apply to all command blocks. Currently there are two valid parameters:
* **topic_url**: Pulsar topic uri ([persistent|non-persistent]://<tenant>/<namespace>/<topic>). This can be statically assigned or dynamically generated via NB bindings.
* **async_api**: Whether to use asynchronous Pulsar API (**note**: more on this later)
* **blocks**: includes a series of command blocks. Each command block defines one major Pulsar operation such as *producer*, *consumer*, etc. Right now, the following command blocks are already supported or will be added in the near future. We'll go through each of these command blocks with more details in later sections.
* (future) **admin-block**: support for Pulsar Admin API, starting with using NB to create tenants and namespaces.
* **batch-producer-block**: Pulsar batch producer
* **producer-block**: Pulsar producer
* **consumer-block**: Pulsar consumer
* **reader-block**: Pulsar reader
```yaml
description: |
... ...
bindings:
... ...
# global parameters that apply to all Pulsar client types:
params:
topic_uri: "<pulsar_topic_name>"
async_api: "false"
blocks:
- name: producer-block
tags:
type: producer
statements:
- producer-stuff:
# producer-name:
# topic_uri: "persistent://public/default/{topic}"
topic_uri: "persistent://public/default/nbpulsar"
msg-key: "{mykey}"
msg-value: |
{
"SensorID": "{sensor_id}",
"SensorType": "Temperature",
"ReadingTime": "{reading_time}",
"ReadingValue": {reading_value}
}
- name: <command_block_1>
tags:
phase: <command_bock_filtering_identifier>
statements:
- name: <statement_name_1>
optype: <statement_filtering_identifier>
... <statement_specific_parameters> ...
- name: <statement_name_2>
... ...
- name: <command_block_2>
tags:
...
statements:
...
```
In the above statement block, there are 4 key statement parameters to provide values:
* **producer-name**: cycle-level Pulsar producer name (can be dynamically bound)
* **Optional**
* If not set, global level producer name in *config.properties* file will be used.
* Use a default producer name, "default", if it is neither set at global level.
* If set, cycle level producer name will take precedence over the global level setting
Each time when you execute the NB command, you can only choose one command block to execute. This is achieved by applying a filtering condition against **phase** tag, as below:
```bash
<nb_cmd> driver=pulsar tags=phase:<command_bock_filtering_identifier> ...
```
* **topic_uri**: cycle-level Pulsar topic name (can be dynamically bound)
* **Optional**
* If not set, global level topic_uri in *config.properties* file will be used
* Throw a Runtime Error if it is neither set at global level
* If set, cycle level topic_uri will take precedence over the global level setting; and the provided value must follow several guidelines:
* It must be in valid Pulsar topic format as below:
```
[persistent|non-persistent]://<tenant-name>/<namespace-name>/<short-topic-name>
```
* At the moment, only "**\<short-topic-name\>**" part can be dynamically bound (e.g. through NB binding function). All other parts must be static values and the corresponding tenants and namespaces must be created in the Pulsar cluster in advance.
An example of executing Pulsar producer/consumer API using NB is like this:
```bash
# producer
<nb_cmd> driver=pulsar tags=phase:producer ...
**TODO**: allow dynamic binding for "\<tenant-name\>" and "\<namespace-name\>" after adding a phase for creating "\<tenant-name\>" and/or "\<namespace-name\>", similar to C* CQL schema creation phase!
# consumer
<nb_cmd> driver=pulsar tags=phase:consumer ...
```
* **msg-key**: Pulsar message key
* **Optional**
* If not set, the generated Pulsar messages (to be published by the Producer) doesn't have **keys**.
### 1.3.1. NB Cycle Level Parameters vs. Global Level Parameters
* **msg-value**: Pulsar message payload
* **Mandatory**
* If not set, throw a Runtime Error.
Some parameters, especially topic name and producer/consumer/reader/etc. name, can be set at the global level in **config.properties** file, or at NB cycle level via **pulsar.yaml** file. An example of setting a topic name in both levels is as below:
### 1.3.2. Consumer Statement block
```bash
# Global level setting (config.properties):
producer.topicName = ...
**TBD ...**
# Cycle level setting (pulsar.yaml)
params:
topic_uri: ...
```
## 1.4. Schema Support
In theory, all Pulsar client settings can be made as cycle level settings for maximum flexibility. But practically speaking (and also for simplicity purposes), only the following parameters are made to be configurable at both levels, listed by cycle level setting names with their corresponding global level setting names:
* topic_uri (Mandatory)
* producer.topicName
* consumer.topicNames
* reader.topicName
* topic_names (Optional for Consumer)
* consumer.topicNames
* subscription_name (Mandatory for Consumer)
* consumer.subscriptionName
* subscription_type (Mandatory for Consumer, default to **exclusive** type)
* consumer.subscriptionType
* topics_pattern (Optional for Consumer)
* consumer.topicsPattern
* producer_name (Optional)
* producer.producerName
* consumer_name (Optional)
* consumer.consumerName
* reader_name (Optional)
* reader.readerName
One key difference between setting a parameter at the global level vs. at the cycle level is that the global level setting is always static and stays the same for all NB cycle execution. The cycle level setting, on the other side, can be dynamically bound and can be different from cycle to cycle.
Because of this, setting these parameters at the NB cycle level allows us to run Pulsar testing against multiple topics and/or multiple producers/consumers/readers/etc all at once within one NB activity. This makes the testing more flexible and effective.
**NOTE**, when a configuration is set at both the global level and the cycle level, **the ycle level setting will take priority!**
## 1.4. Pulsar Driver Yaml File - Command Block Details
### 1.4.1. Pulsar Admin API Command Block
**NOTE**: this functionality is only partially implemented at the moment and doesn't function yet.
Currently, the Pulsar Admin API Block is (planned) to only support creating Pulsar tenants and namespaces. It has the following format:
```yaml
- name: admin-block
tags:
phase: create-tenant-namespace
statements:
- name: s1
optype: create-tenant
tenant: "{tenant}"
- name: s2
optype: create-namespace
namespace: "{namespace}"
```
In this command block, there are 2 statements (s1 and s2):
* Statement **s1** is used for creating a Pulsar tenant
* (Mandatory) **optype (create-tenant)** is the statement identifier for this statement
* (Mandatory) **tenant** is the only statement parameter that specifies the Pulsar tenant name which can either be dynamically bound or statically assigned.
* Statement **s2** is used for creating a Pulsar namespace
* (Mandatory) **optype (create-namespace)** is the statement identifier for this statement
* (Mandatory) **namespace** is the only statement parameter that specifies the Pulsar namespace under the tenant created by statement s1. Its name can either be dynamically bound or statically assigned.
### 1.4.2. Batch Producer Command Block
Batch producer command block is used to produce a batch of messages all at once by one NB cycle execution. A typical format of this command block is as below:
```yaml
- name: batch-producer-block
tags:
phase: batch-producer
statements:
- name: s1
optype: batch-msg-send-start
# For batch producer, "producer_name" should be associated with batch start
batch_producer_name: {batch_producer_name}
ratio: 1
- name: s2
optype: batch-msg-send
msg_key: "{mykey}"
msg_value: |
{
"SensorID": "{sensor_id}",
"SensorType": "Temperature",
"ReadingTime": "{reading_time}",
"ReadingValue": {reading_value}
}
ratio: 100
- name: s3
optype: batch-msg-send-end
ratio: 1
```
This command block has 3 statements (s1, s2, and s3) with the following ratios: 1, <batch_num>, 1.
* Statement **s1** is used to mark the start of a batch of message production within one NB cycle
* (Mandatory) **optype (batch-msg-send-start)** is the statement identifier for this statement
* (Optional) **batch_producer_name**, when provided, specifies the Pulsar producer name that is associated with the batch production of the messages.
* (Optional) **ratio**, when provided, MUST be 1. If not provided, it is default to 1.
* Statement **s2** is the core statement that generates the message key and payload to be put in the batch.
* (Mandatory) **optype (batch-msg-send)** is the statement identifier for this statement
* (Optional) **msg-key**, when provided, specifies the key of the generated message
* (Mandatory) **msg-payload** specifies the payload of the generated message
* (Optional) **ratio**, when provided, specifies the batch size (how many messages to be put in one batch). If not provided, it is default to 1.
* Statement **s3** is used to mark the end of a batch within one NB cycle
* (Mandatory) **optype (batch-msg-send-end)** is the statement identifier for this statement
* (Optional) **ratio**, when provided, MUST be 1. If not provided, it is default to 1.
### 1.4.3. Producer Command Block
This is the regular Pulsar producer command block that produces one Pulsar message per NB cycle execution. A typical format of this command block is as below:
```yaml
- name: producer-block
tags:
phase: producer
statements:
- name: s1
optype: msg-send
# producer_name: {producer_name}
msg_key: "{mykey}"
msg_value: |
{
"SensorID": "{sensor_id}",
"SensorType": "Temperature",
"ReadingTime": "{reading_time}",
"ReadingValue": {reading_value}
}
```
This command block only has 1 statements (s1):
* Statement **s1** is used to generate the key and payload for one message
* (Mandatory) **optype (msg-send)** is the statement identifier for this statement
* (Optional) **producer_name**, when provided, specifies the Pulsar producer name that is associated with the message production.
* (Optional) **msg-key**, when provided, specifies the key of the generated message
* (Mandatory) **msg-payload** specifies the payload of the generated message
### 1.4.4. Consumer Command Block
This is the regular Pulsar consumer command block that consumes one Pulsar message per NB cycle execution. A typical format of this command block is as below:
```yaml
- name: consumer-block
tags:
phase: consumer
statements:
- name: s1
optype: msg-consume
topic_names: "<pulsar_topic_1>, <pulsar_topic_2>"
# topics_pattern: "<pulsar_topic_regex_pattern>"
subscription_name:
subscription_type:
consumer_name:
```
This command block only has 1 statements (s1):
* Statement **s1** is used to consume one message from the Pulsar cluster and acknowledge it.
* (Mandatory) **optype (msg-consume)** is the statement identifier for this statement
* (Optional) **topic_names**, when provided, specifies multiple topic names from which to consume messages. Default to document level parameter **topic_uri**.
* (Optional) **topics_pattern**, when provided, specifies pulsar topic regex pattern for multi-topic message consumption
* (Mandatory) **subscription_name** specifies subscription name.
* (Optional) **subscription_type**, when provided, specifies subscription type. Default to **exclusive** subscription type.
* (Optional) **consumer_name**, when provided, specifies the associated consumer name.
### 1.4.5. Reader Command Block
This is the regular Pulsar reader command block that reads one Pulsar message per NB cycle execution. A typical format of this command block is as below:
```yaml
- name: reader-block
tags:
phase: reader
statements:
- name: s1
optype: msg-read
reader_name:
```
This command block only has 1 statements (s1):
* Statement **s1** is used to consume one message from the Pulsar cluster and acknowledge it.
* (Mandatory) **optype (msg-consume)** is the statement identifier for this statement
* (Optional) **reader_name**, when provided, specifies the associated consumer name.
**TBD**: at the moment, the NB Pulsar driver Reader API only supports reading from the following positions:
* MessageId.earliest
* MessageId.latest (default)
A customized reader starting position, as below, is NOT supported yet!
```java
byte[] msgIdBytes = // Some message ID byte array
MessageId id = MessageId.fromByteArray(msgIdBytes);
Reader reader = pulsarClient.newReader()
.topic(topic)
.startMessageId(id)
.create();
```
## 1.5. Schema Support
Pulsar has built-in schema support. Other than primitive types, Pulsar also supports complex types like **Avro**, etc. At the moment, the NB Pulsar driver provides 2 schema support modes, via the global level schema related settings as below:
* Avro schema:
@@ -149,7 +355,7 @@ Pulsar has built-in schema support. Other than primitive types, Pulsar also supp
schema.definition:
```
For the previous Producer block statement example, the **msg-value** parameter has the value of a JSON string that follows the following Avro schema definition (e.g. as in the sample schema definition file: **[iot-example.asvc](activities/iot-example.avsc)**)
Take the previous Producer command block as an example, the **msg-value** parameter has the value of a JSON string that follows the following Avro schema definition (e.g. as in the sample schema definition file: **[iot-example.asvc](activities/iot-example.avsc)**)
```json
{
"type": "record",
@@ -164,39 +370,91 @@ For the previous Producer block statement example, the **msg-value** parameter h
}
```
## 1.5. Activity Parameters
## 1.6. NB Activity Execution Parameters
At the moment, the following Pulsar driver specific Activity Parameter is supported:
At the moment, the following NB Pulsar driver **specific** activity parameters are supported:
- * config=<file/path/to/global/configuration/properties/file>
* service_url=<pulsar_driver_url>
* config=<file/path/to/global/configuration/properties/file>
## 1.6. Pulsar NB Execution Example
Some other common NB activity parameters are listed as below. Please reference to NB documentation for more parameters
```
<NB_Cmd> run type=pulsar -vv cycles=10 config=<dir>/config.properties yaml=<dir>/pulsar.yaml
* driver=pulsar
* seq=concat (needed for **batch** producer)
* tags=phase:<command_block_identifier>
* threads=<NB_execution_thread_number>
* cycles=<total_NB_cycle_execution_number>
* --report-csv-to <metrics_output_dir_name>
## 1.7. NB Pulsar Driver Execution Example
1. Run Pulsar producer API to produce 100K messages using 100 NB threads
```bash
<nb_cmd> run driver=pulsar tags=phase:producer threads=100 cycles=100K config=<dir>/config.properties yaml=<dir>/pulsar.yaml
```
**NOTE**:
2. Run Pulsar producer batch API to produce 1M messages with 2 NB threads; put NB execution metrics in a specified metrics folder
```bash
<nb_cmd> run driver=pulsar seq=concat tags=phase:batch-producer threads=2 cycles=1M config=<dir>/config.properties yaml=<dir>/pulsar.yaml --report-csv-to <metrics_folder_path>
```
3. Run Pulsar consumer API to consume (and acknowledge) 100 messages using one single NB thread.
```bash
<nb_cmd> run driver=pulsar tags=phase:consumer cycles=100 config=<dir>/config.properties yaml=<dir>/pulsar.yaml
```
## 1.8. Appendix A. Template Global Setting File (config.properties)
```properties
schema.type =
schema.definition =
### Pulsar client related configurations - client.xxx
client.connectionTimeoutMs =
### Producer related configurations (global) - producer.xxx
producer.producerName =
producer.topicName =
producer.sendTimeoutMs =
### Consumer related configurations (global) - consumer.xxx
consumer.topicNames =
consumer.topicsPattern =
consumer.subscriptionName =
consumer.subscriptionType =
consumer.consumerName =
consumer.receiverQueueSize =
### Reader related configurations (global) - reader.xxx
reader.topicName =
reader.receiverQueueSize =
reader.readerName =
reader.startMessagePos =
```
* An example of **config.properties** file is [here](activities/config.properties)
* An example of **pulsar.yaml** file is [here](activities/pulsar.yaml)
---
# 2. Advanced Driver Features -- TODO: Design Revisit
# 2. TODO : Design Revisit -- Advanced Driver Features
**NOTE**: The following text is based on the original multi-layer API caching design which is not fully implemented at the moment. We need to revisit the original design at some point in order to achieve maximum testing flexibility.
To summarize, the original caching design has the following key requirements:
* **Requirement 1**: Each NB Pulsar activity is able to launch and cache multiple **client spaces**
* **Requirement 2**: Each client space can launch and cache multiple Pulsar operators of the same type (producer, consumer, etc.)
* **Requirement 3**: The size of each Pulsar operator specific cached space can be configurable.
In the current implementation, only requirement 2 is implemented. Regarding requirement 1, the current implementation only supports one client space per NB Pulsar activity!
In the current implementation, only requirement 2 is implemented.
* For requirement 1, the current implementation only supports one client space per NB Pulsar activity
* For requirement 3, the cache space size is not configurable (no limit at the moment)
## 2.1. Other Activity Parameters
- **url** - The pulsar url to connect to.
- **default** - `url=pulsar://localhost:6650`
- **maxcached** - A default value to be applied to `max_clients`,
`max_producers`, `max_consumers`.
- default: `max_cached=100`
@@ -204,13 +462,8 @@ In the current implementation, only requirement 2 is implemented. Regarding requ
instances which are allowed to be cached in the NoSQLBench client
runtime. The clients cache automatically maintains a cache of unique
client instances internally. default: _maxcached_
- **max_producers** - Producers cache size (per client instance). Limits
the number of producer instances which are allowed to be cached per
client instance. default: _maxcached_
- **max_consumers** - Consumers cache size (per client instance). Limits
the number of consumer instances which are allowed to be cached per
client instance.
- **max_operators** - Producers/Consumers/Readers cache size (per client instance). Limits
the number of instances which are allowed to be cached per client instance. default: _maxcached_
## 2.2. API Caching

3
driver-pulsar/src/main/resources/topics.md
View File

@@ -1,3 +0,0 @@
# pulsar help topics
- pulsar