-
-
Notifications
You must be signed in to change notification settings - Fork 322
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
Feature: Imporve Cache Collector #471
Comments
Hey, thanks for the suggestions!
If you'd still like to work on a PR, I'd accept one for the first part for now. Otherwise I'll look into adding this for the next minor release. |
This is now merged and will be released as part of Clockwork 5.1, I ended up flipping the config option logic ( |
@itsgoingd what do you think about collecting the cache value sizes? It's very important for high-loaded projects. |
Oops, forgot about that part. I think it definitively makes sense, adding it as a separate feature-request to the 5.1 todo-list. |
Interface part will be difficult for me. As I know, UI is already built and I don't know how to change UI components. |
The UI is a separate Vue SPA, which can be found here - https://github.com/underground-works/clockwork-app If you'd like to work on this feel free to join our Discord, I can offer some real-time guidance there. But if you'd rather not get into that, I can also do this myself, just let me know. :) Btw. do you have any ideas on how you would handle non-string cache values? |
@itsgoingd I'll do the backend stuff, VueJS part I leave for you :) |
We ran a high-loaded project and it is very important to monitor how the application utilizes cache.
I'd suggest to collecting the size of the cache values, something like
Str::length(serialize($query['value']))
. It can be configurable feature.Also, I'd suggest adding the option for hiding cache values itself but show key names (disabling the
collect_queries
option disables listing of cache keys as well).In our server infrastructure bandwidth between the app and Redis servers is the bottleneck, so monitoring cache value sizes during development is very important.
If maintainers are ok with this, I can send PR.
The text was updated successfully, but these errors were encountered: