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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce fs_accounts
option size, possible?
#400
Comments
I feel like some fs_accounts data is transient-worthy, while some makes sense to stay in the option itself. That might help solve this as transients can be offloaded more easily off to object caching solutions like Redis. |
@lkraav our initial thesis was "speed over size", i.e., it's "cheaper" to load a single record vs. multiple, as the intuition was that we need the data we store and the natural split will be based on plugins (a record per plugin). As the SDK progressed and we added many advanced features, we are now naturally storing significantly more details, and most likely, not everything is needed to be auto loaded. So thanks for bringing that up 馃憤 we'll prioritize an audit of the SDK and rethink our storage layer design. @sc0ttkclark and definitely, good chance some can be offloaded to transients too. |
any update on this? |
Any update or progress on this? I have two necessary plugins on my website now switching to Freemius but I'm hesitant to update because of this issue. It looks like no activity on this for quite some time. |
Hey @bsahins @small-fork 馃憢 Thanks for checking in. We already made some healthy progress with the storage layer optimization in Dec 2022 (you can check the improvements here) and plan to continue the work in April/May. |
@vovafeldman Thank you so much for the update. I really appreciate it! |
@vovafeldman Hi there! My fs_accounts is 75526 bytes big. Any way I can reduce it somehow? |
@vovafeldman Any progress on this? My fs_accounts is now 69346 bytes large. When I look into it there are a lot of information about old plugins I no longer use. Is there a way to safely remove that data? |
Testing on staging site - removing fs_account from database clears data inside it from unused plugins, and the fs_accounts appears again with fresh data, much smaller in size. I am still unsure is it safe to proceed with this on a live site? |
@ben72, thanks for mentioning the @fazhek, just removing |
@vovafeldman That seems reasonable. When can we expect to see the garbage collector? If you need to see an old fs_account with probably lots of garbage you can have mine. |
I'm liking the garbage collector idea; my fs_account is ALSO hugetastic & I'd really rather be able to make it a LOT smaller. Thanks! |
The size of fs_accounts autoload has been horrible for years... and unless I'm grossly misunderstanding something, loading ANY of the Freemius plugins NOT associated with our installed plugin, makes absolutely zero sense. Like many others on this thread, the fs_accounts options table is second largest. |
I know it's been a while, but we are almost there! The GC (Garbage Collector) is ready and past regression testing. Due to the significance of the change, before we release it to the public, we first production test it on one of our plugins. If you want to try it, here's the relevant branch: feature/garbage-collector-configurables Make sure to set the Once you have those set, the GC will clean uninstalled plugins data after the time you defined by |
Update: we have released v2.6.0 with the Garbage collector. Please check the release note to find out more information: https://github.com/Freemius/wordpress-sdk/releases/tag/2.6.0 Thank you. |
馃殌 feature request
Description
Option table optimization dictates to look at autoload payload first.
fs_accounts
is easily one of the heaviest options recorded. Only WC Memberships has a heavier payload, but it has the excuse of being the backbone of the business.Describe the solution you'd like
Please find a way to reduce autoload option payload. Significantly. 10x less kB would be a nice goal.
Describe alternatives you've considered
Yes, I will just disable Freemius wherever possible. I don't want to and neither do plugin vendors.
Your thoughts?
The text was updated successfully, but these errors were encountered: