Duur verversen Power BI service varieert sterk

Vraag: Waarom is de duur van verversen zo inconsequent? Zoals te zien duurt een refresh soms enkele minuten tot een uur. Een andere keer wordt een foutmelding gegeven. Ik heb al de data <2022 in een dataflow gezet zodat dit eenmalig ververst hoeft te worden. Ondanks dat blijft het traag.

Afbeeldingen:



Foutmelding PowerBI online:

Data source error:
OData:
Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host…
The exception was raised by the IDataReader interface.
Please review the error message and provider documentation for further information and corrective action.
Cluster URI: WABI-NORTH-EUROPE-redirect.analysis.windows.net
Activity ID: 8aafe282-14c5-40f8-95d6-12b1a252bde7
Request ID: 6b1c3ffe-031d-681e-2d48-9fac5a2441b4
Time: 2022-09-23 07:20:35Z

Query PowerBI: (let op deze is voor <=2021. Eenzelfde wordt gedraaid voor 2022)

let
    Bron = OData.Feed("https://bridge-online.cloud/acme-twinfield/odata4", null, [Implementation="2.0"]),
    #"Twinfield.Twinfield.GeneralLedgerDetailsV3@tfd_table" = Bron{[Name="Twinfield.Twinfield.GeneralLedgerDetailsV3@tfd",Signature="table"]}[Data],
    #"Filtered Rows" = Table.SelectRows(#"Twinfield.Twinfield.GeneralLedgerDetailsV3@tfd_table", each ([FIN_TRS_HEAD_YEAR] <= 2021)),
    #"Removed other columns" = Table.SelectColumns(#"Filtered Rows", {"COMPANY_NAME", "CODE", "NUMBER", "FIN_TRS_HEAD_DATE", "FIN_TRS_HEAD_PERIOD", "FIN_TRS_HEAD_RELATION", "FIN_TRS_HEAD_RELATIONNAME", "FIN_TRS_LINE_BASEVALUESIGNED", "FIN_TRS_LINE_DESCRIPTION", "FIN_TRS_LINE_DIM1", "FIN_TRS_LINE_DIM1GROUP1", "FIN_TRS_LINE_DIM1GROUP1NAME", "FIN_TRS_LINE_DIM1GROUP2", "FIN_TRS_LINE_DIM1GROUP2NAME", "FIN_TRS_LINE_DIM1NAME", "FIN_TRS_LINE_DIM1TYPE"}),
    #"Renamed Columns" = Table.RenameColumns(#"Removed other columns",{{"COMPANY_NAME", "Adm_naam"}, {"FIN_TRS_HEAD_DATE", "Boekdatum"}, {"NUMBER", "Boekingsnummer"}, {"CODE", "Dagboek"}, {"FIN_TRS_LINE_DIM1", "Grootboekrek"}, {"FIN_TRS_LINE_DIM1NAME", "Grootboekrek_naam"}, {"FIN_TRS_LINE_DESCRIPTION", "Omschrijving"}, {"FIN_TRS_HEAD_PERIOD", "Periode"}, {"FIN_TRS_HEAD_RELATION", "Relatie"}, {"FIN_TRS_HEAD_RELATIONNAME", "Relatienaam"}, {"FIN_TRS_LINE_BASEVALUESIGNED", "Bedrag"}, {"FIN_TRS_LINE_DIM1GROUP1", "Groep 1"}, {"FIN_TRS_LINE_DIM1GROUP1NAME", "Groepnaam 1"}, {"FIN_TRS_LINE_DIM1GROUP2", "Groep 2"}, {"FIN_TRS_LINE_DIM1GROUP2NAME", "Groepnaam 2"}})
in
    #"Renamed Columns"

Er zijn twee vragen:

  • waarom wisselt de duur sterk
  • waarom komt er soms een foutmelding

Verzoek is om voor de laatste een losse thread te starten.

M.b.t. de wisselende duur: dit kan van veel factoren afhankelijk zijn binnen Twinfield, Invantive Cloud en het rapport.

Voor het deel Invantive Cloud zijn een aantal factoren die een rol kunnen spelen te benoemen. Het rapport gebruikt een filterstap waardoor alle boekingen t/m 2021 opgehaald worden. Het is niet bekend of dit veel of weinig boekingen zijn. Mocht daar informatie over zijn, gelieve die toe te voegen.

Belasting

De systeembelasting van Invantive Cloud kan van invloed zijn, evenals de netwerkbelasting. Het is aan te raden de netwerkbelasting te minimaliseren door de instellingen te gebruiken zoals beschreven in Vermijd time-out fout bij Power BI OData download. Voor specifiek Twinfield beperkt het gebruik van ODataVersion=4, OmitValues=ODataOmitValues.Nulls het datavolume vaak met meer dan 95%. In dit geval zal het minder zijn omdat er specifieke kolommen gekozen worden.

De verwachting is dat de systeembelasting geen grote rol speelt. Die kan wel leiden tot enige variatie maar meestal niet met een dergelijk grote factor.

Caching

De caching van de data kan een grote rol spelen. Merk op dat Invantive Bridge Online werkt met real-time data uit Twinfield, behoudens dat een vraag vaker opnieuw gesteld wordt in een geconfigureerde tijd. Het ene antwoord komt uit de cache en het andere wordt vers opgehaald. Advies is om in Invantive Bridge Online Monitoring te kijken of het vinkje “Uit cache” aangevinkt is of niet. Zie ook Differentieer OData4 cachegedrag met Power BI.

Als het om relatief veel data gaat, dan is het niet aan te raden om deze dataset hoogfrequent op te halen.

Maximale Capaciteit

Voor het gebruik binnen een abonnement zijn er limieten aan de capaciteit die een gebruiker gegund wordt. De voornaamste factor hierin is het maximaal aantal gelijktijdige downloads over alle gebruikers van dat abonnement heen. Meestal is dat vier. Dit betekent dat er vier rijstroken heen die door alle downloads gedeeld worden. Indien een andere gebruiker 8 downloads tegelijk start, zullen de rijstroken enige tijd bezet blijven. Een andere downloadgebruiker die even later een download start, zal dan moeten wachten. Dergelijke vertragingen qua maximale capaciteit (en de zusjes voor authenticatiefouten en identieke verzoeken) zijn zichtbaar in Invantive Bridge Online Monitoring.

Twinfield

De prestaties van achterliggende platformen kunnen variëren. Normaliter niet in dergelijke mate, maar toch. Hier hebben we geen inzage in. Mogelijkerwijs dat men zelf hier ergens de situatie van inzichtelijk maakt zoals dat voor de Invantive-producten zichtbaar is op Status page expanded with throughput and Exact Online measurements (Engels).

PowerBI en rapporten

De prestaties van PowerBI en een rapport kan variëren. Ook hier hebben we geen inzage in.

Mocht dit niet helpen, gelieve dan als antwoord toe te voegen:

  • een geanonimiseerde schermafdruk van een snel en een langzaam verzoek uit Bridge Online Monitoring;
  • het aantal rijen per jaar in de dataset toe te voegen als een tabel.

Dank allereerst voor de reactie. Ik heb bewust een dataflow in PowerBI aangemaakt voor alle transacties van voor 2022. Daardoor wordt niet alles opgehaald. Aantal boekingen van voor 2022 bedraagt ongeveer 360.000 regels.

Belasting
Aanvullingen specifiek voor Twinfield verwerkt.

Caching
Over het algemeen staat het vinkje aan.

Maximale Capaciteit
Dit zou niet van toepassing kunnen zijn, omdat ik alleen de download heb uitgevoerd bij deze specifieke klant.

Na de aanpassing onder belasting lijkt de verversing een stuk stabieler te zijn.

Overigens valt mij op dat in de Bridge Online Monitoring 5x de query wordt uitgevoerd. Terwijl ik 3x zou verwachten. Eigenlijk wil ik dat beperken tot 1 keer.

Fijn de stabieler werkt.

Algemeen advies is om altijd de checklist na te lopen zoals beschreven op Wat zijn de aandachtspunten om een nieuwe klant op Power BI te implementeren?.

Als het vinkje bij “Uit Cache” aanstaat, dan zal het antwoord vlot terugkomen en afhankelijk zijn van de downloadsnelheid. Het betreft dan wel mogelijk verouderde data. Dit kan verklaren waarom het soms snel en soms langzaam is. Langzaam is zonder cache, snel is met cache. De cacheduur kan zoals beschreven aangepast worden.

Merk op dat de maximale capaciteit niet per gebruiker is, maar over alle gebruikers van een organisatie heen. Wordt er met 5 personen tegelijk per persoon een download in 8-voud parallel gedaan, dan zouden in principe 40 rijstroken nodig zijn. Dit wordt geblokkeerd en beperkt tot (meestal) 4 (afhankelijk van de abonnementsvorm).

Het lukt niet om de opmerking over “5x de query wordt uitgevoerd” te interpreteren. Indien relevant, gelieve hiervoor een apart topic te maken. Vermeld in dat topic middels een schermafdruk wat er bedoeld wordt en waarom 3x of 1x ook zou kunnen.

Wat betreft de maximale capaciteit. Ik ben als tijdelijke gebruiker toegevoegd aan een omgeving van een klant. In het account van de klant ben ik de enige die gebruik maakt van Invantive. Daarom zou dit geen probleem moeten zijn.

Dat is correct; het ontwerp is dusdanig dat bij gebruik Delegatie de maximale capaciteit behorende bij het geselecteerde abonnement van de klant gebruikt wordt. Als daar geen andere gebruikers actief zijn, dan zijn alle downloadsloten beschikbaar.

Mocht de maximale capaciteit een keer een bottleneck zijn, dan is dat ook snel zichtbaar door hoge waardes in de Monitoring onder “Vertraging op Maximale Gelijktijdigheid (ms)”.