Details
-
Technical task
-
Resolution: Unresolved
-
Major
-
Cheshire-Cat
-
None
Description
Today the stats endpoint response is very verbose and this could result in more processing and storage needs at the ns_server level.
For eg:
"travel-sample:FTS:avg_grpc_internal_queries_latency": 0, |
"travel-sample:FTS:avg_grpc_queries_latency": 0, |
"travel-sample:FTS:avg_internal_queries_latency": 0, |
The prefixes like $bucketName:$Scope:$CollectionName:$IndexName:StatsName would become really inefficient. And the overheads would be really huge with more indexes.
This needs to be fixed with a few stats trimming approaches.
Couple of them popping to mind are
- Hierarchical data/response representation to result in really trimmed version of relevant stats.
- Adoption of gzip or other compression utilities/custom encodings if the request `Content - Type` demands it.
But any such stats response change would result in an API break and needs to be checked / Synced with ns_server team before proceeds further.