Quote from pgilpat on November 3, 2026, 14:58

Greetings,

I've been working on the severe slowness of this website for nearly two weeks now. The website is https://collectorstudio.com/

We have 2,538 products and have been using the filter for years. On approximately October 18, the site became excruciating slow to load all page, including the product filter pages. On or about that timeframe, I updated with the FOX plugin, or the HUSKY plugin - or both. I can't remember, I've been working through so many things. Prior to these updates, the site had been blazing fast. It keeps filling up the php-fpm -  pm.max_children

I have since purchased the premium version of the HUSKY plugin and have installed and licensed - HUSKY - Products Filter Professional for WooCommerce v.3.4.7

We were also using FOX currency switcher, and had been working with Alex on this thread on the FOX forum - https://pluginus.net/support/topic/website-overwhelmed-with-calls-to-currency-switcher-causing-outage/

I have since deactivated the FOX plugin in an effort to rule things out.

I continue to work with Plesk to determine the source of the slowness. In a recent conversation this morning with Plesk, they have provided the following insights in reviewing the current slow.log file (https://collectorstudio.com/slow-husky.zip).

Plesk mentioned:

When you contact WOOF support, send them the log and mention that the slow stacks are in woocommerce-products-filter → dynamic_count() (classes/counter.php).
Since the restart, the PHP worker pool has hit its limit only once (00:49 MST), and the server’s CPU and memory are normal.

root@ip-172-26-0-30:~# cat /var/log/plesk-php83-fpm/error.log | grep -i "server reached pm.max_children setting"
[03-Nov-2026 00:49:59] WARNING: [pool collectorstudio.com] server reached pm.max_children setting (28), consider raising it
root@ip-172-26-0-30:~# date
Tue Nov 3 03:09:08 MST 2026

A single shop page takes about 1.4 seconds to generate when the server is idle.

# curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" "https://collectorstudio.com/shop/?swoof=1&pa_item-type=posters&nc=$RANDOM"
200 1.436714s
That’s heavy for one request, and when search engines and bots request many different filter and sort combinations at once, the PHP workers fill up and visitors get 504s.
Cached pages (like the plain /shop/ page) are fast, which is why the problem comes and goes.

The slow log, however, keeps pointing to the WooCommerce Products Filter (WOOF) plugin.

root@ip-172-26-0-30:/var/www/vhosts/collectorstudio.com/httpdocs/wp-content# tail /var/www/vhosts/collectorstudio.com/logs/slow.log
[0x00007f6612e151a0] get_sql_clauses() /var/www/vhosts/collectorstudio.com/httpdocs/wp-includes/class-wp-tax-query.php:251
[0x00007f6612e15120] get_sql() /var/www/vhosts/collectorstudio.com/httpdocs/wp-includes/class-wp-query.php:2304
[0x00007f6612e14840] get_posts() /var/www/vhosts/collectorstudio.com/httpdocs/wp-includes/class-wp-query.php:3974
[0x00007f6612e147d0] query() /var/www/vhosts/collectorstudio.com/httpdocs/wp-includes/class-wp-query.php:4105
[0x00007f6612e14760] __construct() /var/www/vhosts/collectorstudio.com/httpdocs/wp-content/plugins/woocommerce-products-filter/classes/counter.php:120
[0x00007f6612e14700] __construct() /var/www/vhosts/collectorstudio.com/httpdocs/wp-content/plugins/woocommerce-products-filter/classes/counter.php:59
[0x00007f6612e14620] __construct() /var/www/vhosts/collectorstudio.com/httpdocs/wp-content/plugins/woocommerce-products-filter/index.php:2008
[0x00007f6612e14380] dynamic_count() /var/www/vhosts/collectorstudio.com/httpdocs/wp-content/plugins/woocommerce-products-filter/views/html_types/select.php:159
[0x00007f6612e14190] [INCLUDE_OR_EVAL]() /var/www/vhosts/collectorstudio.com/httpdocs/wp-content/plugins/woocommerce-products-filter/index.php:3709
[0x00007f6612e14110] render_html_e() /var/www/vhosts/collectorstudio.com/httpdocs/wp-content/plugins/woocommerce-products-filter/views/woof.php:231

It runs a heavy product query for every filter option on each page load, and those requests are what fill the workers.

Your other plugin and bot tests didn’t show a cause, so I suggest:
1. In WOOF settings, turn off the dynamic recount / “show count” options, or set them to cache. Also try limiting the number of filters shown at once.
2. Then, if the load stays high, contact the WOOF (HUSKY) developers with the slow log above. Enfold support can help with the sorting and filter templates.
3. Ask your developer to update robots.txt (via Yoast SEO) to disallow the filter, sort and AJAX URLs (swoof=, product_order=, orderby=, pa_*, wc-ajax=). This stops well-behaved crawlers from requesting every filter combination, which is the main source of load. Bots that ignore robots.txt are handled by the Fail2Ban rules that were added previously.

---

I have turned the "dynamic recount" setting.

Alex, I am really stumped here an overwhelmed trying to solve.

GT Metrix snaps:

http://collectorstudio.com/GTMetrix11-3-26-2-20AM.pdf

http://collectorstudio.com/GTMetrix11-3-26-2-20AM-performance.pdf

Thank you again for your help.