Bedankt voor het advies bij de where-clauses; helaas heb je dit bij PowerBI niet zelf onder controle.
Antwoord op je vragen:
- Liepen er gelijktijdig meerdere maar verschillende requests binnen hetzelfde abonnement? Elke abonnementsvorm heeft een eigen limiet qua aantal gelijktijdige verzoeken (meestal 4). Elk volgend request wordt geparkeerd tot er een slot vrij is. Dat wordt ook bevestigd in de monitoring.
A: wanneer je een “refresh” uitvoert in PowerBI heb ik de indruk dat alle requests in parallel gelanceerd worden maar in series uitgevoerd worden.
- Liepen er gelijktijdig meerdere requests voor dezelfde data met hetzelfde filter? Zo ja, dan wordt elk gelijkluidend request geparkeerd totdat de eerst gestarte klaar is. Alle wachtenden retourneren dan de gegevens uit cache.
A: nee.
- Om hoeveel rijen gaat het? Bij views uit de
*Flat-reeks is de normale responsetijd per 100 rijen 4 minuten. De Teamleader API’s zijn niet echt geschikt voor grote volumes inclusief details.
A: het gaat om ongeveer 3.000 rijen en de responstijd is ongeveer 20 minuten. MAAR: telkens als ik de query uitvoer MET filter wordt er automatisch dezelfde query uitgevoerd ZONDER filter. En dan praten we over >15.000 rijen. Het binnenhalen van deze gegevens duurt ongeveer 1 uur. En helaas stopt de eerste query pas na het uitvoeren van de tweede query. Ik heb hierover eerder al een topic gepost.
- Is er selectief gefilterd en is dat filter ook zichtbaar in de Bridge Online Monitoring bij de SQL-query?
A: ja.
Printscreen van de monitoring - door het feit dat het opladen afgebroken wordt is er geen volledige logging.
Query 1 - Op TeamLeader met parameter start op 12:41:08
Query 2 - Op TeamLeader zonder parameter start op 12:42:03
Het merkwaardige is dat ik met de andere TeamLeader-1 dit probleem niet heb en dat ziet er de logging als volgt uit:
