[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642700#comment-17642700
]
Noble Paul commented on SOLR-16347:
-----------------------------------
{quote}I really wish you'd include full context around claims like "33%
slower". Node startup isn't 33% slower in all, or even in most cases...
{quote}
You are missing the bigger picture.
If you introduce a 30% slowdown on *core* startup,
* a *node restart* degradation will be much smaller than 30% if you have a
*single core*
* a *node start* perf degradation will be even more pronounced with a *single
core*
* a *node start time with a 1000 cores* will be even more pronounced and much
closer to the 30% core startup degradation
Interestingly we do not have a *core startup* test and we only have a node
restart test. We were fortunate that we tested with a 1000 cores and this got
uncovered.
The fact is this commit caused a *~30% perf degradation* in *core startup* and
coincidentally it got caught in a node start test
{quote}would you feel better about things if I held off on subsequent branch_9x
JAX-RS backports until more progress has been made on the underlying regression?
{quote}
That is not a good idea because,
* In the performance benchmarks 9x branch is already slower than 9.1 . So if
some other commits cause perf degradation in 9x branch it can get masked
* Committers who work on other features cannot touch classes modified by this
commit
We have already spent 3-4 weeks after this bug was uncovered and let us not
wait any longer
Any progress must be made in a separate branch and we should reintroduce the
changes only after all the concerns are addressed.
Going forward, we should it make it a practice to immediately revert changes to
the stable branch if it causes a perf degradation
> Add JAX-RS integration for defining v2 APIs
> -------------------------------------------
>
> Key: SOLR-16347
> URL: https://issues.apache.org/jira/browse/SOLR-16347
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> SOLR-15182 rewrote our v2 APIs to use annotations using an existing
> (in-house) framework. But continuing to use a homegrown framework is less
> than ideal for a few reasons:
> # Our in-house framework doesn't integrate with 3rd-party tooling like
> OpenAPI.
> # It gives us less functionality than many off-the-shelf frameworks, at a
> higher maintenance cost.
> # The current framework is less explicit about API inputs and outputs than
> many off-the-shelf alternatives, making code less clear and readable for
> developers.
> (For more on the pros/cons and for different evaluations on the tradeoff
> here, see
> [this|https://lists.apache.org/thread/6wx2vzfnmfgkw03b7s450zfp7yhrlz8f]
> long-running dev@ thread.)
> The work done by SOLR-15182 makes the jump to JAX-RS reasonably
> straightforward on an individual API basis: once the framework is in place
> switching a given API to JAX-RS is mostly a matter of swapping out our
> homegrown annotations for those recognized by JAX-RS and changing API method
> signatures to better represent the API inputs/outputs.
> We should integrate Jersey or a similar JAX-RS implementation and start
> cutting over v2 APIs to this new mode of definition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
