[
https://issues.apache.org/jira/browse/SOLR-14641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17174239#comment-17174239
]
Ishan Chattopadhyaya edited comment on SOLR-14641 at 8/10/20, 10:41 AM:
------------------------------------------------------------------------
bq. It doesn't make sense to asking everyone do a dedicated performance test
before and after their commits.
I am not requesting performance tests for every commit. But for those that
affect the default code path for all/most users. PeerSync is enabled by
default, as an example.
bq. I believe the right way to ensure performance is coming up with something
like lucene bench, so every downgrade and upgrade will be recorded and can be
watched (per multiple commits).
I totally agree, and that is where I'm going with
https://github.com/thesearchstack/solr-bench. However, in the absence of that,
there is absolutely no reason why we shouldn't perform performance testing
manually before subjecting our users to the changes. I don't want us to repeat
what happened with SOLR-14665 (where the commit happened without any
performance testing, the issue was released and regression was caught only
after the release. And what is worse is that a bugfix release has still not
happened for that).
was (Author: ichattopadhyaya):
bq. It doesn't make sense to asking everyone do a dedicated performance test
before and after their commits.
I am not requesting performance tests for every commit. But for those that
affect the default code path for all/most users. PeerSync is enabled by
default, as an example.
bq. I believe the right way to ensure performance is coming up with something
like lucene bench, so every downgrade and upgrade will be recorded and can be
watched (per multiple commits).
I totally agree, and that is where I'm going with
https://github.com/thesearchstack/solr-bench. However, in the absence of that,
there is absolutely no reason why we shouldn't perform performance testing
manually before subjecting our users to the changes. I don't want us to repeat
what happened with SOLR-14665.
> PeerSync, remove canHandleVersionRanges check
> ---------------------------------------------
>
> Key: SOLR-14641
> URL: https://issues.apache.org/jira/browse/SOLR-14641
> Project: Solr
> Issue Type: Improvement
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
> Fix For: 8.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SOLR-9207 introduces PeerSync with updates range which committed in 6.2 and
> 7.0. To maintain backward compatibility at the time we introduce an endpoint
> in RealTimeGetComponent to check whether a node support that feature or not.
> It served well its purpose and it should be removed to reduce complexity and
> a request-response trip for asking that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
