[
https://issues.apache.org/jira/browse/CASSANDRA-19808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869990#comment-17869990
]
Cesar Andres Stuardo Moraga commented on CASSANDRA-19808:
---------------------------------------------------------
Thanks, Brandon.
That is very interesting, I was not aware of TCM. We are currently devising
some large-scale detection tools, and we were wondering about the components
necessary to qualify an occurrence as a bug, a fix, a micro-optimization, and
so on.
I would like to ask you a few questions, feel free to answer whenever you can:
# Frequency is something we will consider; it sounds very reasonable. The
question here is whether Cassandra offers guides on how to determine what to
report. I understand that in cases where there is a logic issue, that is a
little more straightforward. In our case, we analyze trends in large-scale
(large number of peers, tables, views, etc.) deployments and try to find points
that could become bottlenecks. Do you have guides that could allow us to
determine if one of those pressure points could be a bug candidate?
# Are there CEP's directed to large-scale Cassandra clusters? On the scale of
thousands of nodes, for example?
Thanks again!
Cesar. A. Stuardo.
> Gossiper (micro) optmizations
> -----------------------------
>
> Key: CASSANDRA-19808
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19808
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Cesar Andres Stuardo Moraga
> Priority: Normal
>
> I am wondering about optimizations that can be done in the gossiper class,
> especially targeting performance at larger scales.
> # getLiveMembers: Creating a hashmap every time this is called. Aside from
> creating some trash, its linear in terms of the number of peers.
> # getMaxEndpointStateVersion: I feel this can be calculated and cached
> rather than looking for it. It is also linear on the number of peers.
> # getGossipStatus: Linear in the number of peers, also source of garbage at
> larger scales.
> It seems optmizing these methods can contribute to a cleaner/performant
> membership protocol. Is there any plans on having these types of optmizations?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
