Qps estimation and scaling

Concurrency is measured in QPS (Queries per second), representing the number of valid service requests a server receives per second. Regardless of whether positioning is successful, any request carrying a correct cloud positioning library AppId and passing authentication will be counted towards concurrency statistics.

After successful initialization, devices default to sending positioning requests once per second. Due to network latency and variations in request arrival times, instantaneous concurrency may exceed the QPS limit. For example, 10 QPS theoretically supports 10 devices, but if more than 10 requests are received within the same second, excess requests will be rejected. To ensure service stability in multi-device concurrency scenarios, we recommend reserving redundancy when purchasing QPS. For instance, configure 11-12 QPS to support 10 devices.

The cloud positioning service group defaults to 10 concurrency, sufficient for most application scenarios. For higher concurrency usage scenarios, we offer flexible resource expansion solutions:

During peak periods like holidays, choose short-term expansion packs to temporarily boost concurrency capacity
For applications with large user bases requiring stable high-concurrency support, additional concurrency resources can be bound long-term for the service group's validity period

Based on 10 QPS, you can flexibly choose short-term supplementary packs or long-term fixed concurrency quotas to adapt to resource needs at different business stages.

Behavior during concurrency overrun

When requests instantaneously exceed allocated QPS, the service returns the following error (example):

statuCode： 21, message: "Exceed your QPS limitation"

If trial users fail to locate, it may be due to insufficient QPS. We recommend enabling logs via Mega Toolbox to check response messages. As shown:

qps-limit

Note

Trial users have small concurrency quotas. When positioning fails, pay attention to potential over-limit error messages.

Concurrency qps scaling

You can expand concurrency quotas through two channels:

Offline consultation with sales or customer service (for large-scale, long-term, or customized needs)
Directly upgrade via the management console online (for temporary or minor expansions)

Offline consultation for upgrade

When daily concurrency is expected to exceed 50 QPS, contact EasyAR sales or customer service for capacity expansion and resource assurance. After scaling, log in to the developer backend to confirm quota activation.

The process to confirm concurrency quotas is boxed in the figure below:

Steps:

Developer Center -> Block Cloud Positioning -> Cloud Positioning Service Group -> Current QPS

check-qps

Verify the upgraded QPS quantity and validity period. Check via the EasyAR management interface, described next: Managing Concurrency QPS

Online upgrade

Two console entry points support online QPS upgrades, as shown:

Developer Center -> Block Cloud Positioning -> Cloud Positioning Service Group -> Upgrade
Developer Center -> Block Cloud Positioning -> Cloud Positioning Service Group -> QPS Details -> Upgrade

add-qps

Important

For concurrency demands exceeding 50 QPS, consult sales to ensure stable resource supply.

Managing concurrency qps

Concurrency management primarily includes:

Viewing current QPS quantity
Expanding QPS
Upgrading validity periods for partial QPS

Management interface

Steps

Upgrading qps quantity and validity period

qps-manage

After entering QPS Details, the interface appears as above. Current QPS quantity is marked in the right box.

The timeline in the middle displays validity periods for base QPS and upgraded QPS portions.

Purchase records at the bottom show upgrade orders and validity period details.

Recommendations

Estimate peak rather than average concurrency, reserving redundancy for peaks (e.g., purchase 11-12 QPS for a 10 QPS peak).
Purchase short-term supplementary packs during holidays or events for high-concurrency needs.
Post-expansion verification: Use Mega Toolbox in high-concurrency scenarios to confirm requests aren't rejected and responses are stable.
If encountering persistent rejections or anomalies, collect logs and contact support (include time window, cloud positioning library AppId, and preferably packet captures containing request samples and error codes).

Table of Contents