perf(dbless): load declarative schema during init() #10932
Conversation
This updates the logic in Kong.init() to load the declarative config schema and store it in the kong global at `kong.db.declarative_config`. This brings a substantial perf improvement to the /config endpoint, which was previously reloading the schema on every request.
|
Seems worthy of a backport--at very least to 3.3. @hbagdi feel free to add/remove backport labels. |
|
well, no one has complained. |
@hanshuebner what I meant was that this doesn't need any new tests. There are plenty of tests for the components that were changed in this PR, and they would certainly fail if this change yielded unintended breakage. At a quick glance here are some: The following tests exercise the declarative config endpoint (
And the following tests exercise the data plane configuration reload functionality:
|
|
@flrgh I updated the PR description to include the testing information. |
|
The backport to To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-release/3.3.x release/3.3.x
# Navigate to the new working tree
cd .worktrees/backport-release/3.3.x
# Create a new branch
git switch --create backport-10932-to-release/3.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 c339a8cb7a854da448c1e7e71944f9e0b46a0956
# Push it to GitHub
git push --set-upstream origin backport-10932-to-release/3.3.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-release/3.3.xThen, create a pull request where the |
* perf(dbless): load declarative schema during init() This updates the logic in Kong.init() to load the declarative config schema and store it in the kong global at `kong.db.declarative_config`. This brings a substantial perf improvement to the /config endpoint, which was previously reloading the schema on every request. * docs(changelog): add entry for 10932 (cherry picked from commit c339a8c)
* perf(dbless): load declarative schema during init() This updates the logic in Kong.init() to load the declarative config schema and store it in the kong global at `kong.db.declarative_config`. This brings a substantial perf improvement to the /config endpoint, which was previously reloading the schema on every request. * docs(changelog): add entry for 10932 (cherry picked from commit c339a8c)
Summary
I was curious as to why some admin API tests for
/configwere so slow and went digging. Turns out this endpoint was reloading the declarative schema on every request, adding several hundred milliseconds of latency.This updates the logic in Kong.init() to load the declarative config schema and store it in the kong global at
kong.db.declarative_config.before
after
No additional tests are needed because the functionality is already tested:
The following tests exercise the declarative config endpoint (POST /config):
spec/02-integration/02-cmd/03-reload_spec.lua
spec/02-integration/04-admin_api/11-reports_spec.lua
spec/02-integration/04-admin_api/15-off_spec.lua
spec/02-integration/05-proxy/02-router_spec.lua
spec/02-integration/08-status_api/01-core_routes_spec.lua
spec/02-integration/08-status_api/03-readiness_endpoint_spec.lua
spec/02-integration/11-dbless/01-respawn_spec.lua
spec/02-integration/11-dbless/03-config_persistence_spec.lua
And the following tests exercise the data plane configuration reload functionality:
spec/02-integration/09-hybrid_mode/01-sync_spec.lua
spec/02-integration/09-hybrid_mode/03-pki_spec.lua
spec/02-integration/09-hybrid_mode/04-cp_cluster_sync_spec.lua
spec/02-integration/09-hybrid_mode/08-lazy_export_spec.lua
spec/02-integration/09-hybrid_mode/09-config-compat_spec.lua
spec/02-integration/09-hybrid_mode/10-forward-proxy_spec.lua
Checklist
The Pull Request has testsN/A - tested by existing testsThere is a user-facing docs PR