Samenvatting
Het probleem is gereproduceerd via delegatie.
De oorzaak lijkt dat het gelijktijdig verwerken voor een tiental of tientallen administraties sterk verslechterd is. Gebruikers met honderden of enkele administraties ervaren geen verschil voor zover bekend en meetbaar.
Een ontwikkelaar zal analyseren wat de vertraging veroorzaakt om de oorzaken weg te nemen. Zodra de oorzaak achterhaald wordt een actieplan bedacht en doorgevoerd. Daarna wordt de verbetering verwerkt in een nieuwe release.
Workaround voor dit moment is om:
- de timeouts hoger in te stellen
- waar mogelijk een filter toe te voegen (zie workaround 2)
- meer downloads parallel uit te voeren
Voor de derde actie is het abonnement tijdelijk omgezet naar een 10-user abonnement met 8 in plaats van 4 parallelle slots tot 10 maart. Hiervoor worden geen extra kosten in rekening gebracht.
Analyse
Een analyse geeft aan dat specifiek voor AccountsIncremental het om circa 115 MB aan gzipped-data gaat (circa 1 GB uncompressed) met meerdere honderdduizenden rijen in circa 10 partities in deze database. Van de 21e februari op de 22e februari is het gedrag veranderd, zie onderstaande tabel.
| Aspect |
21-2 |
22-2 |
| Versie |
22.0.48 |
22.0.55 |
| Pure verwerkingstijd (sec) |
50 |
250 |
|
#Downloads per dag |
1 |
8 |
Een andere omgeving met vergelijkbare aantallen in AccountsIncremental en één administratie is ter referentie er naast gelegd om te kijken of het een administratiespecifiek of algemeen probleem is. Hierbij is vreemd genoeg geen trendbreuk zichtbaar voor en na de versieverandering. De doorlooptijden zijn binnen van een marge van 10% vergelijkbaar.
Nog een andere omgeving is ook meegenomen in de vergelijking, maar dan op basis van historische ontwikkelingen op TransactionLinesIncremental. Hiervan is de looptijd echter wel vergelijkbaar gestegen van 21 februari op 22 februari.
Een voornaam verschil tussen release 22.0.48 en 22.0.55 is een andere wijze van parallellisatie van downloads als een rate limiter zoals op Exact Online actief is.
Vervolgens is gekeken wat de verwerkingssnelheid is met een kleine tabel namelijk GLAccountsIncremental. Als de gegevens per administratie achtereenvolgens opgehaald worden, dan duurt dit 500 ms kloktijd per administratie. Bij parallel ophalen duurt dit ruim 1.100 ms kloktijd per stuk, ondanks parallellisme.
Een test met artikelen met serieel verwerken van de administraties geeft hetzelfde aan, serieel duurt 6x zo kort als parallel met acht stromen:
--
-- Serieel.
--
declare
l_cnt number;
begin
for r in ( select code, 'eol' from systemdivisions@eol )
loop
select count(*)
into l_cnt
from itemsincremental@eol
;
end loop;
end;
De conclusie tot dusver is dat bij het ophalen van gegevens uit tien of tientallen administraties parallellisme sinds versie 22.0.55 een vertraging veroorzaakt.
Gedurende het testen van de nieuwe release is dit probleem niet naar voren gekomen, maar de testomgevingen zijn ook niet altijd representatief. Zo is er getest op .NET Framework in plaats van .NET Core (waarbij zowel .NET Core op Windows als Linux deze vertraging laten zien).
Test Workaround 1: verlagen parallellisatie
Een korte proef met artikelbestand door de parallellisatie terug te brengen naar 1 leverde geen snelheidswinst op t.o.v. de parallelle verwerking.
Test Workaround 2: filters
Een korte proef met artikelbestand door het datavolume te beperken met een filter (like) toonde een forse snelheidswinst.
Aangezien met de incrementele tabellen eerst alle data verzameld moet worden ook als er een filter is, is blijkbaar het verzamelen van de volledige dataset niet de bottleneck, maar het teruggeven. Ergens is dit een serieuze factor langzamer geworden bij middelmatige aantallen administraties.
Door op het teruggeven een filter op te leggen neemt de snelheid weer toe.
