Samenvatting
De onderstaande tekst is ook verwerkt in het samenvattingsartikel Vermijd time-out fout bij Power BI OData download.
Er is gisteren nog 1 andere vrijwel identieke melding geweest van een gebruiker over een “request failed” error waarbij van de 20 keer verversen op Power BI Service de OData refresh maar 2 keer slaagt. Ook hier is de voornaamste foutmelding:
| Aspect |
Waarde |
| Melding |
OData: Request failed: The operation has timed out |
| Start |
1-11-2021 20:19:16 |
| Einde |
1-11-2021 21:13:08 |
Bijzonder is dat deze “request failed: The operation has timed out” error optreedt ruim voor middernacht. Zelfs met een tijdzoneverschil van 2 uur (het is niet duidelijk of de tijden in CET of UTC zijn) is dit ruim voor herstarttijden van bijvoorbeeld Exact Online API servers en langdurige patches. We kunnen daarom storingen op het achterliggende platform als oorzaak uitsluiten.
Vergelijkbare melding “Request failed: The operation has timed out”
De error “The operation has timed out” is sterk gelijkend op de Power BI problemen beschreven op Data laden vanuit OData (Bridge-Online) werkt niet meer. Toendertijd was het echter duidelijk te wijten aan een te zware belasting voor de Invantive Cloud-infrastructuur. Nu treedt het probleem - zoals ik begrijp uit reacties per e-mail - alleen op via PowerBI.com en niet bij verversen via Microsoft Power BI Desktop. We kunnen daarom de Invantive Cloud-infrastructuur daarom uitsluiten als oorzaak.
Limiet Data
Power BI en vooral Power BI Service (PowerBI.com) heeft een aantal limieten. De maximale hoogte is afhankelijk van de licentievorm, waarbij duurder niet altijd beter is. Denk bijvoorbeeld aan een 1 GB limiet op zowel gratis als Power BI Pro voor een datamodel van een PBIX waar omheen gewerkt kan worden door de dataset op te knippen in kleinere.
Limiet Looptijd
De maximale loopduur van een query is verschillend. De standaard maximale loopduur van een OData feed is 10 minuten (zie documentatie OData.Feed). Per OData-feed kan de limiet gewijzigd worden in de Advanced Editor, zoals met:
let
Bron = OData.Feed("https://bridge-online.cloud/3279/odata4/", null, [Implementation="2.0", Timeout=#duration(0,2,0,0)]),
#"Teamleader.V2.Projects@tlr_table" = Bron{[Name="Teamleader.V2.Projects@tlr",Signature="table"]}[Data]
in
#"Teamleader.V2.Projects@tlr_table"
De cruciale en enige benodigde aanpassing is het aanpassen van de regel:
Bron = OData.Feed("https://bridge-online.cloud/3279/odata4/", null, [Implementation="2.0", Timeout=#duration(0,2,0,0)]),
in
Bron = OData.Feed("https://bridge-online.cloud/3279/odata4/", null, [Implementation="2.0"]),
Hierdoor zal er twee uur i.p.v. 10 minuten gewacht worden.
Waar zit de advanced editor / geavanceerde editor?
Update De “advanced editor” is in Power BI te vinden in het venster dat omhoogkomt bij keuze van “Gegevens transformeren” in het lint:
Kies daarna voor “Geavanceerde editor” bij een query:
Tijdsduur
In dit voorbeeld geeft #duration(0, 1, 50, 40) een (arbitrair gekozen) tijdsduur weer van 1 uur, 50 minuten en 40 seconden. De syntax van #duration is online te vinden in de Power Query M documentatie.
De maximaal limiet voor een OData feed is voor Power BI Pro 120 minuten en voor Premium 300 minuten (documentatie).
Er is bij mij op dit moment geen manier bekend om de timeout centraal in te stellen op de OData-bron zoals dat wel kan met sommige andere bronnen via “data source settings”.
Merk op dat voor dataflows weer andere timeouts gelden (2 uur voor tabel, 3 uur voor dataflow, 24 uur met Premium).
Time-outs zijn sinds de beschikbaarheid van Power BI downloads vanuit Twinfield, Exact Online en anderen vlot afbreken ook terug te vinden in de Bridge Online Monitoring. Als PowerBI.com eenzijdig de download staakt, dan verschijnt een itgenpmr003 melding zoals in onderstaand voorbeeld waarbij na 10 minuten telkens de verbinding verbroken wordt:
Advies 1: controleer dat de OData dataset een timeout ingesteld heeft. Indien niet, stel die om te beginnen in op 120 minuten en pas die verder waar nodig aan.
Een probleem dat gebruik van PowerBI.com soms in de weg staat is dat PowerBI.com op grote OData datasets nogal eens zelf crasht. De Power BI Service probeert dan rustig honderden keren opnieuw dezelfde OData dataset op te halen. Mogelijkerwijs wordt in de toekomst indien dit automatisch gedetecteerd wordt het gebruik automatisch kortstondig geblokkeerd om impact voor andere gebruikers te vermijden.
Vragen
Om verder een beter beeld te krijgen van de situatie:
- Welk licentievorm op Power BI wordt gebruikt: gratis, Pro, Premium of Premium Generation 2?
- Zijn er de afgelopen 30 dagen meldingen geweest vanuit Invantive om te wisselen van gebruikte tabel om de prestaties te verbeteren?
- Wat is de exacte start- en eindtijd die bij de melding staat zodat de looptijd bepaald kan worden (een timeout treedt vaak op bij “ronde” aantallen minuten)?
- Welke tabel / OData URL betreft het?
- Hoeveel rijen zitten er grofweg in de OData dataset?
- Hoeveel bytes netwerkomvang geeft Invantive Bridge Online Monitoring aan voor het verzoek? Door dit te vermenigvuldigen met 10 a 15 voor decompressie (afhankelijk van compressieprotocol) is een schatting van het te verwerken datavolume door PowerBI.com te krijgen. Een netwerkomvang van 500 MB is tot circa 7,5 GB voor verwerking binnen de 10 GB limiet voor gedeelde capaciteit. Een netwerkomvang van 500 MB is tot circa 750 MB binnen de limiet van 1 GB voor datasets in Power BI Service.
Advies 2: Vraag antwoord op bovenstaande vragen toe als een antwoord.
Advies 3: staat automatisch mailen van de gebruiker al aan als er een verversingsfout optreedt? Dit maakt het mogelijk om korter op de bal te spelen zodat de verzoekjes nog in Invantive Bridge Online Monitoring zichtbaar zijn.
Tip: Azure Data Factory
Sommige omgevingen op Invantive Cloud zijn groter dan anderen; soms met tot 1.000 administraties en soms zijn het gewoon erg veel gegevens of gebruikers. Bij intensief gebruik raden we aan om bijvoorbeeld Azure Data Factory te gebruiken om de gegevens vanuit Invantive Cloud in een database te laden en die te gebruiken; Azure Data Factory is net zoals Power BI onderdeel van Microsoft’s Azure cloudomgeving en staat daardoor veel dichterbij.
Tip: Pull-principe en Pre-emptive loading
Invantive Cloud maakt near real-time rapporten mogelijk dankzij het “pull”-principe. Anders dan veel andere oplossingen die op vaste tijden data klaarzetten (bijvoorbeeld 8 uur 's ochtends) worden de data pas opgehaald zodra ze aangevraagd worden. Dit is vergelijkbaar met asynchroon CPU’s ten opzichte van de regulier geklokte. Naast near real-time gedrag en hogere prestaties heeft dit ook dezelfde nadelen als deze speciale categorie van processoren:
- Minder bekend en daardoor kost meer tijd om mee te leren werken: het push-principe met vaste tijden wordt al decennia gebruikt voor datawarehouses, pull is relatief nieuw.
- Problemen in de keten (bijvoorbeeld een storing op het gekoppelde platform) zijn sneller zichtbaar omdat er met near real-time gegevens gewerkt wordt.
Voor punt 2 is om een gebruiker in staat te stellen om problemen in de keten tijdelijk te accepteren is recent een cache-only optie toegevoegd zoals beschreven op Cache only-modus voor Invantive Bridge Online: minder problemen als cloud-platform instabiel is.
Voor punt 1 (“onbekend maakt onbemind”) overwegen we een pre-emptive loading feature toe te voegen. Gebruikers kunnen dan per tabel aangeven dat ze die bijvoorbeeld 's ochtends al willen laten klaarzetten om een vaste tijd. Hiermee wordt dan het oude bekende push-principe weer toegevoegd.
Op dit moment kun je als gebruiker dit zelf ook realiseren: door in de ochtend een gelijktijdige dataset refresh te schedulen via de Power BI Service wordt effectief hetzelfde bereikt (zie Pre-load data in OData-cache to avoid Power BI timeouts). Gedurende levensduur van de Invantive Cloud-caches worden dan de gehele dag dezelfde gegevens gebruikt. Een timeout zal dan niet meer kunnen optreden omdat de data geleverd wordt uit de zeer snelle response cache.
