
<p>Here at Sisense we support <a href="https://documentation.sisense.com/latest/administration/high-availability-in-sisense/high-availability.htm">high-availability</a>, multi-server deployments for scalability and flexibility. In fact, these deployments are ready to go, out of the box and are common at most of our customer’s sites.</p>



<p>While this type of deployment meets the performance demands of most customers, we recently had a large customer come to us wanting to get even more out of their system. We decided to customize a solution using out of the box Sisense capabilities to meet their specific requirements.</p>



<p>Here’s what we did.</p>



<h2 class="wp-block-heading">Step 1: Investigate</h2>



<p>If we take a look at a common architecture schema with a high availability environment, you may find, for example, a database layer, a build layer with one build node, a query and web layer with two query nodes and two web nodes, and a load balancer. Just like the image below:</p>



<div class="wp-block-image"><figure class="aligncenter"><img decoding="async" src="https://cdn.sisense.com/wp-content/uploads/scen1HA.png" alt="Sisense System Architecture "/></figure></div>



<p>In an environment like this, an end user sends a request through the load balancer to one of the two web nodes,  with no discretion to which they are using. By default, the web nodes then run the query on one of the two query nodes and return the response to the request to the end user.</p>



<p>It’s important to keep in mind that each query node stores every query in the machine’s memory. So, let’s say that each of the query nodes has 500GB of RAM. Once the node gets to a predetermined threshold of RAM space left, the server automatically starts to clean up the queries to free up available RAM.</p>



<p><strong><font size="5">Which software stack is right for you? Find out with our <a href="https://www.sisense.com/whitepapers/software-stack-selection/">ultimate comparison guide.</a></font></strong><strong><font size="5">
</font></strong></p>



<font size="5"></font>



<p><font size="5"><strong></strong></font><br>
</p>



<h2 class="wp-block-heading">Step 2: Brainstorm</h2>



<p>Therein lies our question: Why is there lag time in answering a query if the query nodes clear their cache once RAM reaches a maximum capacity? How can we reduce frequency without purchasing more RAM space?</p>



<p> started by mapping and roughly measuring the dashboards and how much RAM was utilized when queried. Because both of the query nodes have ~500GB of RAM in our example, I wanted to understand how much of it will be utilized and how often the cleaning process will occur. For example:</p>



<style>
table, th, td {<br />
    border: 1px solid black;<br />
    border-collapse: collapse;<br />
}<br />
th, td {<br />
    padding: 10px;<br />
}<br />
</style>



<div class="table-responsive"><figure class="wp-block-table table table-bordered"><table class=""><tbody><tr><th>Dashoard Number</th><th>Type</th><th>Capacity</th></tr><tr><td>1</td><td>Customer Churn</td><td>100 GB</td></tr><tr><td>2</td><td>Finance</td><td>50 GB</td></tr><tr><td>3</td><td>Sales</td><td>35 GB</td></tr><tr><td>4</td><td>Help Desk Tickets</td><td>100 GB</td></tr><tr><td>5</td><td>Executive</td><td>50 GB</td></tr><tr><td>6</td><td>Leads Analysis</td><td>60 GB</td></tr><tr><td>7</td><td>Lead Generation</td><td>400 GB</td></tr><tr><td>8</td><td>Customer Satisfaction</td><td>200 GB</td></tr><tr><td><strong>TOTAL CAPACITY</strong></td><td> </td><td><strong>995 GB</strong></td></tr></tbody></table></figure></div>



<p>After listing out the dashboards and realizing that the total capacity is less than 1TB, I needed to look at the actual functionality of the different nodes. Each web node has the same metadata and each query node has the same <a href="https://www.sisense.com/product/mash-up/elasticube/">ElastiCube</a> (Sisense’s super-fast data stores). So, when one end user asks a question and it’s directed to query node A, the answer gets “stored” there. However, if another end user asks the same question and it gets directed to query node B, it will be “stored” there too.</p>



<p>Ah-ha! This is not efficient. We’re storing the same answers twice on two different query nodes. This means, for example, that 5GB RAM query can take up a total of 10GB when stored on both query nodes. Moreover, this expedites the time interval for when the RAM will have to be flushed. Let’s try and reconfigure the architecture to fix it and find out.</p>



<h2 class="wp-block-heading">Step 3: Test and Expand</h2>



<p>To eliminate having the same queries saved on both query nodes’ RAM, I needed to create a structure that told the web nodes which query node to use based on which dashboard was being used.</p>



<p>If we use the example list of dashboards from above, I made sure that if dashboard 1, 3, 4, 6, and 8 were being used, the queries should be sent to query node A. If dashboards 2, 5, or 7 were being used, then the question should be sent to query node B. This means breaking the ElastiCube set and directing each dashboard to a dedicated query node. Doing so would eliminate our redundancy on the query layer.</p>



<p>For reliability purposes, if one of the query nodes is down, we want to have a fallback option that ensures all queries will succeed, even at the expense of performance. The solution was creating new ElastiCube sets like this:</p>



<p>Set 1: The cube on query node A is <strong>default</strong>, the cube on query node B is the <strong>fallback.</strong></p>



<p>Set 2: The cube on query node B is <strong>default</strong>, the cube on query node A is the <strong>fallback.</strong></p>



<p>The fallback cube does not participate in the ElastiCube Set round-robin routing and is not typically used. The fallback cube is only used when none of the other cubes in the set are available.</p>



<p>Now, specific queries are always routed to the same caches. Because the queries are not duplicated in both caches the available RAM across both caches is better utilized to store a larger amount of queries.</p>



<p>After testing this architecture and ensuring it works for all scenarios with two query nodes we expanded the capabilities to allow more than two query nodes if needed. Success!</p>



<h2 class="wp-block-heading">So, What’s The Big Deal?</h2>



<p>To put it simply: the ability to boost performance without having to add additional hardware reduces <a href="https://www.sisense.com/blog/business-intelligence-total-cost-of-ownership/">total cost of ownership</a>. Most people can meet their performance demands with a standard high-availability set up. But for those who can’t, and who have the abilities to manage this new solution, this is an exciting discovery. </p>



<div class="wp-block-image"><figure class="aligncenter"><a href="https://www.sisense.com/whitepapers/software-stack-selection/"><img decoding="async" src="https://cdn.sisense.com/wp-content/uploads/banner-blog_3.jpg" alt="What BI architecture is right for you? Find out now with our Ultimate Data Warehousing Selection Sheet"/></a></figure></div>


Software Performance Issues? It Might be Your Architecture.

LinkedIn

Twitter

GitHub

curve-image-unique-image-unique

curve

3-dark-2-image-unique-image-unique

3 DARK 2

Get the latest in analytics right in your inbox.

Article