We recently started experiencing frequent spikes in CPU usage on one of our production servers running the popular WordPress eCommerce platform, WooCommerce.
When our team started investigating the problem they noticed the website in question which had recently hit 4,500+ products, had some 250,000+ entries within its wp_postmeta table.
Anyone who’s had experience dealing with large amounts of data within WordPress will know eventually performance can be effected by the time it takes MySQL to query that wp_postmeta table. Now in some cases page caching can be an option and a great solution to this problem. But as with most eCommerce websites, features like product filters that can lead to literally millions of possible page combinations can cause problems.
Our website was making extensive use of the recently renamed WooCommerce widget “Filter Products by Attribute” and we found in extreme cases the widgets were taking 15-20 seconds to return results and not to mention the 60% CPU load it was bearing on our server per request.
We found that the product counts and their respective database queries per widget were the cause of these CPU spikes.
We theorised a temporary solution to create a version of the “Filter Products by Attribute” widget and remove the various calls to the product count functions, this alleviated the performance issues and confirmed the problem. But as you begin selecting various attributes the widget depends on some sort of count to function, which turned this solution on its head.
We made the final decision to drastically reduce the multiple iterations of the “Filter Products by Attribute” widget that where in use, and for the time being website performance has been resolved.
Whilst we’ve heard rumours of upcoming changes to the WooCommerce data architecture, which would see product attributes being moved from the wp_postmeta table into custom tables. This is no small task and we’re not expecting to see a public (wordpress.org) release for 6+ months.
Share this page