Is your feature request related to a problem? Please describe.
We're seeing an excessive amount of records in GeneralLog, which also result in GlobalSetting updates. This is adding additional overhead on the resources to write to disk and database, which we sometimes don't find value.
The most obvious example for us is Application/Settings, which gets a DB log record and does a GlobalSettings update for every time a Data Integration Provider is used.
Another excessive log action we see is related to scheduled tasks. Because there are so many of them at a granular level, it can become noisy
Describe the solution you'd like
The ability to disable which LogAction to log (maybe don't provide a list of the absolute action a user should never disable)
Find an alternative way NOT to write statistical data to GlobalSettings
Describe alternatives you've considered
Lower the retention days for GeneralLog
Create a GlobalSettings.ProviderUser.config file
Additional context
We're simply looking into some obvious situations where increasing I/O operations are happening, whether that's on the DB or the File System. When applied to real-life scenarios and/or load, they can become quite costly to workaround, whether because of the time invested in finding the issue/right solution or from the cost of the resources that need to be considered to overcome the bottleneck.
This was discussed with Jeppe in person, at the Summit.
Is your feature request related to a problem? Please describe. We're seeing an excessive amount of records in GeneralLog, which also result in GlobalSetting updates. This is adding additional overhead on the resources to write to disk and database, which we sometimes don't find value. The most obvious example for us is Application/Settings, which gets a DB log record and does a GlobalSettings update for every time a Data Integration Provider is used.
Another excessive log action we see is related to scheduled tasks. Because there are so many of them at a granular level, it can become noisy
Describe the solution you'd like
Describe alternatives you've considered
Additional context We're simply looking into some obvious situations where increasing I/O operations are happening, whether that's on the DB or the File System. When applied to real-life scenarios and/or load, they can become quite costly to workaround, whether because of the time invested in finding the issue/right solution or from the cost of the resources that need to be considered to overcome the bottleneck.
This was discussed with Jeppe in person, at the Summit.