Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007676opensim[GRID] Asset Servicepublic2015-08-11 13:002016-06-22 07:05
Assigned Tonebadon 
PlatformComputerOSWindowsOS Version7
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007676: Setting accesstime for assets in mysql database
DescriptionField 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 ReproduceClear your regions asset cache and restart it.
Watch then at the access_time column in your asset database table.
TagsNo tags attached.
Git Revision or version number
Run ModeStandalone (1 Region)
Physics EngineBulletSim
Environment.NET / Windows64
Mono VersionNone
Attached Filespatch file icon AssetAccessTime.patch [^] (961 bytes) 2015-08-11 13:00 [Show Content]

- Relationships

-  Notes
Gavin Hird (reporter)
2015-08-11 13:24

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.
Kubwa (reporter)
2015-08-11 13:26

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)
2015-08-11 13:32

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.
AliciaRaven (manager)
2015-08-11 13:42

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.
Kubwa (reporter)
2015-08-11 13:53

"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)
2015-08-11 14:04

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.)
aiaustin (developer)
2015-08-11 14:14
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...

fcache assets

Should the database table be altered? Melanie's comments on that follow.

melanie (administrator)
2015-08-11 15:04

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.
Kubwa (reporter)
2015-08-12 06:27

"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.
nebadon (administrator)
2016-06-22 07:05

this is old and appears will not be accepted

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker