[#14473] - Fields Performance - Value Queries
- Closed
- 13 Mar 2017
- Medium
- Build: staging
- # 14473
For every field, a single query is issued to look up its value:
SELECT `value`
FROM `#__fields_values`
WHERE `field_id` = 25
AND `context` = 'com_content.article'
AND `item_id` = '318'This article was in a context where 13 fields were available to it, and on a category view, so in essence it was issuing 13 lookup queries for each article.
This is not going to scale well.
joomla-cms-bot
- | Labels |
Added:
?
|
||
It was commented before this code was ever committed that for every field you are adding a query. I was told it wasnt a real issue :(
Well it is. We ran into this on our company's dev site with a slightly misconfigured fields setup that resulted in 260 extra queries being run (and inherently the page being basically dead).
Fields is essentially unusable in a category view. That's my conclusion from today's experience.
Please remove fields from category/featured view. Otherwise joomla (outside tags) will have to load fields too.
i only say what I was told not what i believed to be true :)
Please remove fields from category/featured view.
And the next one will ask to add it again...
And even if you remove it you still have the issue with the single article view that each field is looked up individually, one query for each field.
If we can get it at least down to one per item, it should not be that bad in list views imho.
It could maybe be reduced to one per list, but that would likely mean loading and caching all values for a given context which certainly isn't ideal either.
Ca not we load all fields per article? And do not use fields in categories. I have to take a look in code.
About categories: maybe add some new parameter to menu item.
"Show fields": article view, category view, ...
It's not so much adding fields to categories, but our issue was we had fields assigned to a category and a category page that was rendering 20 articles. 1 value lookup for each field in each article that's being displayed adds up quickly.
It's tolerable on a single item view unless you're adding 100 fields (if you do you're doing it wrong). But any config that is adding more than ~50 queries is screwing things up.
I always mean fields for articles in category view.
As long as we don't have events which are triggered for multiple articles at once it will be difficult to solve. Another approach would be to integrate com_fields into the models and abandon the plugin approach.
Having a look on the code, some optimisation should be possible. Will make a pr later.
Shall we consider this as a Release Blocker?
I think so.
Closing as we have a PR.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-03-13 19:59:09 |
| Closed_By | ⇒ | Bakual |
Yep, that's indeed not going to scale well.
I think we should be able to drop the
WHEREfield_id= 25part and retrieve all values for a given context and item_id in one query and work from that (maybe using some cache).Pinging @laoneo, what do you think?