You can update default Rule Engine queues configuration (poll interval and partitions) using UI. # Sample parameters to fit into 10 requests per second on a "monolith" deployment: export TB_QUEUE_CORE_POLL_INTERVAL_MS =1000Įxport TB_QUEUE_RULE_ENGINE_POLL_INTERVAL_MS =1000Įxport TB_QUEUE_TRANSPORT_REQUEST_POLL_INTERVAL_MS =1000Įxport TB_QUEUE_TRANSPORT_RESPONSE_POLL_INTERVAL_MS =1000Įxport TB_QUEUE_TRANSPORT_NOTIFICATIONS_POLL_INTERVAL_MS =1000
# By UI set the parameters - interval (1000) and partitions (1) for Rule Engine queues. # Number of requests to particular Message Queue is calculated based on the formula: # ((Number of Rule Engine and Core Queues) * (Number of partitions per Queue) + (Number of transport queues) # + (Number of microservices) + (Number of JS executors)) * 1000 / POLL_INTERVAL_MS # For example, number of requests based on default parameters is: # Rule Engine queues: # Main 10 partitions + HighPriority 10 partitions + SequentialByOriginator 10 partitions = 30 # Core queue 10 partitions # Transport request Queue + response Queue = 2 # Rule Engine Transport notifications Queue + Core Transport notifications Queue = 2 # Total = 44 # Number of requests per second = 44 * 1000 / 25 = 1760 requests # Based on the use case, you can compromise latency and decrease number of partitions/requests to the queue, if the message load is low. # These params affect the number of requests per second from each partitions per each queue. See corresponding architecture page and rule engine page for more details.Įxport TB_QUEUE_AWS_SQS_ACCESS_KEY_ID =YOUR_KEYĮxport TB_QUEUE_AWS_SQS_SECRET_ACCESS_KEY =YOUR_SECRETĮxport TB_QUEUE_AWS_SQS_REGION =YOUR_REGION Useful if you plan to deploy ThingsBoard on Azure.Ĭonfluent Cloud is a fully managed streaming platform based on Kafka. Useful if you plan to deploy ThingsBoard on Google Cloud.Īzure Service Bus is a fully managed message queuing service from Azure. Google Pub/Sub is a fully managed message queuing service from Google. Useful if you plan to deploy ThingsBoard on AWS. RabbitMQ is recommended if you don’t have much load and you already have experience with this messaging system.ĪWS SQS is a fully managed message queuing service from AWS. However, some providers also have managed services for Kafka. It is also useful if you like to stay independent from your cloud provider. It is useful for both on-prem and private cloud deployments.
This queue is used on the most of ThingsBoard production environments now. Kafka is recommended for production deployments. It is useful for development(PoC) environments and is not suitable for production deployments or any sort of cluster deployments. In Memory queue implementation is built-in and default.
#Run lunch as sudo user how to#
How to choose the right queue implementation? ThingsBoard is able to use various messaging systems/brokers for storing the messages and communication between ThingsBoard services. The current value corresponds to one week. export SQL_TIMESCALE_CHUNK_TIME_INTERVAL =604800000 # Number of miliseconds. Please note that this value can be set only once. # Specify Interval size for data chunks storage. # DB Configuration export DATABASE_TS_TYPE =timescaleĮxport SPRING_DATASOURCE_URL =jdbc:postgresql://localhost:5432/thingsboardĮxport SPRING_DATASOURCE_USERNAME =postgresĮxport SPRING_DATASOURCE_PASSWORD =PUT_YOUR_POSTGRESQL_PASSWORD_HERE
0 kommentar(er)
