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
Perhaps add a response time to the responses? This may help a user decide when they need to scale their storage engine (DynamoDB read/write capacity units for example).
That's all set by the user outside of discfg and is not a discfg concern. Especially if using a different storage engine that does not have these kind of settings for scale (S3 for example).
Regardless, it's useful to know a response time. Whether it's for capacity planning (something we're trying alleviate with discfg by design) or just for the needs when designing an application. I do believe response time is going to be a tradeoff for other features with discfg.
The text was updated successfully, but these errors were encountered:
Perhaps add a response time to the responses? This may help a user decide when they need to scale their storage engine (DynamoDB read/write capacity units for example).
However, I'm not certain it's a huge concern here since AWS can (recently announced, https://aws.amazon.com/blogs/aws/new-cloudwatch-events-track-and-respond-to-changes-to-your-aws-resources/) trigger Lambdas based on various events to automatically scale. Up and down.
That's all set by the user outside of discfg and is not a discfg concern. Especially if using a different storage engine that does not have these kind of settings for scale (S3 for example).
Regardless, it's useful to know a response time. Whether it's for capacity planning (something we're trying alleviate with discfg by design) or just for the needs when designing an application. I do believe response time is going to be a tradeoff for other features with discfg.
The text was updated successfully, but these errors were encountered: