to get a personalized navigation.
to get a personalized navigation.
We have a client with very slow, and unstable, GET of purchase orders, compared to other clients.
We usually fetch with a orderstatus=open filter, but I've also tested with no filters, to compare record counts etc with other clients.
Simple GET on company 3013655 takes 45-90sec. Current test 1m 13.74s - 6.07MB of data (reported from Postman)
1.311 records totalcount (from meta data)
2nd test: 1m 7s,
3rd test: 1m 2s
(page size auto = 1000 records)
When filtering:
Test1: 9.82sec, 1.27MB and 89 records
Test2: 9.03sec
Test3: 8.27sec
Test4: 9.88sec
Test5: 10.77sec
Test6: 10.25sec
Test7: 5.82sec
Test8: 10.24sec
When testing "now" the numbers are slow, but we also have documented that during the day, with normal load, it takes 30-60sec for filtered requests with 80-90 records. We have this information from the customer, and verified in our logs + verified from time to time with static testing in postman. Even when doing several test we find that the request time is moving from 8-10sec to 40sec, up and down with minutes apart. We don't see this slow unstable request times on other clients.
Other clients usually return the first page within 15-20sec, when fetching all records:
Customer 2: 18.02 sec, 1.47MB, 328 records | filtered: 2.73sec, 179KB, 35 records
Customer 3: 46.43sec, 9.14MB, 376 records | filtered: 2.30sec, 213KB, 4 records
Customer 4: 45.15sec, 4.35MB, 1.946 records | filtered: 2.30sec, 78KB, 19 records
The problematic company does have more POs that cust 2 and 3, but less than cust 4.
When looking at the filtered status, there is not much difference customer 2, 3 and 4, with records 4-35, but the problematic case with 89 records takes a lot more time to fetch.
Line count is likely a factor, I've included the load-size as an indicator of that.
More customer information related to the case will be added in a private note.
Hello Sven, thank you for the information you've provided.
Could you also send the client details (ipp-company-id / API Client ID) to developersupport@visma.com ? So that we can investigate this in detail.
Copyright © 2022 Visma.com. All rights reserved.