Embed Workers

Embedded Analytics - Embed Workers

Holistics' Embedded Analytics feature uses a specific worker type called an Embed Worker. These workers solely usage is to support your embedding of Holistics's Dashboards into your webpage or app.

As you scale your business, you will have increasing simultaneous dashboard viewers. This inevitably slows down the querying process as multiple SQL queries are sent to your database at the same time. Embed Workers come in to ensure that the process of querying these visualizations becomes a smooth process for all your customers. The more Embed Workers you have, the faster your customers get the results they need.

Embed Workers can be toggled and increased from the Embedded Analytics Manager (link) The minimum number Embed Workers required for our Embedded Analytics featured is 3 with a (current) maximum of 9.

Info

• The Embed Worker functions differently from other internal workers, as it only impacts external embedded analytics.
• Unlike internal workers, which cannot be manually increased by users, embed workers in embedded analytics can be activated and increased by the user.

How does caching work in different scenarios with our workers?

Holistics enables caching of query results, reducing the workload on workers when an embedded viewer accesses a previously viewed dashboard.

Let's consider a company 'A' with 2000 viewers (A1, A2,...A2000). The default dashboard filter is uniform for all users within the company, and each user loads 5 widgets.

Option 1: Embedding a company-level dashboard (default filter at the company level) without custom viewer filters:

• User A1 facilitates loading dashboards for all based on default filters (triggering cache, where workers' impact is minimal unless viewers apply different filters).
• This serves the 2000 viewers without affecting initial load time, retrieving data directly from the cache.

Option 2: Embedding a user-level dashboard (applying filters at the viewer level):

• Holistics dashboard filters apply a "WHERE" clause to each widget's SQL syntax, sending unique queries to the database if not found in the cache.
• Assuming all users view the dashboard simultaneously with different filters, this generates 10000 unique SQL queries (5 reports x 2000 users) for processing.
• Dashboard load time depends on concurrent workers and query runtime.

Diving into Option 2, with 5 widgets taking 2 seconds each and 5 concurrent workers:

• Each user loads 5 widgets (5 queries), each taking 2 seconds.
• With 5 workers and 5 widgets, it takes 2 seconds for each user to load a dashboard.
• When all 2000 users view the dashboard simultaneously, it takes roughly 66.6 minutes to load, considering query runtime and concurrent workers.

The decision on load times rests on query runtime and concurrent workers, letting you balance cost vs viewer experience and decide whether to invest in more workers.