Critical performance issue - PBI Service

Hello

Firstly, my sincere apologies for the dramatic delay in response; there’s been a number of altercations over the past few months, one is that I’m moving on to pastures new in a few  weeks. That said, I’ve been meaning to respond to this post to provide my input & responses to the above for several weeks now(!).

v-qiuyu-msft

Thank you for your response; I skimmed over the insightful Microsoft doc you referred me too and was happy to read that I was following industry ‘best practices’ (except for using PBIs platform to replicate the functionality of SSAS in the absence of SSAS teck) in the overall BI implementation/solution. The  (other) exception was the ‘network latency’ section; this very well could have been a strong factor in this  performance issue, it has always been a serious concern of mine here and had flagged internally. Unfortunately, this matter remains inconclusive.

GilbertQ

Thank you for your response; correct, quite a few. However, as mentioned in my original post was the fact that, due to office circumstances at the time, SSAS teck was NOT being implemented. As I’m sure you know, SSAS is a teck that enables ‘performance tuning’ within its feature-set; since my original post, now that I’ve built, deployed and handling the data processing of the BI solution exclusively in SSAS (once I’d introduced the teck into the office), performance is now “user friendly” as you might expect. Ultimately, just as some offices might “incorrectly” use Excel as a ‘flat file database system’ in a way that the Excel teck isn’t explicitly designed for, PBI was also being used in a way that it isn’t explicitly designed for, and you get ‘real-world’ problems as you might expect.

Thanks all. I am happy for this post to be closed.