Skip to content

Shared LRU cache across connections#82

Merged
bplatz merged 4 commits intomainfrom
feature/shared-lru-cache
Aug 1, 2024
Merged

Shared LRU cache across connections#82
bplatz merged 4 commits intomainfrom
feature/shared-lru-cache

Conversation

@bplatz
Copy link
Contributor

@bplatz bplatz commented Jul 29, 2024

This moves the connection setting of cacheMaxMb to a server-level setting.

All connections leveraged on the same server should share the same LRU cache.

While technically there is more granular control available, it would in most circumstances under-utilize the machine resources - or if oversized to accommodate that, then leave the server susceptible to OOM failures.

We always have fluree/db, and people can write their own custom thin layer to do anything unique they want.

It utilizes the server-level config options in #80

@bplatz bplatz requested a review from a team July 29, 2024 19:28
Copy link
Contributor

@zonotope zonotope left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good and the rationale makes sense.

One little nitpick is that I think I would rather have individual components for these "server level" configurations instead of one catch-all. That way you could tell from the dependency graph which components depend on what at a more fine-grained level.

The user level JSON config is fine to have a catch all, but I think it would be nice to have a separate :fluree/cache component with an initialization method that created the cache from the cach-max-mb argument directly, and all dependent components can (ig/ref :fluree/cache) directly.

In any case, this works so I'm fine with it, but I would rather things that need initialization live in their own integrant components, even if they are grouped under a single key in the user-level json config.

@bplatz
Copy link
Contributor Author

bplatz commented Jul 30, 2024

In any case, this works so I'm fine with it, but I would rather things that need initialization live in their own integrant components, even if they are grouped under a single key in the user-level json config.

@zonotope I believe this addresses your comment: fcf570c

@zonotope
Copy link
Contributor

In any case, this works so I'm fine with it, but I would rather things that need initialization live in their own integrant components, even if they are grouped under a single key in the user-level json config.

@zonotope I believe this addresses your comment: fcf570c

Looks good to me.

Base automatically changed from fix/multi-server-raft to main August 1, 2024 20:36
@bplatz bplatz merged commit 64d827f into main Aug 1, 2024
@bplatz bplatz deleted the feature/shared-lru-cache branch August 1, 2024 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants