The plugin slows down the site by littering the wp_options table
-
For synchronization jobs, the plugin uses the wp_options table. As a result, after a while I got more than 75,000 entries of the form wc_facebook_background_product_sync_job_* in the wp_options table. It’s not normal, is it? It is wrong to store something in wp_options besides site settings, plugins and template.
It also slows down the product list page in the admin area, because a separate SQL query for get synchronization status is executed for each product (each row).
I suggest storing synchronization jobs in a separate table in which can configure the appropriate indexing and cleaning by creation time or status.
-
There are not so many of them with failed.
{"requests":{"\u0432\u0438\u043d\u043d\u044b\u0439\u041c1\u043a\u043e\u043c\u0444\u043e\u0440\u0442\u041a\u0440\u0443\u04226_10455":"DELETE","p-10455":"UPDATE"},"id":"863abc633168a273085314521000c335","created_at":"2021-05-04 14:05:03","created_by":0,"status":"failed","started_processing_at":"2021-05-04 14:05:44","updated_at":"2021-05-04 14:05:45","total":2,"progress":2,"handles":["AcxJMYkTfvHDueZ9tCI-q9rGSKXsnrUQqpE0ZxZT6e9My8aIvMevtx2dz9M_xxqbir48q8-aYjk-qs5kF1auKfCeUBaqA95awS4MbABbHlTNEQ"],"completed_at":"2021-05-04 14:05:45","failed_at":"2021-05-04 14:05:47","failure_reason":"Uncaught Exception: Job data key \"requests\" not set in \/var\/www\/domain.com\/htdocs\/wp-content\/plugins\/facebook-for-woocommerce\/includes\/Products\/Sync\/Background.php:65\nStack trace:\n#0 \/var\/www\/domain.com\/htdocs\/wp-content\/plugins\/facebook-for-woocommerce\/vendor\/skyverge\/wc-plugin-framework\/woocommerce\/utilities\/class-sv-wp-background-job-handler.php(588): SkyVerge\\WooCommerce\\Facebook\\Products\\Sync\\Background->process_job()\n#1 \/var\/www\/domain.com\/htdocs\/wp-content\/plugins\/facebook-for-woocommerce\/vendor\/skyverge\/wc-plugin-framework\/woocommerce\/utilities\/class-sv-wp-background-job-handler.php(168): SkyVerge\\WooCommerce\\PluginFramework\\v5_10_0\\SV_WP_Background_Job_Handler->handle()\n#2 \/var\/www\/domain.com\/htdocs\/wp-includes\/class-wp-hook.php(292): SkyVerge\\WooCommerce\\PluginFramework\\v5_10_0\\SV_WP_Background_Job_Handler->maybe_handle()\n#3 \/var\/www\/domain.com\/htdocs\/wp-includes\/class-wp-hook.php(316): WP_Hook->apply_filters()\n#4 \/var\/www\/domain.com\/htdocs\/wp-includes\/plugin.php(484): WP_Hook->do_action()\n#5 \/var\/w"}
Most tasks with the status “completed”. For example:
{"requests":{"\u043a\u043e\u0440\u0433\u0438\u041c1+\u04221_18660":"DELETE","p-18660":"UPDATE","p-17072":"UPDATE"},"id":"bbbf6746b5eeae8e95a7c0b8035a2e19","created_at":"2021-09-26 15:54:24","created_by":0,"status":"completed","started_processing_at":"2021-09-26 16:06:36","updated_at":"2021-09-26 16:06:47","total":3,"progress":3,"handles":["AcxFcCvticu_mOsu1kXhUOu5Ch5LnJI2d2KEn3bqbv4DD4M3my0r14nm-s-OY4BcYh7-5adTl1H9F9n-8SkKFn8Q"],"completed_at":"2021-09-26 16:06:47"}
The plugin is always the latest version, WordPress and WC too.Just in case, I will clarify why I wrote that storing a job in wp_options is an undesirable solution. This can be useful if someone decides to repeat the same thing that this plugin does. When data is stored this way, site cannot make a simple and fastest request to MySQL like
DELETE FROM "wp_options" WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 DAY) AND status = "completed"
Instead, the plugin does an unpredictably resource-intensive operation.
First, the plugin needs to request all entries with wc_facebook_background_product_sync_job_*. It can be a long time if something goes wrong and the records stop being cleared, or there are a lot of products in the store.
Then the plugin needs to parse the data in JSON format inside them in order to get the status of the task and perform manipulations with it (sort, delete or change). There may not be enough time for this as part of the background execution of tasks if the site uses the standard cron WP. And even if such site background jobs are run through the wp-cli, there may not be enough server RAM to perform these tasks. Or it just prevents the site from being responsive when background tasks are running.
The above problem (not from the previous post, but about potential interrupting jobs) is observed by me on many sites that have more than ~100 products. Each of them can have hundreds of variations, so the total number of jobs required for processing can be even 10,000 or more. I dream that someday the plugin will work more efficiently. Thanks for your work anyway, devs.I also have same problem, with about 1600 rows, but problem is that some have option_value size of like 400 000 characters, for example :
{“requests”:{“p-143606″:”UPDATE”,”p-143597″:”UPDATE”,”p-143435
and so on for 400 000 characters long.Some other database rows are more “normal” size. EDIT: I also have pretty many products and variations, about 7000 products, with a lot more variations.
- The topic ‘The plugin slows down the site by littering the wp_options table’ is closed to new replies.
