Today when we respond to a cluster:monitor/state action we serialize the current cluster state:
|
PublicationTransportHandler.serializeFullClusterState(currentState, Version.CURRENT).length(), false)); |
However, we do so on the network thread:
|
// very lightweight operation in memory, no need to fork to a thread |
|
return ThreadPool.Names.SAME; |
This is a problem if the cluster state is large, because it consumes a network thread doing non-network things. It's particularly a problem if using lots of transport clients with sniffing enabled since each client will, by default, call this method every 5 seconds.
Yet we do this serialization to get the compressed size of the cluster state so that we can report it (see #3415). Many clients will not care about this. Maybe we can omit it? Alternatively, note that it only depends on the cluster state so maybe we can cache it and invalidate the cache on each cluster state update.
Today when we respond to a
cluster:monitor/stateaction we serialize the current cluster state:elasticsearch/server/src/main/java/org/elasticsearch/action/admin/cluster/state/TransportClusterStateAction.java
Line 186 in 4cab8ec
However, we do so on the network thread:
elasticsearch/server/src/main/java/org/elasticsearch/action/admin/cluster/state/TransportClusterStateAction.java
Lines 59 to 60 in 4cab8ec
This is a problem if the cluster state is large, because it consumes a network thread doing non-network things. It's particularly a problem if using lots of transport clients with sniffing enabled since each client will, by default, call this method every 5 seconds.
Yet we do this serialization to get the compressed size of the cluster state so that we can report it (see #3415). Many clients will not care about this. Maybe we can omit it? Alternatively, note that it only depends on the cluster state so maybe we can cache it and invalidate the cache on each cluster state update.