Hi jjorio,

Except some small fixes for security or minor issues, the latest release of SEBLOD 1.x is more than 2.5 years old. (ie end of 2010)

As you know Joomla 1.5 is no longer supported... and SEBLOD 1.x neither.

Unfortunately there is no search indexing in SEBLOD 1.x and the main issue is that everything is stored in the "introtext" field in a custom format... this means that the search engine uses regexp in order to match the results...

But.. there is a cache system. You can see the caching parameters (cf screenshot).
You should enable it. (from the search type edit view, click on the "edit action field" button)

Of course if you use SEBLOD 3.x on Joomla! 3.x (maybe for your new web projects), you'll see that you can now store the value of your fields in "standard" format (each value in its own column), and thus.. search performances are far away better now!

Regards.
Saba

Thanx Saba, I'll be testing this right away ...
I suppose this caching system needs the page to be visited a first time before it is stored, as I have a lot of searching critereas, this means I'll always have a lot of slow pages, or have to do all searches myself each time I change something in the database.
Is that how it works ?

Of course, next website, will be on the latest, but you can guess on this one I don't have the choice :)

I tested the cache options. They are quite effective for the speed, but as expected, every page needs to be viewed once before it is stored and displayed fast.

I have another question.
Here is the debug query :

SELECT a.id, a.title AS title, a.metadesc, a.metakey, a.catid, b.title as category, a.alias, a.sectionid, a.created AS created, a.created_by, a.created_by_alias, a.modified, a.publish_up, a.publish_down, a.hits, a.attribs, a.introtext, a.fulltext, CONCAT_WS( "/", u.title, b.title ) AS section, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END as slug, CASE WHEN CHAR_LENGTH(b.alias) THEN CONCAT_WS(":", b.id, b.alias) ELSE b.id END as catslug, u.id AS sectionid, "2" AS browsernav FROM #__content AS a INNER JOIN #__categories AS b ON b.id=a.catid INNER JOIN #__sections AS u ON u.id = a.sectionid WHERE ( a.introtext NOT REGEXP "(::pickstartstc::)20130705(::/pickstartstc::)" AND a.introtext NOT REGEXP "(::pickendstc::)20130712(::/pickendstc::)" AND a.introtext NOT REGEXP "(::lang::)en(::/lang::)" ) AND a.state = 1 AND u.published = 1 AND b.published = 1 AND a.access <= 0 AND b.access <= 0 AND u.access <= 0 AND ( a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2013-06-05 12:43:50' ) AND ( a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-06-05 12:43:50' ) GROUP BY a.id ORDER BY FIELD(a.title, "")

Search [cache]: 1.112 seconds, 22.46 MB ~ 240 Results
Display [cache]: 31.775 seconds, 183.06 MB

Looking to the two lines below, it seems that the search itself doesn't take that long. The display does.

Could it be due to :
- Number of results displayed
- Weight of information extracted for each result
- The overall weight of the page
- All of theses ... ?

Thanks for any advice ! :)

Regards