Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Would it make sense to use Drupal's static variable storage to store keys? Then a key would only need to be retrieved once per page request.
Comments
Comment #1
rlhawkHere is a patch that implements static variable storage for keys.
Comment #2
gregglesDid you see a real performance benefit from this? Any numbers you can share on benefit and the scenario where it's helpful?
I feel like there's a chance that the provider might provide a different key even if the name is the same, right? Why not use more data in the static array to ensure the result is 100% the same?
Comment #3
rlhawkInteresting. I hadn't thought of that. So, a single key provider could return a different value within a page request—based on, for example, the node ID and/or a field name, or something else that's specific to that particular piece of data.
I did a rough Apache Benchmark comparison (1000 requests of 50 nodes with 20 encrypted fields) with the basic, default encryption method and the Drupal Private Key as the key provider and the difference with and without static variable storage was negligible. However, I'm writing a key provider plugin that retrieves a key from an external server, so it would be preferable to avoid making a lot of unnecessary external requests.
I can certainly use static variable storage within my specific key provider plugin, but I thought it could be useful generally in the Encryption module.
Presumably, the key provider plugin that is calling encrypt_get_key_from_key_provider would know if it could take advantage of static variable storage, so perhaps there could be a second argument to that function, $static, that is FALSE by default, so as not to break any existing implementations. If it's set to TRUE, the function would use the static variable, if it's available. I expect that the three key providers that are included with Encryption could use it.
Comment #4
gregglesAh, that makes total sense that a key provider might be slow.
I don't know that the key would change, just trying to think of ways this patch might break stuff. I think since all of the existing key providers can work fine with it then let's do it. We might want to add some docs about how a custom site would work around this and the scenarios where that would be necessary. Can you do that? Marking needs work for it.
Comment #5
rlhawkAbsolutely, I'll do that. Thanks, Greg.
Comment #6
rlhawkI realize that the last paragraph in my previous post doesn't make sense. encrypt_get_key_from_key_provider isn't called by the plugin; it's the other way around. So either each key provider plugin can implement static variable storage on its own, or whether or not it should be used can be set in the plugin definition.
Comment #7
rlhawkOK, the attached patch does the following:
Comment #8
rlhawkChanging status.
Comment #9
rlhawkChanging status.
Comment #10
rlhawkDue to the addition of configurations, the previously submitted patch is no longer applicable. In order to determine if a key has already been retrieved, we need to use a unique hash of the provider name and settings to identify it. Here's a new patch that does that.
Comment #11
rlhawkI made a slight modification, so here's a new patch.
Comment #12
crashtest_ CreditAttribution: crashtest_ commentedLatest patch applies cleanly, and produces expected behavior. Tested with static setting TRUE and FALSE. Works.
Comment #13
rlhawkThis is committed.