Fair Use Daglimieten voor een Betere Gebruikerservaring
Invantive introduceert “Fair Use Daglimieten” om een optimale gebruikerservaring te garanderen voor Invantive Bridge Online. Deze limieten richten zich op vier dimensies: hoeveelheid uitgewisselde data, aantal verzoeken, totale duur van verzoeken en het aantal geretourneerde rijen uit een tabel. Ze zijn onderverdeeld in vers gebruik en totaal gebruik, inclusief caches. De invoering is gepland voor 1 oktober 2023, maar kan worden aangepast afhankelijk van de impact op zware gebruikers.
Deze aanpassingen bieden meerdere voordelen, waaronder betere prestaties, snellere responstijden en meer stabiliteit tijdens piekuren. Gebruikers kunnen hun verbruik monitoren via het dashboard op Invantive Bridge Online en zijn voorzien van extra HTTP-headers voor geautomatiseerde bewaking. Bij eventuele problemen of vragen kunnen gebruikers contact opnemen met Invantive via support@invantive.com. Deze maatregelen zijn ontworpen om een meer gebalanceerde en rechtvaardige gebruikerservaring te creëren.
Fair Use Daglimieten
We zijn verheugd om te zien hoe intensief Invantive Bridge Online wordt gebruikt om real-time data op te halen voor rapportages en data uit te wisselen met cloudapplicaties. Dagelijks worden er grote aantallen verzoeken verwerkt, waarbij veel verzoeken meerdere bedrijven betreffen.
Echter, om een optimale ervaring voor iedereen te garanderen introduceren we enkele aanpassingen om zo het concept van “fair use” ook te automatiseren. Daarnaast zorgt de automatisering van “fair use” er ook voor dat op hol geslagen processen niet meer langdurig alle gebruikers hinderen.
In het kader van “fair use” worden er daglimieten ingesteld op verschillende dimensies:
- hoeveelheid data uitgewisseld per dag,
- aantal verzoeken per dag,
- totale duur verzoeken per dag en
- het aantal rijen uit een tabel geretourneerd.
Deze dimensies worden gesplitst in het gebruik voor ophalen van verse data en het totaal gebruik, inclusief caches. Deze twee x vier dimensies zijn deels gecorreleerd, maar vangen daarnaast elk een specifieke groep van problemen af.
Deze limieten worden geleidelijk ingevoerd en zijn ontworpen om de kwaliteit en snelheid van de dienst voor alle gebruikers te waarborgen. Wens is om de invoering afgerond te hebben voor 1 oktober 2023, maar het invoeringstempo wordt bijgesteld als zware gebruikers een niet-realistische impact ervaren.
Bij overschrijding van een daglimiet wordt een HTTP-statuscode 429 teruggeven (“Too many requests”) met een toelichting in OData-formaat. De bijbehorende foutcodes zijn itgenboe402, itgenboe403, itgenboe404, itgenboe405, itgenboe406, itgenboe407, itgenboe408 en itgenboe409.
In bovenstaande lijst ontbreken restricties op het CPU- en geheugengebruik per dag; deze kunnen momenteel technisch nog niet zinvol bepaald worden. Mogelijk zal dit in de toekomst toegevoegd worden.
We zijn ervan overtuigd dat de bovenstaande limieten bijdragen aan een meer gebalanceerde en rechtvaardige gebruikerservaring.
Voordelen
De voordelen van de Fair Use Daglimieten voor gebruikers zijn:
- Betere prestaties en snellere responstijden voor iedereen.
- Meer stabiliteit tijdens piekuren.
- Ruimte voor toekomstige uitbreiding en verbeteringen.
Meetmethode
De metingen van daglimieten vinden plaats per kalenderdag volgens UTC-tijdmeting. De UTC-daggrens loopt afhankelijk van de datum 1 of 2 uur achter bij de Nederlandse daggrens.
Inzicht
Interactief Inzicht in Gebruik
Gebruikers kunnen op Invantive Bridge Online en Invantive App Online per abonnement de cumulatieven per abonnement vinden als een kaart in het dashboard. Hierbij worden de vier dimensies getoond - telkens voor enerzijds vers gebruik en anderzijds totaal gebruik - als percentage van het maximum.
De maximale waardes zijn afhankelijk van de abonnementsvorm. De waardes zijn terug te vinden door het abonnement op te zoeken in het scherm “Overeenkomsten” en de blauwgekleurde hyperlink met de abonnementsvorm te kiezen. Zoek vervolgens op “max”:
De daglimieten gelden voor alle Bridge Online en App Online-servers. Voor de huidige server en gebruiker worden de totalen doorlopend bijgewerkt in het dashboard. De getoonde getallen kunnen door het gelijktijdig gebruik van meerdere servers en/of meerdere gebruikers op eenzelfde abonnement achterlopen bij het daadwerkelijk gebruik. Het daadwerkelijk totale gebruik over alle servers en gebruikers heen wordt regelmatig onderling gesynchroniseerd. Op een synchronisatiemoment kunnen de totalen significant omhoogspringen.
De details voor de huidige dag kunt u vinden in het scherm “Sessie I/O’s” op Invantive Cloud, terwijl het scherm “Maandelijkse Geaggregeerde Sessie-I/O’s” in het “Diagnostiek” menu historische details laat zien. Zoek hiervoor op “AppOnline” (voor https://app-online.cloud) en “BridgeOnline” (voor https://bridge-online.cloud). In het scherm Sessie I/O’s op Invantive Cloud is al het gebruik zichtbaar tot/met tenminste 5 minuten eerder.
Cached data van Bridge Online/App Online naar buiten is herkenbaar aan de waarde BridgeOnlineOdata4ZipOutCache voor Data Container Alias. Verse data van Bridge Online/App Online naar buiten is herkenbaar aan BridgeOnlineOdata4.
Geautomatiseerde Bewaking
Alle OData4- en applicatie-verzoeken op Invantive Bridge Online en Invantive App Online zijn voorzien van extra “HTTP-headers”. De waardes van deze headers stellen software en eventueel gebruikers in staat om de huidige uitnutting van de limieten te kennen en hier op te handelen. De HTTP-headers volgen de draft voor RateLimit header fields for HTTP.
De HTTP-headers zijn zichtbaar bij het verzoek in Invantive Bridge Online Monitoring als meest recente stap in het onderste deel van de details:
In onderstaande tabel staan de gebruikte HTTP-headers en hun betekenis:
| Naam | Betekenis |
|---|---|
| Invantive-RateLimit-SubscriptionType | Abonnementsvorm (zie scherm Overeenkomsten) |
| Invantive-RateLimit-ContractCode | Abonnementscode |
Invantive-DIMENSION-RateLimitPolicy |
Duur van het tijdsvenster in seconden en de numerieke limiet |
Invantive-DIMENSION-RateLimit |
Verbruik, limiet en aantal seconden tot aflopen tijdsvenster |
De HTTP-headers met DIMENSION zijn beschikbaar in acht varianten:
FreshBytesPerDay: downloadvolume in bytes aan verse data (zonder caches).TotalBytesPerDay: totaal downloadvolume in bytes.FreshDurationMsPerDay: downloadduur in milliseconden voor verse data (zonder caches).TotalDurationMsPerDay: totale downloadduur in milliseconden.FreshRowsPerDay: aantal rijen in downloads met verse data (zonder caches).TotalRowsPerDay: totaal aantal rijen in downloads.FreshRequestsPerDay: aantal downloads met verse data (zonder caches).TotalRequestsPerDay: totaal aantal downloads.
Daarnaast kunnen andere HTTP-headers doorgegeven worden t.b.v. analyse, maar de beschikbaarheid hiervan is niet gegarandeerd.
Voorbeeld RateLimit-HTTP header
Een voorbeeld van een RateLimit-waarde is:
limit=10000,remaining=10000,reset=55553
De limiet per dag is 10.000 en er zijn nog 10.000 beschikbaar. Het volgende tijdsvenster met nieuwe quota begint over 55.553 seconden.
Voorbeeld RateLimitPolicy-HTTP header
Een voorbeeld van een RateLimitPolicy-waarde is:
10000;w=86400
De limiet is 10.000 en het tijdsvenster begint elke 86.400 seconden (24 uur) opnieuw.
Achtergrond
Deze aanpassing is noodzakelijk geworden omdat de top-10 van gebruikers circa 50% van de servercapaciteit in beslag neemt. Een groot deel van de gebruikers merkt hierdoor wisselende reactietijden op downloadverzoeken. Om dit te compenseren is de servercapaciteit afgelopen maanden tot twee keer toe verdubbelt, maar de omzet waar de capaciteit uit betaald wordt groeide niet daarin mee. Anders dan op het oog vergelijkbare producten waarbij de omzet uit abonnementen verveelvoudigd wordt met consultancy, moeten de Invantive-abonnementen kostendekkend zijn.
Voor de Geraakte Gebruikers
We begrijpen dat dit voor sommigen een aanpassing zal vergen aan de werkwijze. Om dit proces te vereenvoudigen daarom een lijst van opties die snel veel verbetering realiseren zonder concessies aan het resultaat. Deze lijst is geordend van eenvoudig en snel, naar complexere verbeteringen:
- Stem op deze Power BI-verbetering om ook binnen Power BI te profiteren van tot 75% reductie in downloadvolume en downloadverzoeken zoals beschreven in Sneller data verwerken uit Invantive Cloud op geselecteerde OData-clients.
- Beperk eenvoudig het downloadvolume en -duur door compressie in te schakelen.
- Beperk eenvoudig downloadvolume en -duur door herhaalde pogingen voor dezelfde data door een te lage time-out.
- Vermijd herhaalde downloads en verbeter de snelheid door vaakgebruikte datasets te delen (video).
- Vervang downloads van verse gegevens voor langzaam veranderende dimensies door downloads uit de cache door de toegestane maximale leeftijd van de gegevens te verhogen zoals beschreven aan het einde van Realtime OLTP verzoeken via OData4 voor Power Apps en Power BI.
- Beperk het downloadvolume door alleen de benodigde kolommen op te halen.
- Beperk downloadvolume en -duur door alleen de benodigde rijen op te halen met een filterstap of
where-clause. - Overzicht van Power BI-technieken om prestaties en downloadtijd te verbeteren.
- Gebruik hogere limieten voor cached data door een meer passende cachelevensduur te kiezen.
- Beperk de downloadduur door snellere tabellen te gebruiken zoals
*Incremental. - Een uitgebreide lijst van performance-optimalisatie artikelen is te vinden onder Topics met de tag performance.
Mocht u ondanks optimalisatie toch behoefte houden aan significant hogere limieten of heeft u tussentijds snel en tijdelijk een hogere limiet nodig? Invantive biedt verschillende abonnementsopties aan die meer capaciteit bieden.
Tenslotte kunt u een gratis performance audit aanvragen via de procedure beschreven in Hoe laat ik een gratis Power BI performance audit uitvoeren?.
Free Exact Online and Bouw7 Plan
Voor gebruikers van het Free Exact Online and Bouw7 Plan en enkele weinig gebruikte abonnementsvormen met een zwaardere beperking op het aantal rijen dan “Fair Use” betekent dit ook dat de daglimiet van bijvoorbeeld 100.000 rijen nauwkeuriger wordt gemeten. Voorheen was het enkel mogelijk om per query een limiet van x te gebruiken, maar dankzij de nieuwe mogelijkheden vindt de controle nu per dag in plaats van per query plaats.
Invoering
Wens is om de invoering afgerond te hebben voor 1 oktober 2023, maar het invoeringstempo wordt bijgesteld als zware gebruikers een niet-realistische impact ervaren.
De limieten zijn samengesteld op basis van het huidige gebruik en de noodzakelijke geachte abonnementsvorm-specifieke bijdrage aan de kosten voor infrastructuur. Bij het huidige gebruik is geanalyseerd welk gebruik onrealistisch hoog is voor hetgeen bereikt moet worden. Deze limieten zijn gevalideerd tegen de overige gebruikers om de kans op overlast te minimaliseren. Voor duurdere abonnementsvormen zijn de limieten hoger gesteld, omdat de bijdrage hiervan aan de kosten voor infrastructuur ook hoger is.
De invoering bestaat uit meerdere stappen:
- Upgrade programmatuur met metingen ingeschakeld, maar foutmeldingen uitgeschakeld (afgerond 22 september 2023).
- Activering foutmeldingen maar vergeleken met 5x hogere limieten dan abonnementsvorm voorschrijft (afgerond 25 september 2023).
- Activering foutmeldingen maar vergeleken met 3x hogere limieten dan abonnementsvorm voorschrijft (afgerond 3 oktober 2023).
- Activering foutmeldingen maar vergeleken met 2x hogere limieten dan abonnementsvorm voorschrijft (afgerond 3 oktober 2023).
- Activering foutmeldingen maar vergeleken met 1.5x hogere limieten dan abonnementsvorm voorschrijft (gestart 5 oktober 2023).
- Activering foutmeldingen met de abonnementsvorm-specifieke limieten (start na succesvolle afronding vorige stap).
Neem contact op met Invantive via support@invantive.com of chat indien u storingen ervaart door de invoering van de Fair Use Daglimieten. Specifieke abonnementen kunnen tijdelijk uitgesloten worden van de Fair Use-limieten mits er zicht is op aansluiting bij de Fair Use-limieten op afzienbare termijn.
Veelgestelde Vragen
Mijn totale download duurt maar 60 minuten, maar het dashboard toont een totale duur van ruim het dubbele. Hoe kan dat?
Een download kan uit meerdere losse downloads bestaan, die na elkaar of gelijktijdig uitgevoerd worden. De totale duur van alle downloads wordt bepaald. In het geval van gelijktijdige uitvoering van meerdere downloads loopt de totale duur dus sneller op dan de klok aangeeft.
Op Teamleader heb ik een enorme duur in beeld. Hoe kan dat?
Teamleader heeft een unieke combinatie van erg lage call rate limieten en de noodzaak om per rij een API-call uit te voeren om custom fields op te halen.
Algemene tip is om downloads op Teamleader NIET parallel uit te voeren, maar achtereenvolgens. Door bijvoorbeeld 4 downloads de erg lage rate limit te laten delen zal de doorvoersnelheid niet verhoogd worden, maar is de totale duur wel 4x zo hoog.