Low Search index error: 500 internal server error
I'm installing Low Search v4.4.5 for the first time on EE 2.10.1. I created a collection for our blog channel. When I click on the "index" link under Build Options it starts processing and eventually indicates there was an error.
Viewing the details it says there was a 500 internal server error. The error details are too long to include here since it looks like it's including the actual content. but it starts/ends with:
Error Number: 2006
MySQL server has gone away
REPLACE INTO exp_low_search_indexes (collection_id, entry_id, site_id, index_text, index_date) VALUES ('1','884','1','| supercharing ioc matching in the new threatstream app for splunk | supercharing ioc
....
ing |','1558630227')
Filename: third_party/low_search/models/low_search_index_model.php
Line Number: 137
Replies
Low 23 May 2019 17:56
Hmm, not necessarily a LS issue, but try this: for the collection, set all weights to 1 (or 0). Only fields that contain a couple of words (like title) could be set to 2. Then save the collection and try again.
If the problem persists, try these pointers: https://matomo.org/faq/troubleshootin...
James 23 May 2019 21:19
Ok, so adjusting collection weights definitely seems to help. After a couple tests, it seems the problem child is the field that has the actual body contents of the blog. Some of the posts can be quite lengthy. In fact I was able to set all of the fields and categories to 3 as long as I kept the field with the body content at 1 or lower.
How important to the proper functioning of Low Search are the weight values?
Low 25 May 2019 07:05
My advice would be that any search field you want to include in the search index, set its weight to 1. That would be sufficient in most cases.
If the field is somehow more important than others, and only contains a few (key)words, you could set it to 2.
I'd reserve setting the weight to 3 for fields solely meant to contain very specific search terms for the entry, like a dedicated keywords field.
Set to 0 if you don't want add the field to the searchable content.
The reason behind this is due to the way MySQL implemented their full-text search algorithms; a but technical and obfuscated, but the main takeaway is to leave the weight to 1 unless you have a good reason not to.