Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
2.5.1
-
Security Level: Public
-
None
-
June 30 - July 18
Description
It looks as though the compaction daemon runs immediately when the first database is opened, so if that database needs compaction it will start right away. This could cause performance problems in a mobile or desktop app, which needs to load and display data and become responsive as quickly as possible. If the compactor is running during launch it will consume I/O and CPU bandwidth and slow down the queries that the app is making.
On the other hand, if the sleep() call is simply moved to the top of the loop, there's the possibility that if the app isn't running for long (quite likely for a mobile app) its database might never get compacted. Especially because in Couchbase Lite I'm setting the compaction rate to a lower value like a minute.
A decent compromise might be to have the compactor thread sleep for a little while, maybe 15 seconds, before starting its loop. That should give an app enough time to start up first.
A more flexible solution would be to add API that lets the application control when the compaction daemon runs. Maybe "fdb_run_compaction_daemon()". Then the app can set the sleep duration to infinity and call this function whenever it's appropriate.