Hans Karlsen (talk | contribs) No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
When a server process like MDriven Turnkey | When a server process like MDriven Turnkey or MDrivenServer service holds several ecospaces in the same process, we now (from 2023-04-09) have a mechanism called SharedBigValue. | ||
What this does is: | What this does is: | ||
# If a loaded attribute value is byte[] or string | # If a loaded attribute value is a byte[] or string | ||
# | # Larger than 8192 bytes | ||
# Is the maxint in version (latest version) | # Is the maxint in version (latest version) | ||
# | # Shares the same object id, and attribute id | ||
# | # Shares typesystem checksum | ||
...if above is true the cache will really hold a SharedBigValue. | ...if the above is true, the cache will really hold a SharedBigValue. | ||
All public access methods to get to a cache value will screen for a SharedBigValue - and if found - resolve to a | All public access methods to get to a cache value will screen for a SharedBigValue - and if found - resolve to a real value and return this. | ||
Only when objects are loaded from PS and | Only when objects are loaded from PS and hit the ApplyDataBlock method do we consider creating or looking up SharedBigValue. | ||
We do this by keeping a static dictionary on the Cache that is key,SharedBigValue. | We do this by keeping a static dictionary on the Cache that is key, SharedBigValue. | ||
If key already exists we return the existing SharedBigValue | If the key already exists, we return the existing SharedBigValue - otherwise, we create a SharedBigValue and return it (and store it in the dictionary). | ||
Reading is protected by a ReadLock that can be upgraded to WriteLock if we need to create | Reading is protected by a ReadLock that can be upgraded to WriteLock if we need to create. | ||
<nowiki>---------</nowiki> | <nowiki>---------</nowiki> | ||
Limitations that I | Limitations that I consider to be ok until reality proves otherwise: | ||
# It is only | # It is only DB loaded (old value) that is the target for SharedBigValue - thus write/update of large blocks are handled as before - and we do not try to share this. | ||
# We do not actively destroy SharedBigValue's if a new model is uploaded - changing the checksum - and forcing all existing ecospaces to be recreated - this is considered to | # We do not actively destroy SharedBigValue's if a new model is uploaded - changing the checksum - and forcing all existing ecospaces to be recreated - this is considered to be an uncommon production scenario. | ||
<nowiki>----</nowiki> | <nowiki>----</nowiki> | ||
Ways to test: Model with Image and Text, run Turnkey with two different users, or two different browsers, update large text and image in one - make sure it updates in other | Ways to test: Model with Image and Text, run Turnkey with two different users, or two different browsers, update large text and image in one - make sure it updates in the other | ||
<nowiki>----</nowiki> | <nowiki>----</nowiki> | ||
Expected positive effect: Only one instance of large things | Expected positive effect: Only one instance of large things is held in memory even if 1000 users look at this same thing. | ||
Expected negative effect: additional overhead for large texts and byte arrays but kept low by checks above - I do not expect it to be noticeable. | Expected negative effect: additional overhead for large texts and byte arrays but kept low by checks above - I do not expect it to be noticeable. | ||
Currently this feature is always on, you can stop | Currently, this feature is always on, you can stop it from having an effect by setting: | ||
FetchedBlockHandler.kBigValueThreshold=int.MaxValue; | FetchedBlockHandler.kBigValueThreshold=int.MaxValue; | ||
Revision as of 06:16, 12 April 2023
When a server process like MDriven Turnkey or MDrivenServer service holds several ecospaces in the same process, we now (from 2023-04-09) have a mechanism called SharedBigValue.
What this does is:
- If a loaded attribute value is a byte[] or string
- Larger than 8192 bytes
- Is the maxint in version (latest version)
- Shares the same object id, and attribute id
- Shares typesystem checksum
...if the above is true, the cache will really hold a SharedBigValue.
All public access methods to get to a cache value will screen for a SharedBigValue - and if found - resolve to a real value and return this.
Only when objects are loaded from PS and hit the ApplyDataBlock method do we consider creating or looking up SharedBigValue.
We do this by keeping a static dictionary on the Cache that is key, SharedBigValue.
If the key already exists, we return the existing SharedBigValue - otherwise, we create a SharedBigValue and return it (and store it in the dictionary).
Reading is protected by a ReadLock that can be upgraded to WriteLock if we need to create.
---------
Limitations that I consider to be ok until reality proves otherwise:
- It is only DB loaded (old value) that is the target for SharedBigValue - thus write/update of large blocks are handled as before - and we do not try to share this.
- We do not actively destroy SharedBigValue's if a new model is uploaded - changing the checksum - and forcing all existing ecospaces to be recreated - this is considered to be an uncommon production scenario.
----
Ways to test: Model with Image and Text, run Turnkey with two different users, or two different browsers, update large text and image in one - make sure it updates in the other
----
Expected positive effect: Only one instance of large things is held in memory even if 1000 users look at this same thing.
Expected negative effect: additional overhead for large texts and byte arrays but kept low by checks above - I do not expect it to be noticeable.
Currently, this feature is always on, you can stop it from having an effect by setting:
FetchedBlockHandler.kBigValueThreshold=int.MaxValue;