Embed Workers

Introduction

Holistics' Embedded Analytics feature uses a specific worker type called an Embed Worker. These workers' sole usage is to run jobs generated by the Holistics dashboards that you embedded into your websites or applications.

As you scale your business, you will have more simultaneous embedded dashboard viewers. With more Embed Workers, more viewers can be served at the same time without being blocked by other viewers.

For more details about how Holistics handles concurrent reporting jobs, please refer to the Job Queue System and Workers documentation.

Embed Workers vs. internal workers

• The Embed Workers only impact external-facing embedded dashboards and do not handle internal reporting jobs.
• While users cannot manually configure the number of internal workers, they can freely enable/disable and change the number of embedded workers.

How to configure Embed Workers

Embed Workers can be toggled and increased from the Embedded Analytics Manager in the Holistics application.

How does caching work in different scenarios with our workers?

Holistics enable 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.