Performance: Re-introduce lazy locks

[lauraneto]

Summary

• Re-enables lazy locking in LockingMechanism by switching ReadLock and WriteLock to use their lazy implementations instead of eager ones

Background

The codebase already had the concept of lazy vs eager locks, but locks were always being acquired eagerly. This caused unnecessary database queries even when the actual data was already cached at the repository level.

The typical pattern:

using ICoreScope scope = ScopeProvider.CreateCoreScope(autoComplete: true);
scope.ReadLock(Constants.Locks.MediaTree);
return _mediaRepository.Get(id);

Even if the media is cached, the eager lock still hits the database. With lazy locks, the lock is only acquired if and when the database is actually accessed.

Benefits

• Reduces database round-trips when data is served from repository cache
• Improves performance especially with latency between web server and database
• Makes better use of existing repository caches instead of requiring additional request-level caching workarounds

Load Test Results

All tests performed after rebasing on PR #21105 (deadlock fix). Each configuration was tested 5 times to ensure consistency.

Test 1: Cache-Hit Stress Test (50 VUs, 1000 iterations, 100% reads)

Tests performance when serving cached data - the ideal scenario for lazy locks to shine.

Database	Lazy Locks	Eager Locks	Improvement
SQL Server	19.93ms avg	28.15ms avg	29% faster
SQLite	~same	~same	No significant difference

SQL Server Detail:

• Lazy: avg 19.93ms, p95 69.28ms
• Eager: avg 28.15ms, p95 131.51ms
• Lazy locks skip lock acquisition on cache hits, reducing database round-trips

Test 2: Write-Heavy Stress Test (50 VUs, 200 iterations, mixed workload)

Tests high-concurrency write operations (create content type → GET → create content → GET → publish).

Database	Lazy Locks	Eager Locks	Improvement
SQL Server	1.22s avg	1.36s avg	10% faster
SQLite	623ms avg	731ms avg	15% faster

SQL Server Detail:

• Lazy: 1.22s avg, 35.4 req/s throughput, 0% failure rate
• Eager: 1.36s avg, 32.6 req/s throughput, 0.06% failure rate

SQLite Detail:

• Lazy: 623ms avg, 63.6 req/s throughput
• Eager: 731ms avg, 55.4 req/s throughput

Key Findings

1. SQL Server sees consistent improvement - Both read-heavy (29% faster) and write-heavy (10% faster) scenarios benefit from lazy locks under high concurrency.

2. Performance gap increases under load - Higher VU counts (50 vs 20) showed more pronounced benefits from lazy locks.

3. SQLite benefits from writes, not reads - SQLite's single-writer lock model means cache-hit scenarios don't benefit as much, but write-heavy workloads still see 15% improvement.

4. Both configurations are stable - No deadlocks observed with either approach after the PR Content Publishing: Fix deadlocks by acquiring WriteLock at outer scope #21105 fix.

Test plan

• Load test with SQL Server (cache-hit stress + write-heavy stress)
• Load test with SQLite (cache-hit stress + write-heavy stress)
• Verify no deadlocks after rebasing on Content Publishing: Fix deadlocks by acquiring WriteLock at outer scope #21105

[Copilot]

Pull request overview

This PR re-introduces lazy locking to improve performance by deferring database lock acquisition until data is actually accessed, rather than acquiring locks eagerly at the start of operations. This optimization reduces unnecessary database round-trips when data is served from repository caches, showing significant performance improvements in load testing (29% faster for cache-hit scenarios on SQL Server, 10-15% faster for write-heavy workloads).

Key Changes:

• Switched ReadLock and WriteLock in LockingMechanism to use lazy implementations instead of eager ones
• Added missing WriteLock to ContentPublishingService.PublishAsync for thread safety consistency

Reviewed changes

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

File	Description
src/Umbraco.Core/Scoping/LockingMechanism.cs	Changes ReadLock and WriteLock to use LazyReadLockInner and LazyWriteLockInner instead of EagerReadLockInner and EagerWriteLockInner, enabling deferred lock acquisition
src/Umbraco.Core/Services/ContentPublishingService.cs	Adds WriteLock call to PublishAsync method, ensuring consistent locking pattern with other content mutation operations

The changes look good and follow established patterns in the codebase. The added lock in ContentPublishingService is consistent with similar operations in ContentService (e.g., Unpublish, PublishBranch), and the lazy lock implementation properly queues locks for later acquisition. No issues were found during review.

[lauraneto]

@AndyButland Adding you as reviewer as I know you have been working on some performance improvements, so hoping you might have a "real" data set that we can test the change against.
When I was running tests, the improvements were only visible when I really increased the concurrency, otherwise they were similar or sometimes even worse with the lazy (keep in mind this was ran against a local database, so very few delays).

[AndyButland]

I've done some tests using a setup with Umbraco running locally and connecting to a database in Azure - so very high latency between web application and database. Not a particularly real-world scenario for production, but it only exaggerates the concern so makes it easier to see improvements.

I'm testing using a sample database and a document that contains seven published languages and multiple blocks. For each test, I've restarted the website, refreshed the backoffice content page and saved and published once before measuring.

Using code from main branch

	1	2	3	Average (s)
Validate	1.31	0.96	0.86	1.04
Save	5.51	4.54	4.22	4.76
Publish	14.27	13.28	13.38	13.64

Using code from this branch with lazy locks

	1	2	3	Average (s)	Improvement
Validate	0.35	0.39	0.41	0.38	63.3%
Save	3.4	3.2	2.92	3.17	33.3%
Publish	12.9	12.8	13	12.90	5.4%

Using code with read locks disabled

	1	2	3	Average (s)	Improvement
Validate	0.39	0.31	0.43	0.38	63.9%
Save	2.97	2.97	2.96	2.97	37.6%
Publish	12.39	12.09	12.25	12.24	10.3%

So overall:

• Some clear improvements, particularly on the validate and save steps.
• For publishing there's some improvement, but much less. And as this is still the part that takes the longest, it's not on it's own going to give a big performance boost.

This matches with previous analysis I did, finding the bulk of the time taken in the publish operation to be in ContentRepositoryBase.ReplacePropertyValues, where we are writing rather than reading. The main time taken in this is with the property updates in the database, where after publishing we update existing property data records and insert new ones.

From a one-off test here:

Overall Publish	12.52
Update Property Data (85 records)	5.36	42.8%
Insert Property Data (133 records)	2.43	19.4%
Delete Property Data (48 records)	0.035	0.3%

Given we are already using SQL bulk insert and update batch statements here, it's not obvious how we might further improve this part.

Nonetheless, the update in this PR looks clearly a net benefit to re-introduce.

[AndyButland]

Following team discussion we've decided to include this for 17.1. Testing has shown a clear performance improvement and we haven't been able to show any evidence for the deadlock concern that was raised as a reason for historically removing them in the past.