Skip to content

release: v1.59.0#6438

Merged
BrynCooke merged 140 commits intomainfrom
1.59.0
Dec 17, 2024
Merged

release: v1.59.0#6438
BrynCooke merged 140 commits intomainfrom
1.59.0

Conversation

@bnjjj
Copy link
Contributor

@bnjjj bnjjj commented Dec 11, 2024

Note
This particular PR must be true-merged to main.

  • This PR is only ready to review when it is marked as "Ready for Review". It represents the merge to the main branch of an upcoming release (version number in the title).
  • It will act as a staging branch until we are ready to finalize the release.
  • We may cut any number of alpha and release candidate (RC) versions off this branch prior to formalizing it.
  • This PR is primarily a merge commit, so reviewing every individual commit shown below is not necessary since those have been reviewed in their own PR. However, things important to review on this PR once it's marked "Ready for Review":
    • Does this PR target the right branch? (usually, main)
    • Are the appropriate version bumps and release note edits in the end of the commit list (or within the last few commits). In other words, "Did the 'release prep' PR actually land on this branch?"
    • If those things look good, this PR is good to merge!

jonathanrainer and others added 30 commits November 12, 2024 22:05
Adds an initial plugin, that loads at startup and emits metrics
for three simple cases: cpus, cpu_freq and total_memory.
Also improve how we handle refreshing the System
object, rather than doing it in either the callback
or the async task, contain that within a struct
and do it there.
Ensures that gauges will survive hot reload
1. activate is made non-async. It must never fail and it must complete. async fns can halt execution before completion.
2. The spawned thread and channel for fleet detector is removed. There's no need for these. Gauges will be called periodically for export.
3. Telemetry is converted to PrivatePlugin to allow uniform calls to activate.
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Renée <renee.kooi@apollographql.com>
Co-authored-by: Jesse Rosenberger <git@jro.cc>
bnjjj and others added 2 commits December 11, 2024 14:27
)

The router's native, Rust-based, query planner is now generally available and enabled by default.

The native query planner achieves better performance for a variety of graphs. In our tests, we observe:

* 10x median improvement in query planning time (observed via `apollo.router.query_planning.plan.duration`)
* 2.9x improvement in router’s CPU utilization
* 2.2x improvement in router’s memory usage
> Note: you can expect generated plans and subgraph operations in the native query planner to have slight differences when compared to the legacy, JavaScript-based query planner. We've ascertained these differences to be semantically insignificant, based on comparing ~2.5 million known unique user operations in GraphOS as well as comparing ~630 million operations across actual router deployments in shadow mode for a four month duration.

The native query planner supports Federation v2 supergraphs. If you are using Federation v1 today, see our migration guide on how to update your composition build step and subgraph changes are typically not needed.

The legacy, JavaScript, query planner is deprecated in this release, but you can still switch back to it if you are still using Federation v1 supergraph:
```yaml
experimental_query_planner_mode: legacy
```
> Note: The subgraph operations generated by the query planner are not guaranteed consistent release over release. We strongly recommend against relying on the shape of planned subgraph operations, as new router features and optimizations will continuously affect it.

Co-authored-by: Chandrika Srinivasan <chandrikas@users.noreply.github.com>
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
Co-authored-by: Shane Myrick <mail@shanemyrick.com>
@lrlna
Copy link
Member

lrlna commented Dec 12, 2024

the docs for QP GA are in now too^^

Co-authored-by: Edward Huang <edward.huang@apollographql.com>
@BrynCooke BrynCooke marked this pull request as ready for review December 16, 2024 11:00
@BrynCooke BrynCooke requested a review from a team December 16, 2024 11:00
BrynCooke and others added 2 commits December 16, 2024 11:02
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
Co-authored-by: Edward Huang <edward.huang@apollographql.com>
As per docs suggestion, remove this changeset
Copy link
Contributor

@BrynCooke BrynCooke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Block

Comment on lines +1 to +5
### Drop experimental reuse fragment query optimization option ([PR #6354](https://github.com/apollographql/router/pull/6354))

Drop support for the experimental reuse fragment query optimization. This implementation was not only very slow but also very buggy due to its complexity.

Auto generation of fragments is a much simpler (and faster) algorithm that in most cases produces better results. Fragment auto generation is the default optimization since v1.58 release.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Drop experimental reuse fragment query optimization option ([PR #6354](https://github.com/apollographql/router/pull/6354))
Drop support for the experimental reuse fragment query optimization. This implementation was not only very slow but also very buggy due to its complexity.
Auto generation of fragments is a much simpler (and faster) algorithm that in most cases produces better results. Fragment auto generation is the default optimization since v1.58 release.
### Drop experimental reuse fragment query optimization option ([PR #6354](https://github.com/apollographql/router/pull/6354))
We've dropped support for the `experimental_reuse_query_fragments` option. Its implementation didn't achieve good enough performance or reliability.
In its place, the router uses fragment auto generation. As the default implementation since router v1.58, in most cases fragment auto generation achieves better performance and results.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry the prep already happened.

@BrynCooke BrynCooke enabled auto-merge December 17, 2024 10:36
@BrynCooke BrynCooke merged commit 3bdcacd into main Dec 17, 2024
@BrynCooke BrynCooke deleted the 1.59.0 branch December 17, 2024 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.