@ZOS_MattFiror @ZOS_RichLambert @Wrobel
I have no idea on how your database is structured or the logic of your coding.
But I can observe effects that appear to match the symptoms of player contention.
I created this thread to give additional ideas on possible performance improvements if they have not been applied already.

Scenario-1.

4 users are in combat on a server that has 4 cores.
Each user is running in parallel at the same time.
There is 0 cpu contention as the number of users is equal or less than the number of cores.
No user has to wait for cpu cycles.

The data in the database for each user is a record containing fields of attributes per character.
eg.
user1 health magic stamina damage health-regen magic-regen stamina-regen
user2 health magic stamina damage health-regen magic-regen stamina-regen
user3 health magic stamina damage health-regen magic-regen stamina-regen
user4 health magic stamina damage health-regen magic-regen stamina-regen
Thus our database consists of 4 records (No alts here for simplicity).
Only one core/process/user can access any specific record at anytime.
The other cores have to wait until the record is released (writelocked)

user 2/3/4 attack user 1 in parallel, do damage and need to update user1 health.
At the same time user 1 has health regen so also needs to update their health.
Thus we have 4 cores/user that need to modify user1 health at exactly the same time.
Instantly we have a queue of 4 users that want to update the same records attribute.
Each taking it in turn to lock update and then unlock the record.
3:1 contention means user 1 is denied access to their character for 1 in every 4 secs in total.
Thus user 1 gets a laggy and unresponsive character.

Scenario-2.

Now we resturcture the database so each user has their attributes fragmented.
user1 health [write record]
user1 magic [write record]
user1 stamina [write record]
user1 damage [write record]
user1 health-regen [write record]
user1 magic-regen [write record]
user1 stamina-regen [write record]
user1 health magic stamina damage health-regen magic-regen stamina-regen [query read record]

This means user 2 can now debuff user1 stamina.
This means user 3 can now debuff user1 magic.
This means user 4 can now debuff user1 damage.
However, as all of the attributes are seperate records, they can be accessed in parallel by a multithreaded database engine.
Thus contention is 1:1 as long as users dont access the same attribute at the same time.

[NB notice how we have moved to the more modern name/value pairs]

Scenario-3.

After realising the major stunlock issue was down to access contention and thus fragmenting the user record into attributes records.
It dawned on me that we dont have to stop there.
As there are 4 cores and 4 users we actually need 4 versions of each attribute.
I know right...then you get all kinds of corruption and concurrency issues.
Actualy nope! you can actually do it.
All we need is a round robin mechanism that changes health-1 then health 2 then.....
That way there are no write-locks as each user/core works on a unique attribute fragment at all times.

user1 health-1 [write record]
user1 health-2 [write record]
user1 health-3 [write record]
user1 health-4 [write record]
user1 health = health-1 + health-2 + health-3 + health-4 [read record]
user1 health magic stamina damage health-regen magic-regen stamina-regen [query read record]

[NB notice how we have moved to fragmented name/value pairs to allow for multithreading]

Conclusion.

There are 1,000,000s of users.
In an ideal world there would be 1 core for every user and 1 attribute fragment for every user.
This would ensure that there was no cpu cycle contention or writelocked database access contention at any time.
So on the surface that would seem impossible.
BUT...we dont actually need that degree of parallelism.

We actually only need to cater to the amount of people that are in direct combat with each other at any moment in time.
This all depends on the AoE cap limit and the likely numbers involved in XvY.
A good compromise here would probably be 15:1 as a realistic scenario on the amount of people or NPC in direct combat with one player.
Especially if we consider 1 player soloing a dungeon with numerous NPC adds all hitting the player at the same time.
The last thing we want is to be kicked out of a maesltrom arena flawless run, because we suddenly have no control over our character, due to access contention.
The last thing we want is to be attacked by lots of players at once and be completely helpless to evade, hide or even attack in response.