info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- Nikolai Shcherbin@rivervanrain
Nikolai Shcherbin - 0 likes
Try to optimize and tune MySQL Use multiple database connections. Upgrade to Elgg 3. Test and test again
- Reuven@reuven
Reuven - 0 likes
- Reuven@reuven
Reuven - 0 likes
- Jerome Bakker@jeabakker
Jerome Bakker - 0 likes
- Reuven@reuven
Reuven - 0 likes
You must log in to post replies.To much 'joins'
Thank you Nikolai
Very useful
Simple experiment – Excellent results
Disclaimer: May upset Relational DB experts :)
In our case we have 13 filters, each is based on one metadata. For each filter we need 2 Joins (for the metadata and metastring tables) and Wheres with 2 sections (for the metadata name.id and the value). All together 26 Joins and 26 wheres., some of them are quite heavy like calculation the distance between two geographical point on the globe.
However, the page is very slow with 7 filters, and dead with 10 or more.
So, we did a simple experiment. We added a table to the Elgg database with foreign key e.guid and duplicated the relevant metadatas as columns in the new table. The query is composed of one Join (with elgg_entities) and 13 Wheres.
Now the page loads in about a second.
Of course, this is not the best practice but it may be a solution.
We would appreciate any reflection on this experiment.
Is it safe?
Are there other alternatives?
Do future versions of Elgg have solutions to such problem?
Thank you.
In Elgg 3 the normalization of the metadata/metastring table was removed. This will help in speeding up those kind of queries.
Time to update ;)
Thank you Jerome