[
https://issues.apache.org/jira/browse/GEODE-9750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433857#comment-17433857
]
ASF subversion and git services commented on GEODE-9750:
--------------------------------------------------------
Commit e44a0442fd00e9e7bcf156d910400646362dc821 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e44a044 ]
GEODE-9750: add pubsub stats (#7028)
-- The new pubsub stats
-- fixed some warnings in the existing RedisStats.java class.
-- fixed unit on network bytes read (it should have been 1024 not 1000)
-- a couple of stats read the atomic value twice; now do it once
-- added the following new pubsub stats to GeodeRedisStats:
publishRequestsCompleted, publishRequestsInProgress, publishRequestTime
subscribers, uniqueChannelSubscriptions, uniquePatternSubscriptions
I did not add the requested publishRequestMisses because it would be too
expensive to implement given our batching and the need to know if it missed on
all servers in the cluster.
> add geode-for-redis stats for publish and subscribe
> ---------------------------------------------------
>
> Key: GEODE-9750
> URL: https://issues.apache.org/jira/browse/GEODE-9750
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Affects Versions: 1.15.0
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> GeodeRedisStats should have some pub/sub stats. We already have stats for the
> commands themselves. But that does not help much with publish which has an
> async implementation.
> For those async publishes we need a stat that tells how many are in progress
> and a time stat that tells the total amount of time async publish took. Also
> a publish can "miss" (i.e. not find any subscribers) and it is worth having a
> stat show how many of the publishes missed.
> It would also be nice to see how many subscribers a server has (include both
> subscribe and psubscribe) since these can be unbalanced and cause memory or
> perf issues.
> Pattern subscriptions are more expensive if you have many of them that are
> different patterns. So we should having something like "uniquePatterns".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
