Performance: Optimize memory footprint of document URL cache (closes #21055)

[AndyButland]

Prerequisites

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

Addresses #21055

Description

The linked issue raises the concern of the memory footprint of the document URL cache, which is loaded on start-up and held for the lifetime of the application.

My understanding with the introduction of the Hybrid cache was that this was deliberately separated out, so we guarantee URLs are in the cache for routing, but can lazy load documents. So I haven't looked at lazy loading of document URLs as a solution to this.

Rather it seems we can optimize quite a bit the amount of memory the cache takes up. Having done some analysis on it it's apparent we can improve in a few areas:

• The key we are using is unnecessarily verbose as a string containing each element.
• We use the larger culture code instead of the smaller language Id in the cache key.
• We have some items in the value that are already available in the key.
• In the handling of the (rare) case of multiple segments for a document, we are allocating an array, that most of the time we won't need.

I see some significant improvements - ~58% - with a small and quite large database (these figures compare the current implementation with the one in this PR):

[14:59:08 INF] Cached 218 document URLs.
[14:59:08 INF] Document URL cache estimated memory usage: 0.08 MB (80,846 bytes).
[15:01:00 INF] Cached 218 document URLs.
[15:01:00 INF] Document URL cache estimated memory usage: 0.03 MB (34,212 bytes).	

[15:38:12 INF] Cached 1405554 document URLs.
[15:38:13 INF] Document URL cache estimated memory usage: 527.13 MB (552,737,556 bytes).
[15:36:52 INF] Cached 1405554 document URLs.
[15:36:53 INF] Document URL cache estimated memory usage: 236.26 MB (247,739,944 bytes).

Testing

Verify existing integration tests pass and via manual testing that documents can be routed.

[Copilot]

Pull request overview

This PR optimizes the memory footprint of the document URL cache in Umbraco CMS, achieving approximately 58% memory reduction (from 527MB to 236MB with 1.4M documents, and from 80KB to 34KB with 218 documents) without sacrificing performance.

Key Changes:

• Replaced verbose string-based cache keys with a compact struct (UrlCacheKey) using int language IDs instead of culture strings
• Implemented a more memory-efficient cache value structure (UrlSegmentCache) that stores the primary segment directly and only allocates an array for alternate segments when needed (rare case)
• Added a culture-to-language-ID mapping cache to enable the use of integer IDs for lookups
• Introduced memory usage calculation and logging for better observability

Reviewed changes

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

File	Description
src/Umbraco.Core/Services/DocumentUrlService.cs	Core implementation: Introduced UrlCacheKey struct and UrlSegmentCache class for memory-efficient caching, refactored cache storage from string keys to struct keys, added culture-to-language-ID mapping, implemented memory usage calculation, and updated all cache operations (init, lookup, update, remove) to use the new structures
tests/Umbraco.Tests.UnitTests/Umbraco.Core/Services/DocumentUrlServiceTests.cs	Updated unit tests to validate the new cache model structure (Key/Cache tuple instead of single object), verified correct handling of primary/alternate segments, and updated performance benchmark comments to reflect the current implementation

[Migaroez]

LGTM
The only concern I have is the future impact of the language id changing to a key, but it think even then it will be better than it was.