The cluster stats endpoint eventually becomes very slow when working with a large cluster (large index counts are what matters here). E.g. in benchmarking and real world issues (see below linked issue), it can be O(10s) of coordinating node work alone.
As the size of a cluster increases both the node level actions (scales with the number of shards per node) become slower (translog stats etc. are costly to compute for a large number of shards) but also the coordinating node work, that among other things involves deserializing+decompressing all mappings, slows down considerably as could be seen in e.g. #62753.
The coordinating node work can probably be sped up massively by exploiting mapping duplication. The data node slowness is less of a concern since that can be fixed by scaling to more nodes I'd say but there might be possible speed-ups there as well.
The cluster stats endpoint eventually becomes very slow when working with a large cluster (large index counts are what matters here). E.g. in benchmarking and real world issues (see below linked issue), it can be O(10s) of coordinating node work alone.
As the size of a cluster increases both the node level actions (scales with the number of shards per node) become slower (translog stats etc. are costly to compute for a large number of shards) but also the coordinating node work, that among other things involves deserializing+decompressing all mappings, slows down considerably as could be seen in e.g. #62753.
The coordinating node work can probably be sped up massively by exploiting mapping duplication. The data node slowness is less of a concern since that can be fixed by scaling to more nodes I'd say but there might be possible speed-ups there as well.