Thread

Before upgrading this client’s site, I upgrade a test installation of the site to make sure everything is okay. I have run into a problem with site search—it’s taking really long for the search results to be returned and that’s the main functionality for this particular section of this web site. Am looking for suggestions as to how to resolve.

I should note two things:
1) I am returning custom fields in the results and not using the {excerpt} tag
2) I updated to build 20070626 before posting this and the problem persists

For purposes of comparison, I searched for the word open with template debugging turned on and have included below the two lines from the debugging where the disparity between the test installation vs. the current site is most pronounced (and yeah, I’m clueless as to what it means so it may be totally useless!):

TEST INSTALLATION:

Elapsed Time: 15.1118
Total Queries: 33

(0.059359) -> Method Called: search_results
(13.647355) -> Data Returned

CURRENT SITE:

Elapsed Time: 2.1350
Total Queries: 30

(0.072668) -> Method Called: search_results
(-0.187190) -> Data Returned

The live site is running Version 1.5.2 Build 20061128
The test installation site is running Version 1.6 Build 20070626

Has something changed in the way the searches are performed? Indexing or something? Is there something I can do to “undo” the slowdown?

Can you do this for a quick check- if you switch to excerpt instead, does it matter?

It works fine with excerpt. (Here I was, trying to be all thorough and everything and forgot to mention that I have two searches on the site—one uses excerpt and the other uses custom fields—the excerpt one functions just dandy.)

OK- when you don’t use excerpt- does the content have a lot of markup- tables and such?  This is reminding me a bit of an issue on someone’s wiki- had to do with parsing.  I’m going to go hunt for the link and probably give Derek a yell.

Ah- here’s the wiki discussion- may/may not be related.  Derek had him upgrade to the very latest- then we’ll look for issues.  But you’re on the very latest.

Huh- like I say, may be a different issue, but I’m going to give Derek a ‘heads up’ anyway.

Yeah, I saw that and it had a hint of familiarity…that’s why I waited until the 6/26 update but alas, problem persists. I’m attaching an image of the search results so you can see how much data is involved…and yup, they are returned in a table. *rats…image is too wide…hold on…

PHP version is a potential factor here too so please post that also. 😊
-C

PHP is PHP Version 4.3.8
MySQL is 3.23.58
PCRE Library Version is 4.5 01-December-2003
(I don’t know why I threw that in there but I saw it mentioned elsewhere) 😊

Carolyn’s issue on the Wiki involves XSS sanitization, which is not performed on weblog entry custom fields (unless safe HTML only is allowed), so this would not seem to be related.  Also, in that case the articles contained tables, not fields being output as tables—but is still irrelevant, it had to do with having a very high number of links in the article.

The search results tag uses the weblog module to parse these things—are your weblog entries tags on the local site also slow?  And do you have any extensions installed?  And does your local install have identical data to your live site?  Can you also try doing an Optimize and Repair of said database?  Lastly, what formatting types are you using for the custom fields?

Hi Derek. To answer your questions…

I’m not seeing any type of slow down in any other page renderings.

Extensions—just control panel stuff:
EE 1.2.1 Publish Form Extension
Remove “My Account” Tab (v.1.1)

The test installation has the identical data that the live site does.

Optimized and repaired database and…no change.

Text Formatting for the custom fields: None
(Is this what you were asking for this last one?)

Can you post your search results template in a code block, please?  If anything, the search results parsing should be a bit faster than the weblog entries tag, because the query for entries has already been handled for you and cached.  And we really didn’t change anything in the Search module for 1.6.

I’m trying to think if there’s something I’m not telling you because I don’t know any better. What other info might help? Hmmm…um…when this data is shown “normally” in a template (like, not as the result of a search), it is pulled out using the query module rather than the weblog module. Does that mean anything?

Here’s the search results code:

<table cellspacing="0" cellpadding="0" class="sales" summary="This table presents a listing of sheriff's sales.">
<thead>
  <tr> 
    <th>Case #
Docket #</th>
    <th>Scheduled
Sale Date</th>
    <th>Plaintiff
Defendant</th>
    <th>Approx.
Judgement</th>
    <th>Street Address
Town</th>
    <th>Complete Status</th>
    <th>Purchaser
Price | Date Sold</th>
  </tr>
</thead>
<tbody>
{exp:search:search_results}<tr> 
    <td>{title}
{ss_docket}</td>
    <td>{entry_date format="%n/%j/%y"}</td>
    <td><strong>PLTF:</strong> {ss_plaintiff}
<span class="hilight"><strong>DEF:</strong> {ss_defendant}</span></td>
    <td>${ss_judgement}</td>
    <td>{ss_address},
{ss_town}</td>
    <td>{ss_status_code} {ss_status_comment}</td>
    <td>{if ss_buyer != ""}{ss_buyer}
${ss_sold_price} | {expiration_date format="%n/%j/%y"}{/if}{if ss_buyer == ""} {/if}</td>
</tr>
{/exp:search:search_results}
</tbody>
</table>

{if paginate}<div class="searchpaginate">{page_count}  {paginate}</div>{/if}

Yes, it’s quite different.  Can you use the weblog entries tag on a template, please, and use the same code in it that you are using inside your search results tag?  For the tag parameters, examine the search form tag itself so you can be sure that you a mimicking it as closely as possible, sans searching for specific content.

Ugh. Really slow response time, similar to the search results response time. (Here’s the code I used, just to make sure I’m not a spaz):

<table cellspacing="0" cellpadding="0" class="sales" summary="This table presents a listing of sheriff's sales.">
<thead>
  <tr> 
    <th>Case #
Docket #</th>
    <th>Scheduled
Sale Date</th>
    <th>Plaintiff
Defendant</th>
    <th>Approx.
Judgement</th>
    <th>Street Address
Town</th>
    <th>Complete Status</th>
    <th>Purchaser
Price | Date Sold</th>
  </tr>
</thead>
<tbody>
{exp:weblog:entries weblog="foreclosure" orderby="date" sort="desc" show_expired="yes" show_future_entries="yes" status="open" disable="categories|member_data|trackbacks" limit="60"}
<tr>
    <td>{title}
{ss_docket}</td>
    <td>{entry_date format="%n/%j/%y"}</td>
    <td><strong>PLTF:</strong> {ss_plaintiff}
<span class="hilight"><strong>DEF:</strong> {ss_defendant}</span></td>
    <td>${ss_judgement}</td>
    <td>{ss_address},
{ss_town}</td>
    <td>{ss_status_code} {ss_status_comment}</td>
    <td>{if ss_buyer != ""}{ss_buyer}
${ss_sold_price} | {expiration_date format="%n/%j/%y"}{/if}{if ss_buyer == ""} {/if}</td>
</tr>

{paginate}
</tbody>
</table>
<div class="searchpaginate"><span class="pages{total_pages}">Page {current_page} of {total_pages}</span> {pagination_links}</div>
{/paginate}
{/exp:weblog:entries}

What OS is this, municipal?  It sounds like you may just have some performance issues with the local server.  You should definitely disable and remove any third party add-ons to eliminate them - and check the exp_extensions table to make sure they are removed.  Clear your cache folder manually (ftp/locally), and make sure that the permissions on the directory allow PHP scripts to write to it (if you’re on Windows, it will need Modify permissions as well).

Then turn on both Template and SQL Query debugging output in your Output and Debugging preferences, and look for anything unusual.

That’s probably about all we will be able to help with in troubleshooting this local environment.  You can backup your files and database before updating the live site, of course, so I’d recommend upgrading.  If the problem carries over to that site, we can investigate further, but I don’t know that I can do any more detailed troubleshooting without access to your machine.  The page you show above should render and complete very very quickly.