[
https://issues.apache.org/jira/browse/SOLR-16531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656156#comment-17656156
]
Jason Gerlowski edited comment on SOLR-16531 at 1/9/23 5:48 PM:
----------------------------------------------------------------
bq. The problem is, as there is a known perf degradation , nobody can do any
test of perf on any commits.
As I said - if Ishan still holds his veto, I will roll back the changes whether
I "understand" or not, because that's the timeline that was agreed to.
But I have to admit that I've never really understood this point about the
JAX-RS integration making it somehow impossible to measure performance on
branch_9x, and I would really like to.
Performance measurement is inherently a relative exercise: take a baseline
measurement, make a change, measure again, and compute the delta. If the
JAX-RS integration has introduced some slowdown - well that's accounted for in
the baseline, so the measured "delta" is still meaningful. And if you're
worried that the JAX-RS integration might obscure some other
performance-impacting change - there's a feature flag to disable it in your
perf testing.
bq. What are the gaps with app-per-ConfigSet?
I think the gaps depend on what design/scope we want to shoot for. For cores
using the same configset: do we only want to share Jersey apps? What about v2
ApiBags and v1 requestHandlers? What about other solrconfig.xml-configured
plugins? If we want cores to share a set of requestHandlers, how would metrics
be handled since those currently live at the requestHandler level? etc.
I'm going to start in on a more involved spike that attempts to share Jersey
apps, ApiBags, and requestHandlers with the goal of flushing out any
hangups/blockers and figuring out how metrics will need to be handled. So
hopefully that'll help inform some of those questions above. But the answers
probably need to come from community-need too. (e.g. Maybe some multi-tenant
usecases don't want to share rH's across cores. etc.). I'll file a ticket for
this effort today so we have a dedicated place for app-per-configset
discussion. *EDIT*: see SOLR-16615
was (Author: gerlowskija):
bq. The problem is, as there is a known perf degradation , nobody can do any
test of perf on any commits.
As I said - if Ishan still holds his veto, I will roll back the changes whether
I "understand" or not, because that's the timeline that was agreed to.
But I have to admit that I've never really understood this point about the
JAX-RS integration making it somehow impossible to measure performance on
branch_9x, and I would really like to.
Performance measurement is inherently a relative exercise: take a baseline
measurement, make a change, measure again, and compute the delta. If the
JAX-RS integration has introduced some slowdown - well that's accounted for in
the baseline, so the measured "delta" is still meaningful. And if you're
worried that the JAX-RS integration might obscure some other
performance-impacting change - there's a feature flag to disable it in your
perf testing.
bq. What are the gaps with app-per-ConfigSet?
I think the gaps depend on what design/scope we want to shoot for. For cores
using the same configset: do we only want to share Jersey apps? What about v2
ApiBags and v1 requestHandlers? What about other solrconfig.xml-configured
plugins? If we want cores to share a set of requestHandlers, how would metrics
be handled since those currently live at the requestHandler level? etc.
I'm going to start in on a more involved spike that attempts to share Jersey
apps, ApiBags, and requestHandlers with the goal of flushing out any
hangups/blockers and figuring out how metrics will need to be handled. So
hopefully that'll help inform some of those questions above. But the answers
probably need to come from community-need too. (e.g. Maybe some multi-tenant
usecases don't want to share rH's across cores. etc.). I'll file a ticket for
this effort today so we have a dedicated place for app-per-configset discussion.
> Performance degradation due to introduction of JAX-RS
> -----------------------------------------------------
>
> Key: SOLR-16531
> URL: https://issues.apache.org/jira/browse/SOLR-16531
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
> Priority: Blocker
> Fix For: 9.2
>
> Attachments: Screenshot from 2022-11-09 11-20-44.png,
> jaxrs-integration-with-app-per-configset-flamegraph.html,
> results-with-patch.tar.gz, vanilla-jaxrs-integration-flamegraph.html
>
>
> During performance benchmarking on branch_9x, I observed a slowdown in
> restart performance since commits in SOLR-16347. See attached screenshot.
> CC [~gerlowskija].
> http://mostly.cool/cluster-test-with-patch.html
> The benchmark is here:
> https://github.com/fullstorydev/solr-bench/blob/ishan/repeatable-jenkins/suites/cluster-test.json.
> This suite was run after retro-actively applying the parallelStream patch
> from SOLR-16414:
> https://github.com/apache/solr/commit/b33161d0cdd976fc0c3dc78c4afafceb4db671cf.diff
>
> Effort to automate these benchmarks is WIP and tracked here: SOLR-16525.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
