You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the initial implementation of the server (#19), a choice was made to delay this work.
The problems this setting is aiming to solve:
Working within limits of the number of open files
Sled will be keeping an in-memory cache for each open database. We may want to expose this cache size for configuration, but regardless: each open database will eat memory for cache.
The logic implemented should keep track of the last time a database was accessed, and when a database needs to be unloaded, the oldest database should be evicted first.
One question that needs to be answered is, under high load, if a server is configured to only have, let's say 20 databases open, should we allow temporary bursting if a queue of requests comes in that exceeds that? Or should requests block until the limit is exceeded? Maybe two settings -- a target and a maximum?
The text was updated successfully, but these errors were encountered:
This is no longer relevant after #49 is merged. By using one sled instance, the only configuration needed is to expose whatever options we want to allow from sled's configuration.
With the initial implementation of the server (#19), a choice was made to delay this work.
The problems this setting is aiming to solve:
The logic implemented should keep track of the last time a database was accessed, and when a database needs to be unloaded, the oldest database should be evicted first.
One question that needs to be answered is, under high load, if a server is configured to only have, let's say 20 databases open, should we allow temporary bursting if a queue of requests comes in that exceeds that? Or should requests block until the limit is exceeded? Maybe two settings -- a target and a maximum?
The text was updated successfully, but these errors were encountered: