-
After installing FV Player Pro with Vimeo Pro (also using VAST plugin) yesterday, my website has really slowed down.
I normally monitor my mysql.slow log for bottlenecks, after installing the FV player it started to flood with these entries:
SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’;
Some queries taking up to 20 seconds, during heavy site traffic.From what have read, wordpress runs this query every time someone visits a page, and it loads all that data into memory? It looks like FV Player takes and stores all the vimeo rest api results for each video in the wp_options table with autoload set to yes. The option_value also looks rather large since it holds a lot of information from that endpoint. I tried adding an index on that table to speed things up:
create index i1 on wp_options(autoload, option_name, option_value(50))It helped some, but when the cached vimeo entries in that table starts to get up to 500 (have over 1000 videos on the site), and the server starts to get moderate traffic, the site starts to crawl again. If I manually delete those out of the wp_options table, things speed back up again.
Any ideas?
Maybe store that vimeo api data in text files in /wp-content/uploads/flplayer/vimeo/vimeo_id
Or not having it set to autoload if stored in wp_options?Any help or suggestions would be appreciated, it’s a great plugin other then this first initial issue I’m having.
Thanks
-
-
Hello Cameo,
thank you for reporting this. We are usually very sensitive about issues like this. The plugin used WP Transients for a long time, until we changed it to using WP Options recently and haven’t realized the issue with autoload being on will occur.
You are right about storing the data elsewhere – we like the idea of using flat files but we might use a new database table as well.
As a quick pre-Christmas fix I altered the code to not store the options with autoload on. Please upgrade FV Player Pro to the most recent version (0.6.12) to get the fix. It will change the autoload to “no” for each video the next time the cache gets updated, so you can delete the cached entries manually for the last time and the issue won’t repeat.
Thanks,
Martinthanks for that quick fix I installed the update, and will keep an eye on things, but I think that will help to not slow that core query down now….much appreciated. Merry Christmas!
