Power BI Premium Performance – Part 4 | How does Row Level Security affect performance?
In the third part of my blog series on Performance, this time I am going to see how Row Level Security will affect performance.
RLS is an awesome feature when you want to ensure that only the relevant people can view their data and not see other data.
Row Level Security (RLS) is where I can create roles which can be manual, or I can create dynamic RLS where there is one role and based on the user who logs in it then dynamically assigns their security.
Personally, this was something that I was really interested in, because I have read in the past that each user will be assigned their own memory cache, because users cannot share cache when viewing a different slice of the data.
If this is your first time here, you can read about just first blog post in the series Power BI Premium Performance – Part 1 | How to use the new XMLA End Point to see how much memory your datasets are using
If you are interested in the second blog post in the series you can read it here: Power BI Premium Performance – Part 2 | Optimization of your Power BI Model
My third blog post you can find here in the series: Power BI Premium Performance – Part 3 | How does a dataset refresh affect performance?
NOTE: In order to get more granular details, I have done all my metrics using Azure Analysis Services, which allowed me to use the Log Analytics to capture the events I require.
For all the tests below, I had created the 4 roles which all ran at the same time to see how this would affect the performance.
What happens when multiple people are accessing data using RLS?
In the chart below, I tried 2 different approaches to see if there would be a big increase in the memory utilisation.
In this test what I did was to use the query developed by the good people from SQLBI.COM where I could test the hardware for Analysis Services Tabular
I ran a modified query from the above link to ensure that the query would run for long enough to see any impact over time.
The results I did see is an increase in the memory, but this was to be expected. Due to having the 4 users all running their QPU intensive queries at the same time.
In this test I had 4 Power BI desktop files all logged in as the 4 different users.
I then had reports created, where I interacted with the reports click on different visuals, dragging and dropping items into the reports.
I was looking to test multiple RLS users using Power BI reports at the same time.
The results once again, I did see an increase in memory and QPU, but there was no significant increase. But rather following then standard pattern.
I really learnt a lot by getting this done
My most important learning experience is that it appears that when using RLS it does NOT significantly increase the memory.
I also wanted to see if I would get the same outcome on SSAS Tabular 2017 On-Premise and I got the same results, where there was no significant increase in the memory.
Once again thanks for reading my blog post. I do hope that you found it interesting.
As always if anyone has got any other findings or advice, I would appreciate putting it in the comments below.