Performance: Added request cache to media type retrieval in media picker validation

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

From internal support issue.

Description

#18429 introduced server-side validation for the media picker, including validating that the types of the media provided are permitted via the configured allowed types.

In here there's a call to retrieve the media type from it's alias.

This in itself is cached at the repository, but there's a read lock placed each time and that requires a tiny database query. When you multiply languages x blocks x media properties - this can be a lot of calls. Running locally this is negligible, but running locally with a database in Azure, on the test site I've been working with, it's many times slower. Running a website and a database in Azure won't be quite that bad, but they are still running on different machines so seems this latency for even this small query multiple times can be a problem.

I found it just by turning all read locks off and finding much more acceptable performance, and then looked to where they were all coming from, and found them in the media picker validation.

To resolve I've added a request cache so we only retrieve each media type once at most, no matter how many blocks/languages/properties there are.

Testing

See test steps on #18429 for verifying that the server-side validation still works as it should.

Adding _logger.LogInformation("Requesting read lock(s) {LockIds} for scope {InstanceId}", string.Join(", ", lockIds), instanceId); to LockingMechanism.EagerReadLockInner() will allow you see read locks as they are created and verify that only one should be called for each allowed media type.

[Copilot]

Pull Request Overview

This PR adds request-level caching to media type retrieval in the MediaPicker3 validation to improve performance when validating multiple media items across languages and blocks. The caching prevents redundant database queries for the same media type during a single request.

Key Changes

• Added AppCaches dependency to MediaPicker3PropertyValueEditor and AllowedTypeValidator
• Implemented request cache for media type lookups using media type keys instead of full objects
• Updated unit tests to include the new AppCaches parameter

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/Umbraco.Infrastructure/PropertyEditors/MediaPicker3PropertyEditor.cs	Added AppCaches parameter and implemented request caching for media type lookups in validation
tests/Umbraco.Tests.UnitTests/Umbraco.Core/PropertyEditors/MediaPicker3ValueEditorValidationTests.cs	Updated test constructor to include AppCaches.Disabled parameter
tests/Umbraco.Tests.UnitTests/Umbraco.Core/PropertyEditors/DataValueReferenceFactoryCollectionTests.cs	Updated test constructor to include AppCaches.Disabled parameter

[Migaroez]

It works, and I agree that we need this bandaid.

But we really need to look into how to deal with determning all the requirements (datatypes/elementypes/...) to process (validate/update/clean/...) these types of nested content. This is the second "caching" mechanism on top of our repository caches that gets introduced now (see BlockEditorElementTypeCache).

[umbracocommunity]

This pull request has been mentioned on Umbraco community forum. There might be relevant details there:

https://forum.umbraco.com/t/website-significantly-slower-since-upgrading-from-v13-to-v16/6049/18