You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few locations where we can imrpove caching, such as on the api-server and sdk-service
Within sdk-service, we can cache all the responses for incoming requests for ~7 seconds, which is similar to the block time for most cosmos-sdk chains.
In the api-server, we can try fetching cached requests before attempting to fetch them from sdk-service.
The text was updated successfully, but these errors were encountered:
Within sdk-service, we can cache all the responses for incoming requests for ~7 seconds, which is similar to the block time for most cosmos-sdk chains.
yes, makes sense
In the api-server, we can try fetching cached requests before attempting to fetch them from sdk-service.
wdym? You want to add a cache for sdk-service responses in api-server too? I would only cache them in sdk-service for avoiding too much complexity. Since we use a persistent gRPC connection between api-server and sdk-service, if sdk-service can answer from memory the overhead of this roundtrip should be really small.
There are a few locations where we can imrpove caching, such as on the api-server and sdk-service
Within
sdk-service
, we can cache all the responses for incoming requests for ~7 seconds, which is similar to the block time for most cosmos-sdk chains.In the
api-server
, we can try fetching cached requests before attempting to fetch them from sdk-service.The text was updated successfully, but these errors were encountered: