Github user anmolnar commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/440#discussion_r160401512
--- Diff:
src/java/main/org/apache/zookeeper/server/quorum/ProposalStats.java ---
@@ -0,0 +1,70 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.zookeeper.server.quorum;
+
+import com.codahale.metrics.ExponentiallyDecayingReservoir;
+import com.codahale.metrics.Histogram;
+import com.codahale.metrics.JmxReporter;
+import com.codahale.metrics.MetricRegistry;
+import com.codahale.metrics.Reservoir;
+import com.codahale.metrics.Snapshot;
+import org.apache.zookeeper.jmx.CommonNames;
+import org.apache.zookeeper.jmx.MBeanRegistry;
+
+import static com.codahale.metrics.MetricRegistry.name;
+
+/**
+ * Provides real-time metrics on Leader's proposal size.
+ * The class uses a histogram included in Dropwizard metrics library with
ExponentiallyDecayingReservoir.
+ * It provides stats of proposal sizes from the last 5 minutes with
acceptable cpu/memory footprint optimized for streaming data.
+ */
+public class ProposalStats {
+ private final Histogram proposalSizes;
+
+ ProposalStats() {
+ final MetricRegistry metrics = new MetricRegistry();
+ Reservoir reservoir = new ExponentiallyDecayingReservoir();
--- End diff --
I'm not an expert either. According to the following article I think we've
the following reservoir options:
http://taint.org/2014/01/16/145944a.html
SlidingTimeWindowReservoir: the standard one, but looks like the memory
footprint could be potentially high in some cases.
SlidingTimeWindowArrayReservoir: similar to the previous with much better
memory handling
ExponentiallyDecayingReservoir: good memory/cpu footprint and optimised for
streaming data. The main difference is that if there's no data comes in within
the configured number of samples, previously collected statistics will be
presented on JMX. SlidingTimeWindow reservoirs will zero out, which sounds
correct behaviour to me, but it might be less convenient.
---
