Closed (fixed)
Project:
Hierarchical Select
Version:
6.x-3.6
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
12 Feb 2011 at 17:24 UTC
Updated:
10 May 2011 at 02:00 UTC
Hi all,
during my tests on HS, trying to find a solution to speed up the component, I found there are generated by the component lots of slow query. All the ones are similar to the next one:
SELECT COUNT(*)
FROM (SELECT DISTINCT( node.nid ) AS nid,
node.TYPE AS node_type,
node.vid AS node_vid,
node_data_field_codice_web.field_codice_web_value AS
node_data_field_codice_web_field_codice_web_value,
node.LANGUAGE AS node_language,
node.title AS node_title,
node_revisions.teaser AS node_revisions_teaser,
node_revisions.FORMAT AS
node_revisions_format,
node_data_field_codice_web.field_indirizzo_value AS
node_data_field_codice_web_field_indirizzo_value,
node_data_field_codice_web.field_vani_value AS
node_data_field_codice_web_field_vani_value,
node.created AS node_created,
node_data_field_codice_web.field_trattativa_value AS
node_data_field_codice_web_field_trattativa_value,
users.name AS users_name,
users.uid AS users_uid,
users.picture AS users_picture,
users.mail AS users_mail,
node_data_field_codice_web.field_prezzo_value AS
node_data_field_codice_web_field_prezzo_value,
node_data_field_indirizzo.field_indirizzo_value AS
node_data_field_indirizzo_field_indirizzo_value,
node_data_field_indirizzo.field_prezzo_value AS
node_data_field_indirizzo_field_prezzo_value,
node_data_field_indirizzo.field_vani_value AS
node_data_field_indirizzo_field_vani_value
FROM node node
INNER JOIN term_node term_node_value_0
ON node.vid = term_node_value_0.vid
AND term_node_value_0.tid = 57
LEFT JOIN content_type_annuncio_immobiliare
node_data_field_codice_web
ON node.vid = node_data_field_codice_web.vid
LEFT JOIN node_revisions node_revisions
ON node.vid = node_revisions.vid
INNER JOIN users users
ON node.uid = users.uid
LEFT JOIN content_type_annuncio_immobiliare
node_data_field_indirizzo
ON node.vid = node_data_field_indirizzo.vid
WHERE ( term_node_value_0.tid = 57 )
AND ( node.status <> 0 )
AND ( node.TYPE IN ( 'thetype' ) )
AND ( node.LANGUAGE IN ( 'en' ) )
GROUP BY nid
ORDER BY node_data_field_indirizzo_field_indirizzo_value ASC,
node_data_field_indirizzo_field_prezzo_value ASC,
node_data_field_indirizzo_field_vani_value ASC) count_alias
These queries are very slow! So, I tryied to find the way to optimize them, like adding some index to the Drupal tables, but I didn't find the way to do it.
Would be great if some solution should be added to the installation file of the module.
Did anyone have just solved this problem? Can someone help?
Thanks.
Comments
Comment #1
wim leersIs this a query for a HS that's being used as an exposed filter for a View?
Comment #2
gianfrasoft commentedYes, it is!
Comment #3
wim leersThen there is nothing I can do, I'm afraid. These tables are not managed by HS in any way. Remember, HS is only a widget.
You can optimize this manually, by adding indexes manually.
Comment #4
gianfrasoft commentedHi Wim, I know what you're saying about the widget but I think it should be more useful if there was an index to speed up HS's query.
After a lot of interesting debugging, NOW I think I found the most important performance bottleneck of Hierarchical Select. Closing this issue will turn off the hope of finding a solution to the hs performance.
Some indexes should speed up HS in the way we need to obtain results in less then one second. And someone (may be me, I hope, or someone else) should find this solution. Do you agree with me?
I think we should reopen the issue and try to optimize the query.
Thank you in advance.
Comment #5
wim leersYou don't understand. HS does not generate this entire query. Views generates most of it. HS can't fix that automatically. HS implementations merely query existing data. HS implementations don't *create* their own tables.
Comment #6
gianfrasoft commentedOk. you are right. The query was from a view. So, i think, the problem is another.
Trying to find a way to remove the bottleneck, I realized that: in the HS, used as exposed filter of a view, everytime I select a term it processes the associated view, even if in configuration I have:
So I say, why doese HS process the associated view?
Looking inside the code, I think the bottleneck is in the function hs_taxonomy_views_json at this row:
If I don't need to count the terms and I don't neet to verify if there are associated entities (configuration stored in the elements $config['entity_count'] and $config['require_entity']), can I avoid to the command $view->execute_display?
Thanks!
Comment #7
wim leersThe terms are counted to be able to know when to not perform an AJAX callback. And you're right, this can be optimized. But that's postponed to HS 4. See #1052840: HS 4 roadmap.
Comment #8
gianfrasoft commentedHi Wim,
my respect for your wonderful work and for the next version of HS to came.
Staying on the D6's HS version, let me say you should not underrate the importance of this thread. I'm trying to optmize your component for a long time and now, believe me, I think I found the solution that I and many other people were looking for.
Juggling with the code I realized a great hack (yes, this is only an hack) that solves the problem! Because in the hs_taxonomy_views.module file the command:
$view->set_display($display_id);is indispensable for HS's job, I changed function hs_taxonomy_views_json in the way you can read here after:
I change the view on the fly, adding a fake filter with the goal of generating a new query with the same fields but completely empty, but only if entity_count and require_entity are not set true in the configuration.
I think you will not like this solution, but it is the only one I could find in time that I have granted.
I hope this could help someone and I hope this may suggest you a better solution in the same direction.
Kind Regards, Wim, and thank you again.
Comment #9
amfis commentedHi,
I'll try #8 now and will see what I've get.
Therefore I got huge taxonomies and selecting one term with HS takes about 3 - 5 seconds. Thats A LOT of time. I hope this does fix this issue.
Comment #10
gianfrasoft commented@amfis, let me know how it goes. Remember entity_count and require_entity variables have to be FALSE.
Comment #11
amfis commentedLooks like it is other problem than this "hack" does.
Comment #13
howie commentedI had the same exact issue and struggled with it for hours -- each HS request took 3 - 5 seconds to load each element. I am using HS on a vocabulary with 50+ terms, but I've seen HS fly on vocabularies much larger. I tried the hack in #8 but it didn't work.
I was able to narrow it down to a theme issue as HS started moving quickly after switched back to the default Gardland theme. I am currently using a Zen subtheme, which has a default option to "Rebuild the theme registry on every page" (http://localhost/admin/build/themes/settings/my_theme). This is clearly useful in a development setting to avoid caching issues for your css and js. Once I disabled that option all my HS widgets elements loaded in about 0.5 seconds.
Just a minor set back while developing but it looks like everything works just fine when i'm ready for production.