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.
According to composer's suggestions, the SDK now has built-in support for request caching via doctrine/cache. This could potentially replace our custom metadata caching and give us a general performance boost.
We should also look into Guzzle's built in caching as it might be even more comprehensive.
There's a bug with the metadata cache clearing button in that if you press enter on a form field, that submit button is triggered instead of the configuration submit button. If we still need that, we should fix it along with this issue.
Comment | File | Size | Author |
---|---|---|---|
#4 | 2470127.4-doctrine-caching.patch | 12.05 KB | deviantintegral |
#3 | 2470127.3-doctrine-caching.patch | 11.19 KB | deviantintegral |
Comments
Comment #1
deviantintegral CreditAttribution: deviantintegral at Lullabot for NBCUniversal commentedComment #2
deviantintegral CreditAttribution: deviantintegral at Lullabot for NBCUniversal commentedComment #3
deviantintegral CreditAttribution: deviantintegral at Lullabot for NBCUniversal commentedIt turns out that caching was only supported for credentials, and not any other type of request. I've filed an upstream PR, and pointed composer to my fork with that patch.
In the best case where data is all cached, with some WIP code I have for image styles, a file_exists() call on the S3 derivative and a redirect is reduced from ~275ms to ~60ms. In the case where an image style has to be generated, it's a savings of around 20% on an unfortunately large 4-5 seconds.
Comment #4
deviantintegral CreditAttribution: deviantintegral at Lullabot for NBCUniversal commentedFixes always forcing the cache to be on.
Comment #6
deviantintegral CreditAttribution: deviantintegral at Lullabot for NBCUniversal commentedI've committed this over at http://cgit.drupalcode.org/amazons3/commit/?id=191c197