Is there any maximum size limit and data storage limit when using Power BI Report Server?

This time with some formatting! I have had to edit this as I discovered I was talking total rubbish, explanation inline

So this is quite a complex question to answer. (most of this is my opinion rather than being anything I'd bet the ranch on)

There is a limit to the size of files you can upload to the on Prem Server. Its controlled via a config setting and seems to be set to 1000Mb. I assume it responds if you change it, we haven't had to change this so I can't comment. The last set of release notes suggested this had been raised to 2Gb. (Remember this is the vertipaq compressed size so the uncompressed data can be several times larger than this)

Be aware that PowerBI-SSRS is not just a web app. In the background it spins up a captive SSAS TAB instances for PBIX files that have imported data. This captive instance can consume quite large quantities of memory if you get a number of data sets loaded into it concurrently so you may need to give your SSRS-PBI Server some more memory so it can breath if you have moderate to high concurrency.

A slightly longer explanation of what I understand happens is included here https://community.powerbi.com/t5/Report-Server/Needed-instances-for-PowerBI-report-server/m-p/445068...

The web services that are part of PBI-SSRS that provide the data to your rendered client apps are also quite chatty. Every time a user slices/hilights/drills on a visual/page a set of queries is sent to the backend data source, either the captive SSAS instance or the actual backend if the PBIX is using Direct Query or Live connection. So be prepared for a fair amount of network chatter between the PBI-SSRS and your data sources if you are using Direct Query or Live connection. This is one reason we keep them on the same server/servers.

I would suggest that if your imported data PBIX is 5Gb it would probably be way more efficient to translate this into a SSAS tabular instance and host it there. Then connect your PBIX to that SSAS tabular instance using LiveQuery.

If you compare the two from a memory consumption point of view (all numbers are taken from looking at our internal servers here)

Using SSAS TAB backend with live query connection

SSAS Tab memory usage 700mb

SSAS Tab data usage 5gb

PowerBI SSRS (underlying services) 1.8Gb

Each user viewing Report about 50Mb (this is a guess, it could well be half this or double this, It's hard to see without a lot of work looking at memory allocations inside the processes) of SSRS services/visualisation

Assume 5 concurrent users giving you 250Mb

That's a grand total of about 8Gb + room for your OS, scale this to 25 concurrent users and its only 1-2Gb more

The report will load fast (its just the visuals and then you are querying the SSAS Tab model so how responsive it is, will be down to your model/data design/DAX)

Now lets think about hosting the 5GB PBIX (assuming you can and the server doesn't have some fixed limit)

My original assumption here was that each report viewer got their own SSAS TAB instance. This isn't the case the server fires up one SSAS TAB instance and shares it across the users, pushing data into it as required (as reports are requested) It looks like it keeps that data resident so only the first person who uses a data set takes the hit, though it may well unload it after its not been used for a while. You certainly get multiple connections to each model in the captive instance. My misreading of what was going on on the server is because we had a user remoting on to our dev box and firing up PBI Desktop. Hence I was seeing different numbers of msmdsrv.exe instances. I had incorrectly assumed this was the PBI-SSRS server. So my initial estimate was pretty spectacularly wrong.

SSAS Tab memory usage 0

SSAS Tab data usage 0

PowerBI SSRS (underlying services) 1.8Gb

First user cause 5Gb data load into captive SSAS Instance

Each user viewing the PBIX about 50Mb (this is a guess, see notes above) of SSRS services/visualisation

Assume 5 concurrent users and you get 250mb

Giving you a grand total of about 8Gb again + room for your OS, scale this to 25 concurrent users and it's pretty similar

Now lets think about someone accessing one of those reports. The first report has to spin up the 5Gb of data in the captive SSAS Instance before it can even start to render any data. That's several seconds at best. So its going to feel pretty unresponsive initially. But much the same after that as users slice and dice the reports etc. Also the second user onwards won't pay this hit. They'll get the same kind of response as you would using a separate SSAS Instance. So it looks like we can do some good old fashioned cache warming by spinning the PBIX reports up in the mornings before the users get in, or after data refreshes happen.

I do wonder what happens if the data gets refreshed in the PBIX, does this trigger the data in the captive SSAS Instance to be reloaded. And does this flood out to end users already connected to that data set? Might need to see if I can figure this out. An initial scan of the data models suggest this happens transparently. 

I would still probably suggest that for anything bigger than 1Gb that's going to have fairly widespread usage (potentially several concurrent users) its more scaleable and practical to import the PBIX into SSAS Tabular and host it there with a LiveQuery connection to the SSAS model. You get some control over this SSAS instance that just doesn't seem to be as easily available in the embedded data model captve SSAS instance.

These splitting of the report into visuals and data means when someone is calling up a report, all the server has to do is ship the visuals to them and spin up some web services. The data is already in memory in the SSAS Tab instance in direct query mode. After that the traffic is from the web browser as the user queries/slices/dices to the web services and in turn to the data source. The same could be said for data loaded into the captive instance of course once the first user has spun that data up.

Apologies if that doesn't make any sense or isn't what you were asking. And further apologies for talking rubbish the first time around.

S