All Low add-ons are now owned by EEHarbor. Read the blog post.

Support archive

LOW Search results page timeouts memory exhausted...

Paul Cripps 28 Feb 2019 17:58 question, complete

Hello,

We have a site with the following setup:

EE: 2.8.1
LS: 4.3.1
PHP 5.6.40

We've updated the local and dev site to LOW Search 4.4.5 and I get the same errors described below.

The site has roughly 13K articles / items in the collections.

When we search for multiple keywords that contain 'stop words', for example "Superbowl for IT" works, where as "Broadcast for IT" does not, the results template timeouts, as such we can not see any debug info.

Running the test locally I get the same, and I can see the following apache errors:

[Thu Feb 28 17:03:00 2019] [error] [client ::1] FastCGI: comm with server "/Applications/MAMP/fcgi-bin/php5.5.26.fcgi" aborted: idle timeout (30 sec), referer: http://example.localhost/

[Thu Feb 28 17:03:00 2019] [error] [client ::1] FastCGI: incomplete headers (0 bytes) received from server "/Applications/MAMP/fcgi-bin/php5.5.26.fcgi", referer: http://example.localhost/

I've upped the error logging but could not see anything obvious:

$config['log_threshold'] = 4;

Checking the server logs, we saw this:

[28-Feb-2019 17:36:18 Europe/London] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 13227 bytes) in /home/example/system/third_party/low_search/filters/keywords/lsf.keywords.php on line 0

So we increased the PHP memory limit to 256, now 512 and the page now works however it takes up to 30 seconds to load.

Any thoughts on further improvements to help speed this up?

Replies

  1. Low 28 Feb 2019 20:02

    It's a bit hard to debug this, especially since you're running a legacy version of LS on a retired EE product, but sure, here goes.

    The memory allocation could be due to the scoring mechanism of the fallback (non-fulltext) search. The most robust way to tackle that would be to tweak your MySQL configuration to include words of 2 chars and more, to customize stop words, all to make sure the fulltext search is triggered more than the fallback.

    For each collection, make sure the weighting is optimal: fields that contain large amounts of text should have a weight of 1; only fields that contain limited words (like titles) could be weighted 2. Avoid weights of 3. Then rebuild. This is to minimize risk of creating 'common' words in the MySQL fulltext index, that would be ignored. Also, it will help the scoring method that the fallback search method uses.

    You can also try and install Low Search Native, which basically pre-filters search results on native filters (channel, status, expiration date etc) before hitting the Keywords filter. In some cases, this will improve performance quite a bit, but be aware, sometimes it can have an opposite effect, so YMMV.

  2. Paul Cripps 1 Mar 2019 10:23

    Thank LOW, really appreciate your thoughts as these are legacy products.

    I'll run some tests and comparisons locally and on our dev setup and report bac findings.

    We hope to upgrade the site this year, plus jump to PHP7, which hopefully make further improvements.