Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

internal/plugin+internal/plugin6: Fix provider schema caching #33768

Closed
wants to merge 1 commit into from

Conversation

bflad
Copy link
Contributor

@bflad bflad commented Aug 30, 2023

Reference: #33486

The intention of this logic is to use the global provider schema cache if it is available for a given provider address based on the GetProviderSchemaOptional server capability. Previously the logic was errantly checking the named return early, which was not populated yet with the server response. This flips the logic to properly use the server response to determine whether the cache should be set, thereby still gating the caching based on the server capability.

In a configuration with 19 hashicorp/aws provider instances and an associated data source, this drops the received GetProviderSchema calls from 39 calls to 1 call with this change. Maximum RSS dropped from 1.22 GB to 189 MB.

Target Release

1.6.x

Draft CHANGELOG entry

N/A (already changelog'd as #33486)

Reference: #33482

The intention of this logic is to use the global provider schema cache if it is available for a given provider address based on the `GetProviderSchemaOptional` server capability. Previously the logic was errantly checking the named return early, which was not populated yet with the server response. This flips the logic to properly use the server response to determine whether the cache should be set, thereby still gating the caching based on the server capability.

In a configuration with 19 `hashicorp/aws` provider instances and an associated data source, this drops the received `GetProviderSchema` calls from 39(?) to 1. Maximum RSS dropped from 1.22 GB to 189 MB.
@bflad
Copy link
Contributor Author

bflad commented Aug 30, 2023

While this does actually enable cache usage, in my negative, real-world testing of this with hashicorp/aws version 5.14.0 and the same configuration, there is a significant performance decrease with AttachSchemaTransformer execution compared to Terraform 1.6.0-alpha20230816 (we're talking 30+ seconds each graph walk).

@kmoe kmoe marked this pull request as draft August 30, 2023 15:39
@apparentlymart apparentlymart requested a review from a team August 30, 2023 16:28
@jbardin
Copy link
Member

jbardin commented Sep 5, 2023

The reason this slows everything down is that it reverses the logic required by core to actually use the cache. The cache must be set for every single provider, because otherwise core needs to spin up a new provider instance each time it wants to fetch the schema, which is why you run into performance issues. Because every provider method internally must call GetProviderSchema to both get the schema for serialization and ensure that GetProviderSchema was called for provider instances which require it, the condition must be checked at the start of GetProviderSchema, not the end.

Since the aws provider does not yet enable GetProviderSchemaOptional, we cannot get the benefits yet of the schema caching on the provider side because we will always need to spin up every provider to call GetProviderSchema again. I'm actually not able to replicate your findings though, with applying this patch resulting in more calls to GetProviderSchema overall, nor can I explain the drop in RSS since the total number of provider processes should be the same.

@bflad
Copy link
Contributor Author

bflad commented Sep 6, 2023

Superseded by #33807 👍

@bflad bflad closed this Sep 6, 2023
@bflad bflad deleted the bflad/getproviderschema-caching branch September 6, 2023 09:18
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants