Mispelled words taking too long to search

[edev]

Hi,

we recently upgraded our search license to 1 million, and I've discovered that any mis-spelled words such as "carbonn" or "stephenk" takes a long time for the spell check to come up, and most times this error message shows up:

Timeout
Your request exceeded the time limit. Please try again.
Texis & Webinator Copyright (c) 2006 THUNDERSTONE - EPI, Inc.

Is there any way to speed up the search and get rid of the above message? or to replace this message with something else? It's not in the search script and the "allow linear search" and "post process" are all turned off.

Thank you!

[mark]

Is there a long refresh crawl going on that profile? If so, try pausing it so the search indices get updated.

Is the system under heavy load causing everything to run slowly? (check Maintenance->tech support info).

What are your spell check limit settings?

[edev]

There is no crawl going on and I reindexed the profile just to be safe, it did not change the speed. There is nothing running on the server except for the search so I don't think it's due to heavy load. The spell check limit is set to 3.

What's interesting is that if I enter a word that's clearly not a valid word, such as "ksajkld", it returns the spelling suggestions right away:

Did you mean: kaskeld (1)
jsalkeld (1)
skjold (1)

But when I enter a clearly mispelled word like "stepheen" the search speed is very very slow and I often get this error message:

Timeout
Your request exceeded the time limit. Please try again.
Texis & Webinator Copyright (c) 2006 THUNDERSTONE - EPI, Inc.

The problem with the above message is that we have our own look and feel for search and this message messes up the whole table structure of our search result page. If nothing else can be done can I get rid of this message entirely?

I tried commenting out the <timeout> function but it did not work.

[mark]

Not sure about the timeout on stepheen but you can, rather than commenting the <timeout> function, place your own html into it.

In html comments on the resulting page and/or in the vortex.log you should see the scriptname and line number where the timeout occurred. It is always the same line? What's that line in your script?

[edev]

Hi Mark -

Yes the timeout is always on the same line, inside the
<a name=spellchecker export nhits> function:

<sql novars "select id " $sql></sql>

I'm using search script 5.0.2 and have modified the script alot to get our own look and feel so line number doesn't mean much to you.

This line is inside a block like this:
<buildlist phrases=$&phrases queryWords=$queryWords
curCount=0 totalCount=$ret phrase=""
w0=$w0 w1=$w1 w2=$w2 w3=$w3 w4=$w4>
<$okPhrases=>
<$indexc=>
<if $noSug eq 0>
<loop $phrases>
<if $phrases ne $query>
<!-- <sysinfo proctime $startTime> -->
<!-- <if $ret gt $SSc_suggestTime> -->
<!-- <break> -->
<!-- </if> -->
<$sq=$phrases>
<sql novars "select id " $sql></sql>
<if $loop gt 0>
<$okPhrases=$okPhrases $sq>
<$indexc=$indexc $indexcount>
</if>
</if>
</loop>

I will try to put in a <timeout> function in the script because my search script currently doesn't have one, so it must be getting the

Timeout
Your request exceeded the time limit. Please try again.
Texis & Webinator Copyright (c) 2006 THUNDERSTONE - EPI, Inc.

message from the Thunderstone server because there <timeout=-1></timeout> is set in dowalk.

I just want to users to see a normal message from us rather than the Thunderstone message.

[mark]

It appears to be timing out when counting how many each suggested term occurs in the database. Try changing it to

<sql novars max=1 "select id " $sql></sql>

[edev]

Hi Mark -

I made the change and it seems like it worked! we are no longer getting the timeout error message and the spell checks are alot faster to return.

Why are you only returning 1 result row when 3 spelling suggestions are returned?

[mark]

It has to do with the underlying function of sql. Regardless of how many results you extract with max= the "indexcount" is fully calculated by the time the first one is ready. The indexcount is all that's needed in most cases and is, in fact, all that's used in that bit of code. I expect a similar optimization will appear in the standard scripts in the near future.

[edev]

That's why! Thank you very much!