Searching for parameters ... so painfully slow

[dbeavon3]

OK, I know that there is a bunch of back-end stuff that it is doing to recalculate gateways, data sources, and on and on.

But if I edit a normal, standard, boring parameter, I just want it to save my changes in a second.  I don't want to sit there for 60 seconds while it shows me a spinning circle and says "Searching for parameters".

Who does the QA testing of this awful PBI portal?  How can this behavior be acceptable?  This seems like the most basic of U/I design flaws.  It shouldn't be rocket science to figure out how to change a parameter, hit save, and not have to sit and wait for 60 seconds.  

I blame the community for giving Microsoft a very low bar to pass, and allowing them shove really bad U/I design into their PBI portal.  I know web-based U/I is generally pretty bad... however I have to believe you guys have encountered much better U/I on the Internet than this, right!?

[v-mengzhu-msft]

Hi @dbeavon3 ,

According to your description, you mentioned that the display speed of this function is slow, so I also did a test on this function, I first set a parameter in desktop and applied this parameter, then I published the report to the service, and when I checked the function "parameter", the loading speed only took 2~3 seconds; so I considered the influence of the number of parameters, I added one more parameter and applied two parameters in the report at the same time, and after re-publishing, I found that the display speed is still fast, and not as long as 60s as you said.

Therefore, this feature should be fine by design, perhaps related to the speed of your browser? You may consider trying a different environment to see if it still loads slowly.

Best regards,

Community Support Team Selina zhu

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[dbeavon3 · Accepted solution]

Hi @v-mengzhu-msft 

I did some more investigation too.  I think what is happening is that there is a handshake being done between the service and the on-prem datasource.  I think this happens thru the on-prem-data-gateway (OPDG).

The U/I is, unfortunately, obfuscating the complex interactions that happen under the hood.  It is likely that while the settings page says "searching for parameters", it is meanwhile waiting on round-trips to the OPDG, and possibly even to the underlying data source as well (built-in connectors, and/or custom connectors).

It would be really nice if customers of the PBI service could download an activity log with diagnostic information.  There needs to be explain what we are waiting on for ~60 seconds.  Most services have some basic level logging that is available for troubleshooting purposes, but I haven't found that in the Power BI service yet.

I intend to enable the extended logging capabilities of the OPDG and see if I can find anything on that side.  

If the U/I was a tiny bit better, then the answer to these questions wouldn't be so mysterious.  For example, U/I should say ... waiting on OPDG ... or something simple like that, and it would eliminate a great deal of confusion!