This site uses cookies and similar technologies.

If you don't change browser settings, you agree to it.

I understand
3 Posts
jjorio
6 years ago
3
Topic

Hello,

I'm using SEBLOD 1.9 with Joomla 1.5, and the search is very slow, actually unusable.
I've tried some of the optimization hints I found in  the forum, but it didn't change the speed.

Any idea about how to optimize the search ?
Maybe a stupid question : is there any search indexing in SEBLOD 1.9 ? If yes, how to use it ?

Thank you guys !




Get a VIP membership
6 years ago
0
Level 1

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)

seblod-1x-caching-params

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

3 Posts
jjorio
6 years ago
0
Level 1

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 :)

3 Posts
jjorio
6 years ago
0
Level 1

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

Get a VIP membership