Serious Performance Issues
| Project: | Site User List |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hello,
We've been using site_user_list to list our members, and recently when only eight or so people were online, our host gave us a CPU/Memory overload message. We traced it down to site_user_list - the display queries were taking up to 15 seconds - everything else did not even come close. We have over 30 profile fields, and all are essential for our social networking website.
Log (trimmed):
# Mon Jan 21 21:34:37 2008
# Query_time: 15 Lock_time: 0 Rows_sent: 34 Rows_examined: 24332
use database;
SELECT DISTINCT `@uid`, `@picture`, `@name`, `@profile_first_name`, `@profile_last_n$
Is there any work being done towards query optimization? As our site grows, there's no way it can handle 15-second queries with many people viewing the member listing page.
All the Best,
Andrey.
#1
What is the module retrieving data from -- a subselect query, a view, or a table? You can find out on the settings page.
Ricky
#2
A view.
Thanks, Ricky.
Andrey.
#3
Hm. I guess that MySQL isn't optimizing very well. Switch to a table, and turn on cron rebuilds. This should speed things up. Note that changes to users' profiles won't be reflected until the next time cron.php is run.
I plan (when I have enough time to actually work on this again) to switch it over to rebuilding when changes are made, so that there isn't the cron.php lag.
There may also be ways you can change MySQL so that it better optimizes the query, but I don't know what they would be.
Ricky
#4
Switched to the table/cron thing - much better performance (at least 10 fold).
Thanks, Ricky.
All the Best,
Andrey.
#5
what does it mean to switch to a table?
#6
It's how the results are stored are retrieved. Check the site user list settings page under "Retrieve data from a:"
A.