Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large amount of DB calls while running elgg_get_plugins (Trac #4313) #4313

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 9 comments
Closed

Comments

@elgg-gitbot
Copy link

Original ticket http://trac.elgg.org/ticket/4313 on 42055845-06-25 by trac user srokap, assigned to unknown.

Elgg version: 1.8 Beta

I've noticed that while starting Elgg 1.8 core, there are around 2*#plugins calls to DB being made. The calls are made while instantiating data rows to ElggPlugin objects.

I understand why the mechanism works like that, but it obviously seems like a thing that should be optimized. Why not to reuse data already downloaded in elgg_get_entities instead of calling

SELECT * from elgg_entities where guid=PLUGIN_GUID and ( (1 = 1)  and enabled='yes')

for every plugin.

Than for every plugin we download ELggObject fields:

SELECT * from elgg_objects_entity where guid=2

Question is, why don't we reuse already downloaded data from first call, and why don't we rebuild instantiating process (entity_row_to_elggstar and constructing ElggObject) to support downloading additional data in single query.

To sum up, we could be making two DB calls to get all of the data much more efficient instead of making over 100 queries (I don't think it's likely to have non-trivial elgg service with less than 50 plugins in practice). It's especially important for ElggPlugin, but could be extended to more general mechanism.

@elgg-gitbot
Copy link
Author

cash wrote on 42055975-07-03

I agree this is a huge performance issue. We have some other tickets open on better entity loading. I think I also mentioned to Mike that I think we could cache the plugin objects.

@elgg-gitbot
Copy link
Author

trac user srokap wrote on 42056081-09-08

Just a thought, I've removed first king of calls by allowing ElggEntity->load function to process db row optionally to guid as parameter, and changing ElggObject constructor call. I also thought of something like passing second argument to get_data callback, to pass there some additional row info that could be used by the callback, and passed somehow to the constructor maybe? I'm not sure if it would be helpful if some more sophisticated mechanism is under development.

Are there some particular ticket's You're referring to?

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.4 by cash on 42100000-01-01

@elgg-gitbot
Copy link
Author

brettp wrote on 42316380-11-05

Not time to get this in 1.8.4. Setting at high priority for next release.

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.5 by brettp on 42316380-11-05

@elgg-gitbot
Copy link
Author

trac user Brett Profitt wrote on 42371848-11-05

Refs #4313. Loading ElggPlugin classes with the fully joined objects table.

This cuts the number of db queries in half for loading plugins with elgg_get_plugins().
Will look to adapt these techniques to other classes in 1.8.6.
Changeset: 40d3516

@elgg-gitbot
Copy link
Author

trac user Brett Profitt wrote on 42422641-05-01

Refs #4313. Loading ElggPlugin classes with the fully joined objects table.

This cuts the number of db queries in half for loading plugins with elgg_get_plugins().
Will look to adapt these techniques to other classes in 1.8.6.
Changeset: 40d3516

@elgg-gitbot
Copy link
Author

cash wrote on 42460621-05-01

We are now loading all the plugins at once (both entity and object tables).

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.5 by cash on 42460621-05-01

adayth pushed a commit to adayth/Elgg that referenced this issue Feb 22, 2013
…cts table.

This cuts the number of db queries in half for loading plugins with elgg_get_plugins().
Will look to adapt these techniques to other classes in 1.8.6.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant