|Anonymous | Login | Signup for a new account||2019-06-17 16:41 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007676||opensim||[GRID] Asset Service||public||2015-08-11 13:00||2016-06-22 07:05|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0007676: Setting accesstime for assets in mysql database|
|Description||Field access_time in mysql asset database is not updated after accessing an asset from the region.|
Code to do an update allready exists but is never called.
This patch add a call to the update.
Updating asset access_time is important because there are scenarios where you need to know if assets are still be accessed.
If an asset is no longer being accessed for a long time, you might want to move it to another place and, after an additional time, remove it.
It also is senseless to have an column called access_time when its not used.
|Steps To Reproduce||Clear your regions asset cache and restart it.|
Watch then at the access_time column in your asset database table.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Standalone (1 Region)|
|Environment||.NET / Windows64|
|Attached Files||AssetAccessTime.patch [^] (961 bytes) 2015-08-11 13:00 [Show Content]|
Gavin Hird (reporter)
This is probably OK for a slow grid, but for a large grid it will cause a significant increase in writes to the database which may impact performance.
At a minimum there ought to be a config switch to turn this on or off.
If this will slow down the grid and is currently unused, why is the column available and the code still remaining?
I can't belive we actually have and will have grids with a size required to decrease performance that much.
Gavin Hird (reporter)
Perhaps someone thought it was a good idea, but disabled the code when they saw the performance impact.
Again, a switch (make it configurable) and the grid operator can decide.
For any grid that needs more advanced asset service with deduplication and access time updates they should consider FSAssets. The default asset service is not recommended for large grids.
Also, just because an asset hasn't been accessed for a long time does not mean it isn't used. It could be referenced in some inventory object that isn't fetched out often or in a script. Removing assets in this way will most likely result in broken inventory items. This is why the access time was never set in the default asset service, removing assets is just too risky.
"For any grid that needs more advanced asset service with deduplication and access time updates they should consider FSAssets. The default asset service is not recommended for large grids."
Sooo, why not updating access_time then, when the default is not for large grids?
Gavin Hird (reporter)
Because it is VERY costly.
For read accesses we try to make it as fast as possible - ideally serving as many records from cache as possible. If you are going to make a write to the database for every read (also from cache) you will see major performance impact.
When you start a region you do thousands of reads. The least thing you want is to slow it down with writes.
When you log on you may read thousands of records depending on how busy the scene is. Same on region crossings. You absolutely don't want a trip back to write a timestamp for every read.
Depending on your disk system, it may manage to do 90-350 writes per second (write the 4k block, read it back for verification, and maybe write an ack on verification.)
edited on: 2015-08-12 01:07
@Kubwa.. many reads are done only from an asset cache and for some grids that might have had all assets fetched at region startup using a startup command...
Should the database table be altered? Melanie's comments on that follow.
Not going to happen. There are grids out there that would have to shut down for days to run this alter table statement.
We cannot impose such a downtime on grids, therefore there will not be a Migration to remove it.
Also, the code to use it is there because it has been tried, but didn't lead to the desired results. Uncalled methods are not generated so the code itself takes neither space nor time, which is why no one bothered to remove it.
There is a general consensus, that took a long time to reach, that asset cleanup is not worth the risk of broken items. Disks are cheap.
"Uncalled methods are not generated so the code itself takes neither space nor time, which is why no one bothered to remove it."
But makes the source unreadable after a while.
Thats why i allways cry when trying to work on the source.
Well, feel free to close this case, i'll keep it in my own fork.
|this is old and appears will not be accepted|
|2015-08-11 13:00||Kubwa||New Issue|
|2015-08-11 13:00||Kubwa||File Added: AssetAccessTime.patch|
|2015-08-11 13:01||Kubwa||Status||new => patch included|
|2015-08-11 13:24||Gavin Hird||Note Added: 0029138|
|2015-08-11 13:26||Kubwa||Note Added: 0029139|
|2015-08-11 13:32||Gavin Hird||Note Added: 0029140|
|2015-08-11 13:42||AliciaRaven||Note Added: 0029141|
|2015-08-11 13:53||Kubwa||Note Added: 0029142|
|2015-08-11 14:04||Gavin Hird||Note Added: 0029143|
|2015-08-11 14:14||aiaustin||Note Added: 0029144|
|2015-08-11 14:36||aiaustin||Note Edited: 0029144||View Revisions|
|2015-08-11 15:04||melanie||Note Added: 0029147|
|2015-08-11 15:32||nebadon||Status||patch included => patch feedback|
|2015-08-11 15:33||nebadon||Assigned To||=> nebadon|
|2015-08-11 15:33||nebadon||Status||patch feedback => patch included|
|2015-08-12 01:06||aiaustin||Note Edited: 0029144||View Revisions|
|2015-08-12 01:07||aiaustin||Note Edited: 0029144||View Revisions|
|2015-08-12 06:27||Kubwa||Note Added: 0029150|
|2016-06-22 07:05||nebadon||Note Added: 0030660|
|2016-06-22 07:05||nebadon||Status||patch included => closed|
|2016-06-22 07:05||nebadon||Resolution||open => fixed|
|Copyright © 2000 - 2012 MantisBT Group|