Closed ericvergnaud closed 1 year ago
FYI — when we switched to Askar we got a significant boost in performance, and other benchmarks have shown Askar to be much faster and more stable than the IndySDK — especially under load.
Thanks for the easy reproduction instructions — we’ll have to take a look at this. It is curious...
Note that we were using an ACA-Py-based mediator, so we’re not comparing apples to apples in my note.
We're using Askar on mobile side without issue. The above is a js mediator running in Node...
This is related to a known performance issue in ref-napi
, which needs to be patched. This week we've updated shared components (among which we have aries-askar) which use the patched version and should work fine.
As a result, we now require at least node 18, and for that reason I've created #1622 to update Dockerfile
accordingly (and also sample mediator to use Askar instead of Indy SDK).
It would be great if you can re-check from that branch or wait a bit until it is merged to main.
The doc says that IndySDK support will be removed soon, but Askar is currently unusably slow for mediator.
This is evidenced by doing the following:
Run the sample mediator using indy:
docker build -t aries-framework-javascript .
docker compose -f docker/docker-compose-mediators up
curl "http://localhost:3001/invitation?"
, it returns in millisecondsNow run a similar mediator, simply using using askar in lieu of indy:
docker build -t aries-framework-javascript .
docker compose -f docker/docker-compose-mediators up
curl "http://localhost:3001/invitation?"
, it returns in several seconds instead of millisecondsThe above is a simple way to highlight the issue. We rolled out a mediator using askar in AWS and although we were able to get an invitation, any attempt to go further would trigger timeouts from the infrastructure. Switching back to Indy was the only way to solve the issue.
mediator.ts.zip