-
Notifications
You must be signed in to change notification settings - Fork 122
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
Graph display is very slow and uses a lot of memory #1887
Comments
Could you please post the output of an |
Thank you for your response.
|
This is also targeting the statlogs table. How many tuples do you have there...
|
|
@madsi1m I am wondering if you also have a StatLogs with roughly this many tuples? |
|
EDIT: re-reading above looks like the upload screen Which graph are we talking about here? |
We also set this in config.php
|
We don't set it, but it's a default value, isn't it? |
yes, it is the default filesender/includes/ConfigDefaults.php Line 213 in bae2e54
|
The thing that is jumping out at me in the original explain is the id=21 row is using the The below queries will give an idea of what the real stats are for the event type, recent events, recent-events of the right type, and the whole query. I imagine that there are a lot of recent events and so the 31 days is not selective enough for that to be the preferred index condition. I have left the results out of my data below as it is only a one man development machine so the counts that I have are not interesting.
Given that for me there is a reasonable difference between just the event filter and the event filter AND the size filter (the first and last count in the above queries) maybe the below index will also help? If it is useful then I can add it and we can drop the tmp1 index in favour of a more permanent one.
|
above (without adding/changing db)
|
Another reasonable candidate which I can get my local db to accept and use is the following. If we can go from around a million tuples from the index to in the thousands we are off to a good start.
|
You may also have to drop the tmp1 index to force mysql to consider only the new tmp4 one. |
From a college... "It may be an idea to just have table with summary info in it that's generated each day with these calculated values, wouldn't take much space and wouldn't take long to make, so then these queries would be instant" |
our users like to see there high speed link bump the graph, as our cron is every 15min maybe have cron generate the uploadGraph.php data? Or implement a cache for uploadGraph.php's data? I've done such things in other projects using redis but you can use whatever really. Basically in uploadGraph.php do something like: |
can probably also make a config value for the TTL |
uploadGraph.php looks like something i wrote..... |
When there are many transfer histories, the graph display on the upload screen is very slow and uses a lot of memory on the MySQL database.
In our site's case, it is normally over 20 seconds.
Unfortunately, our site went down because it ran out of memory when multiple users displayed the upload screen simultaneously.
So, we don't show the graph now.
Number of rows in Transfers table;
about 40,000
Number of rows in AuditLogs table;
about 800,000
Number of rows in StatLogs table;
13,843,255
SQL
The text was updated successfully, but these errors were encountered: