[ic] Using indexes in search

[interchange-users@icdevgroup.org (Joshua Lavin)]

on 10/31/02 4:16 PM, Jeff Dafoe at jeff@badtz-maru.com wrote:

>> I added the st=text, and that really didn't make a difference. However, I
>> failed to mention that in the one-click search link, there is also
> "ml=999".
>> If I take out the ml=999, the search is faster.
> 
> Make the rf=* and item-param change described in that thread also.  Like
> I mentioned, I had a .45 load with only 3-5 users on browsing through
> results pages.  After switching to text and using rf and item-param,
> essentially eliminating the SQL server from the search results page process,
> the load is now non-measurable in that situation.  I feel that you really
> have to eliminate the SQL server from the search results process as the open
> source SQL servers are not as fast as one would hope when returning large
> amounts of rows.  By making the st=text change you have eliminated the db
> from the search process but if you still have item-description and
> item-thumb on your results page you are still hitting the SQL db a zillion
> times, since each of those tags does its own lookup.  The rf and item-param
> changes will rectify this.  I would all but guarantee you will see a
> substantial difference.

I did some major testing this morning, writing down all the results. Here's
the outcome:

The original search took 13 secs to appear (this is the time when the
browser says "contacting server"). The benchmark was 0.023.
[page scan 
se=Pants/sf=Category/va=dept=clothing/sp=testsearch/ml=999/mp=sort]

After adding st=text, it took 16 secs/benchmark=0.023, second try: 12
secs/0.023. Pretty much the same.

Then I used the item-param results page and rf=*:
[page scan 
se=Pants/sf=Category/va=dept=clothing/sp=testsearch-param/rf=*/ml=999/st=tex
t/mp=sort]

81 secs/0.016. Second try was 18 secs/0.023. Maybe the server was busy the
first time.

However! I noticed on the param results page there was a [sort] tag leftover
(this page was a old results copy I modified).  The sort tag was _not_ on
the original results page. I took this out, since I am using the search
profile "sort" (seen above). Now my times were: 5 secs/0.023.

It seems that the clincher was taking out the [sort] tag and using
item-param. Thanks for all the help, Jeff!

Josh