Visma Business versjon 16.10 er treg

[perimidt]

Hei

Etter at vi oppgraderte til versjon 16.10 av Visma Business har vi opplevd at det går vesentlig tregere å utføre enkelte operasjoner. Vi ser blant annet at registrering av ordre tar 3 – 4 ganger så lang tid som i versjon 12.10. Å bokføre bunter tar også mye lengre tid enn tidligere og vi ser at jo flere rader som skal bokføres jo saktere går det pr. rad. Dvs. at det tar mye mer enn dobbelt så lang tid å bokføre en bunt med 1.000 rader sammenlignet med en på 500 rader.

Vår forhandler har analysert og sammenlignet ytelsen og funnet ut at dette skyldes endringer som Visma har gjort. Det alene har kostet oss flere 10-tusener for Visma krever å motta logger fra vårt system for å feilsøke. I tillegg må vi bruke penger på å finne alternative løsninger til standard Visma Business.

Er det noen som har opplevd det samme og som har noen tips som kan deles?

Hvis noen fra Visma leser dette så er det Case #239021 og #238307.

[arne fure]

Noen partnere som har testet VB 16.10.4 m/ VDC 16.10.3 som nå lagt ut for partnere mht. mulig forbedring av ytelse?

- kunder bør kontakte sin forhandler for evt. informasjon og oppgraderingsmuligheter.

[Ørjan Berg]

Hei

Tester jeg har utført i demo miljø viser at bunt/bilag ytelse er korrigert.

[Mikael Björk]

Jag testade igår åt en kund att klistra in 9000 rader från Excel till en bunt. Det tog 4.5 tim. 

Kunden har 16.10.2. Har ni märkt samma problem i alla 16.XX?

Det är också problem med tusentalsformateringen. Något som också är en bugg. Man skriver i releasenoten att det är fixat i version 16.10.1 men den är tillbaka i 16.10.2. 

Vi ser även det att fakturering tar längre tid. Har det med samma begränsning av antal transaktioner som du beskriver Frode?

Vi stoppar nu alla uppgraderingar. Att använda Excel till Visma Business är en funktion som kunderna uppskattar stort. Men nu är den funktionen oanvändbar. 

[Frode_Antun]

Det er mye som går tregere i versjon 16 enn tidligere versjoner. Jeg kjørte en test på bokføring av 116 tusen korrigerte transaksjoner først på 32 bit og så på 64 bit versjon av VBus og til slutt med bruk av jobb-planleggeren (altså når VBS gjør jobben). Og målte antall transaksjoner VBus klarte å behandle pr. minutt. Det er ingen signifikant forskjell på 32/64 bit og ikke egentlig om det gjøres i et VBus vindu eller som en bakgrunnsjobb. Men VBus klarer å behandle over 10 tusen transaksjoner det første minuttet, 9 tusen det andre minuttet, 7 tusen det tredje minuttet, etc. Etter tjue minutter klarer VBus å behandle 2 tusen transer i minuttet: 

[Frode_Antun]

Jeg meldte dette til Visma for 14 dager siden (case #239021), men så langt har det vært øredøvende stille.

[EddieBratli]

---

Frode
Du fikk tilbakemelding på sak #238307 den  23. mars om at saken var eskalert til utvikling.  Rettet i versjon 17.00 og vi vil forsøke å få den med i patch også. Ref. svar tidligere i dag.
Når det gjelder sak #239021 så beklager vi at du ikke har fått noen tilbakemelding. Denne saken vil også bli meldt til utvikling men har nok noe av samme årsak som sak #00241172 som er eskalert til utvikling.

Beklager litt behandlingstid på saker som dette da det dessverre er en del mva saker nå.

[EddieBratli]

Vi er klar over problemet og beklager manglende tilbakemelding her i community. 
Saken er løst for versjon 17.00 og vi vil forsøke å få med dette også i patch 16.10.3 sammen med omskriving av håndteringen for Mva-melding. Patch er planlagt første uken i Mai.

Gi gjerne en "like" om du synes svaret var nyttig og "Godta som løsning" hvis jeg besvarte spørsmålet ditt. Dette hjelper andre i Community.

[Frode_Antun]

Det ser ikke ut som om det er gjort noe med dette i versjon 16.10.3:

Releasenotes til versjon 16.10.3 

Eller er dette bare et utkast til releasenotes?

[Ørjan Berg]

Jeg har testet i 16.10.3 og problemet er ikke løst.

Fra SQL logg:

[2022.05.06 14:59:17:855] Paste clipboard row item 17 of 100
[2022.05.06 14:59:17:855] [Status message] Bilagsart 21: Inngående faktura
[2022.05.06 14:59:17:855] [Status message] 25 % mva = 0,00
[2022.05.06 14:59:17:855] [Status message] Hovedbokskonto 6900: Telefon
[2022.05.06 14:59:17:855] [Status message] Leverandør 50000: Bennington
[2022.05.06 14:59:17:855] Execute the Voucher table's ExpandAutomaticEntries processing
[2022.05.06 14:59:17:855] Process row item 1 of 1 (primary key 5, 117)
[2022.05.06 14:59:17:855] [Status message] Bilag 5, 117
[2022.05.06 14:59:17:855] A: SELECT * FROM Aut ORDER BY Srt ASC /*66*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM Aut ORDER BY Srt ASC /*66*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]
[2022.05.06 14:59:17:855] A: SELECT * FROM VoTp WHERE VoTpNo = 21 /*3023*/ [0.000]

[Frode_Antun]

De linjene du har markert med rødt, er nok en den av den innledende kontrollen før buntoppdateringen egentlig starter - det samme som skjer når du bruker behandlingsvalget Valider bunt. Her blir hver bilagslinje validert for seg. Har du en bunt med to hundre bilagslinjer og det står Prosjektnr 4711 på alle linjene, så sjekker VBus at Prodsjektnr 4711 finnes 200 ganger. Ikke egentlig smart. Det samme skjer på alle de andre ansvarsenhetene også. Og slik er det fremdeles i versjon 18.

Men det som egentlig tar tid, er at VBus låser saldo-tabellene eksklusivt for hver bilagslinje som skal oppdateres. Du finner igjen disse i loggen som SELECT * FROM AcBal [TABLOCKX] WHERE AcNo=0. Jeg har stusset over dette, for det finnes ingen rad i saldo-tabellene med Kontonr=0. Men det et TABLOCKX som er det vesentlige; Lås hele tabellen inntil COMMIT TRANSACTION. Dette gjør at det ikke har noe hensikt å sette opp flere jobber som oppdaterer bunter samtidig; alle skal gjennom den samme slusa. Dette blir muligens løst i versjon 18.10 som kommer i desember. Det ble løst i NXT nå i oktober. Det vil si; det introduseres en mulighet til å oppdatere bunt uten samtidig å oppdatere saldo-tabellene. Og et menyvalg som heter, oppdater bunter som er bokført siden forrige saldo-oppdatering. 

Men det er nok bare de med meget høyt transaksjonsvolum som kommer til å nyttegjøre seg dette.

[Mikael Björk]

Det är ju riktigt dåligt om det är som du säger. Då kommer det krävas uppgradering till helt ny version (17.xx). 

[Frode_Antun]

Vi meldte denne problemstilling til Visma (case #238307) 18. mars og fikk denne tilbakemelding: Vi kan ikke se at dette er meldt inn fra andre kunder og partnere.

Så det er bare å melde fra til Visma, slik at de ser at det ikke bare er vi som opplever dette.

[Frode_Antun]

Hvis du limer inn fra f.eks. Excel kan det være en workaround å lage en standard importfil i stedet. Men da må man selv sørge for å ha rett verdi på alle rader. Hvis man har en VBS-jobb som gjør dette, kan man vurdere å dele den opp i mindre bunter. 

[olaeld]

Å dele opp i mindre bunter i VBS har negative praktiske konsekvenser for våre kunder. Jeg har også vurdert muligheten for å omgå problemet ved å skrive om koden i vår løsning slik at det legges til f. eks. 100 og 100 linjer til en bunt (som dog først må opprettes). Dette øker kompleksiteten i vår løsning, medfører risiko - og dette burde egentlig bare fungere, slik det har gjort i årevis.

[olaeld]

Vi opplever det samme problemet. Overføring av en bunt med noen tusen linjer tar flere timer. Dette skaper store problemer - frustrerte kunder og ekstraarbeid.

[olaeld]

Vi opplever de samme problemene. Overføring av en bunt med noen tusen linjer tar flere timer, og det skaper både frustrasjon og ekstraarbeid.

[Mikael Björk]

Har ni provat att klistra in direkt på app-servern? Om ni gjort det, går det fortare?

[perimidt]

Hei

Jeg gjorde det nå, 600 ordrelinjer tok 25 minutter å lime inn og resulterte i en SqlLogg på over 200.000 rader.

[Mariosso]

Følger, opplever samme problem.

[Mikael Björk]

Har ni testat att köra klienterna i 32-bit?