-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjust size of in-memory block cache #47
Comments
I've restarted
I will check Friday EOD if cache hit ratio improved, or latency/error rate decreased in any significant way. |
after ~12h:
hits still at ~51%, which confirms that we could increase it further to save on more roundtrips. I am setting it to 4096 now:
|
in 6h 4096 produced "only" 40% hit ratio
|
After weekend, the
|
Cache hit % is pretty successful across instances, including staging where we deployed #61 with Graph API enabled: I am going to double the cache size on staging to Done:
|
bifrost-gateway runs with in-memory 2Q cache with size set to 1024 blocks.
Current cache performance: ~50% cache HIT
Cache metrics from
bifrost-stage1-ny
after one day (~48%):And second sample from other day (~50%):
iiuc the above means that in-memory "frecency" cache of 1024 blocks produces cache HIT ~50% of time.
This is not that surprising, every website will cause the same parent blocks to be read multiple times for every subresource on a page.
We run on machines that have 64GiB of memory and
bifrost-gateway
only utilizes ~5GiB.Proposal: increase cache size
Improving cache hit here won't improve things like video seeking or fetching big files, but will have impact for how fast popular websites and directory enumerations load, avoiding trashing of the most popular content.
Tasks
bifrost-stage1-ny
and increase block cache size, let's say initiallly x5 (to 5120 blocks) and see if it improves cache hit, or if it produces diminishing returns.The text was updated successfully, but these errors were encountered: