Search function no longer returning results

[rgatliff]

I am running Zoom ver 5.1 for the past 18 months without any problems until this week. This week I updated my search db using a local copy of my website and uploaded the updated zoom folder to my website. Now when I run my search.php script, it returns with zero results for keywords that I know exist on my webpages. If I run the search scripts located in the backup copy of my previous build, it works as expected returning lots of entries.

When I run the zoom search scripts on my local pc using php5.3, they work correctly and return the expected entries. So from this I am asumming that the DB files generated by the indexer are good since the same db files work on my pc.

I have been using the same procedures everyother month for the past year. I build the indexer database using my local website backup on my PC. Then I upload the Zoom folder containing the zoom scripts and db to my host website using FileZilla. The db files are uploaded using the binary transfer mode. The host website is runing php5.2.3 on a Linux server.

I turned on logging in the host scripts but none of the searches are being logged. It is as if the search scripts are not seeing the updated db's. There are no error messages being returned either to the zoom result screens or to by website error log files.

To see what I am being returned, go to website www.yellcountyobits.org/zoom/search.html and enter Cathey in the search field.

Any and all help will be appreciated.
Robert

[David]

I think you might have the server side configuration problem descibed here, I think the server is killing the script before execution can finish.

Also can you tell me which hosting company you are using? We like to keep a list of the bad ones.

[rgatliff]

running into limitation issue

After reading the posting on Apache configuration limits, I did some testing and found that I could get the search function to work by reducing the size of my indexer db's. I did this by not indexing some pages of my website. After trying different combinations, I found that I had to get the zoom_dictionary.zdat file to 1024kb or smaller for it to work.

What information is maintained in this file?

Is there a way to reduce the size of this file without having to not-index my entire website? I have already gone thru and made sure I was not indexing unnecessary pages as well as added a long list of common words found on my webpages.

[Ray]

The problem (as described in the the link above) is that your hosting company has placed heavy restrictions on your server, such that scripts cannot use more than a specified amount of RAM. OR, it might be that there's a time limit on how long a script can execute.

There's no point in trying to reduce the size of a single particular ZDAT file. What you are noticing is simply the result of there being less data to search through (which results in a smaller dictionary file). The data across all the ZDAT files correlate to each other. When there's a smaller index, the script will use less RAM, and take less time to execute.

In other words, making the index files smaller won't help you here. It's the reduction in data that's getting you under the restrictions of your server. You either reduce the data indexed (which results in smaller index files) to get by under your server's limits. Or you index all the data you need (and create larger index files and require more memory/cpu to search them). You can't have it both ways.

A 1024 kb (1 MB) dictionary file is not a big index at all. Your server must be heavily restricted.

The proper solution to this problem is to contact your web hosting company and ask them to raise or remove this restriction, especially if this restriction was not mentioned in the conditions of the hosting plan that you agreed to. Bad hosting companies like to use these hidden limits to squeeze as many customers as they can on the same server, and hope the customers don't notice they're providing subpar performance. On the other hand, you usually get what you pay for, and it's often the compromise of a cheap hosting plan.