Article body
Full article
Data Q&A can feel smooth when a few people take turns trying it. Waiting increases when everyone opens dashboards before a morning meeting, asks follow-up questions, and refreshes charts. Multi-user pressure comes from models, analytics queries, data updates, and page loading, and needs planning around real business workloads.
HENGSHI brings Data Agent, metric analysis, chart applications, and multi-tenant delivery into one enterprise analytics architecture. Teams can organize workloads using data-connection settings, chart-loading methods, caching, engine acceleration, and update schedules, then validate deployment capacity with load tests.
Concurrency planning concerns actual tasks and resources. Online users, model calls, running data queries, and database connections are different measures. Multi-tenant authorization isolation also does not automatically provide fair compute scheduling.
1. Establish What Users Do at Peak Times
| Task type | Main resources it may use | Validation focus |
|---|---|---|
| Natural-language data Q&A and follow-ups | Model services, resource retrieval, analytics tools, and data sources. | Measure model waiting, tool calls, and query duration separately. |
| Simultaneous dashboard opening | Chart queries, data connections, network transfer, and browser rendering. | How many queries one page visit initiates, and which can load on demand. |
| Data updates and complex processing | Source reads, data transfer, engine writes, and processing computation. | Whether these compete with interactive queries and finish in time for the business. |
| Large detail analyses or exports | Query execution, result transfer, and output processing. | Whether result size, execution time, and failure handling are controlled. |
One data question may call several tools, and one dashboard may trigger several chart queries. Count these tasks separately instead of directly converting logged-in user counts into database connection-pool sizes.
2. Reduce Unnecessary Competition with Existing HENGSHI Capabilities
Data Connections: Plan Connection Counts Against Source Capacity
HENGSHI connections for Oracle, StarRocks, and other supported sources provide settings such as maximum connections. Before configuring them, establish the source, deployment nodes, and actual workload, and assess the total connection allowance of the source database. Increasing connections may ease waiting or simply transfer more pressure to the database. Tests should determine which happens.
Check model-service concurrency allowances, data-source connections, and analytics-engine execution capacity separately. They cannot be converted using a fixed multiplier. A default value for one product connection parameter is not the concurrency limit of the entire ChatBI system.
Analytics Applications: Reduce Unnecessary Simultaneous Work
HENGSHI charts support loading methods such as pre-querying and querying on click. Projects can load heavy analyses only when users need them and use chart caching to control repeated queries. For complex processing, assess whether an acceleration engine should hold processed data. Adjusting these paths is often more targeted than simply raising concurrency settings.
Data teams can also maintain common metrics, business knowledge, and analysis templates so that frequent questions have clear analytics objects. This makes business meaning and query scope easier to review. Measure actual reductions in retrieval, reasoning, or query work in the intended scenarios.
Data Updates: Arrange Dependencies and Business Windows
HENGSHI dataset-update schedules support scheduling times, prerequisite dependencies, retries, task priorities, and failure alerts. Teams can prepare some data before business peaks and check that jobs finish as planned. These capabilities apply to the relevant data-update jobs and should not be generalized into unified priority scheduling for every ChatBI request.
3. Validate Data Boundaries and Resource Boundaries Separately in Multi-Tenant Delivery
For software vendors and SaaS scenarios, HENGSHI supports resource distribution and independent management between the platform and tenants. The platform can provide analytics resources to tenants, whose administrators then manage internal access authorization. This helps manage shared analytical capabilities separately from each customer’s resource space.
These authorization and resource-management capabilities should not be described as giving each tenant a separate compute quota by default. If service guarantees are needed per tenant or application, confirm available rate limits, isolation, and quotas in the integration layer, model service, database, or infrastructure. Test whether they actually cover the usage paths.
Embedding also requires clear orchestration responsibilities. When choosing iframe, JS SDK, or API integration, enterprises need to decide which side handles pages and Q&A execution. Concurrency, retries, and cancellation initiated by a custom backend must also enter capacity testing.
4. Test Launch Capacity with Mixed Workloads
Fix data batches, metric definitions, accounts, and permissions first. Establish a single-task baseline, then increase simultaneously running tasks. Record model waiting, query duration, errors, and resource use in each round to see which stage becomes congested first.
| Test dimension | Test arrangement | Question to answer |
|---|---|---|
| Task mix | Combine simple metrics, complex analysis, dashboard loading, and data updates. | Whether mixed operation remains usable when individual tests perform well. |
| Caching and updates | Test initial queries, repeated queries, and queries after updates separately. | Whether results are correct and performance depends on a particular cache state. |
| Roles and tenants | Use several test accounts and tenants with realistic permission structures. | Whether data scope remains correct and other users slow substantially as concurrency increases. |
| Failure and cancellation | Inspect timeouts, request cancellation, retries, and connection failures. | Whether backend work still consumes resources after the frontend operation ends. |
| Completion time | Observe typical duration, P95/P99, and error rates together. | How tail users experience the system even when most requests are usable. |
These measures establish capacity for the current model, data volume, and deployment configuration. They are not a vendor-wide commitment to a fixed number of concurrent users. When adjusting connections or expanding resources, change only the relevant configuration and repeat the same tasks, verifying that an improvement does not become pressure elsewhere.
5. A Multi-User Rollout Example for Retail SaaS
The following is a fictional solution example, not real customer data or measured results. A retail SaaS provider is preparing to deliver HENGSHI analytics to several customers. Stores open operating dashboards during the half-hour before morning meetings, followed by regional managers using ChatBI to investigate anomalies.
The team first maintains sales metrics, store scopes, and tenant authorization, then arranges common dashboards using HENGSHI chart-loading settings and caching. The data team configures operating-data update schedules and verifies completion before the peak. Analyses needing recent changes receive separate query paths and freshness requirements.
Load tests run store dashboards, regional follow-ups, and background data updates together, checking model services, data connections, and engine load. If complex tasks affect interactive use, arrange off-peak execution, limit task sizes, or expand capacity according to the deployment’s actual capabilities. Launch criteria cover response behavior, correct results, and tenant data boundaries together.
6. Use Actual Operating Records to Determine Rollout Scope
HENGSHI capabilities cover data connections, analytics assets, interactive applications, and multi-tenant delivery. Project teams can organize performance improvements across these configurable stages. The public performance FAQ also emphasizes inspecting both data querying and page behavior.
Moving from a pilot to multiple users requires business, data, and technical teams to agree on task scope, update cadence, and capacity targets. Build common analyses into maintainable metrics and applications first, then validate the deployment with real roles and mixed workloads so that expansion rests on actual operating records.