View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017966 | mantisbt | performance | public | 2014-12-14 16:48 | 2015-03-15 19:58 |
Reporter | dregad | Assigned To | vboctor | ||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.0-beta.2 | ||||
Target Version | 1.3.0-beta.2 | Fixed in Version | 1.3.0-beta.2 | ||
Summary | 0017966: My View Page takes about 5s to load | ||||
Description | Since this tracker was upgraded to 1.3.x, I noticed the My View Page is very long to load - anywhere from 4 to 6s to load on average. This is apparently caused by the Timeline feature, if I disable the include the page loads in less than 0.3 seconds. I would assume the root cause is a poorly performing SQL query against the history table, but didn't check in details. | ||||
Tags | No tags attached. | ||||
Maybe a consequence of the commits I pushed last night , but My View Page now seems to load much faster (< 2s) than it did in the last couple of weeks. |
|
The page typically renders between 0.5 to 1s. However, the week 2014-12-01 .. 2014-12-08 has a lot of activity and hence it takes the long duration. I've done some testing for that week and submitted a pull request that improves the times as follows: Before:
After:
Work done:
Possible improvements:
I think other than the very busy weeks the performance is reasonable and we can checkin the pull request and possible open a follow up change for the other optimization. |
|
Thanks for picking this up. I don't have time to review the PR right now, will do so in the next few days.
I agree that on average perf is "reasonable", I would even say "acceptable" on this tracker, and your approach to merge your fix now and work on a better solution later is fine with me on principle. That being said, "My View" being the central point and default page for most people, we should definitely do everything we can to make it as efficient and fast as possible, both from an end-user perspective ("I don't want to wait 2s for my page to load") and from an administrator's point of view (minimize server load) |
|
I've checked in the pull request: https://github.com/mantisbt/mantisbt/pull/565
The current API leverages standard history APIs, if we want to go further, then we will have to operate directly on the raw table and use history APIs raw by raw independent of the issue. This will likely cause a lot of redundant issue related queries, though this may hit a cache, not sure. In other words, a fair bit of work to refactor history API to be able to re-use the same authz logic whether we are iterating on bug_history_table or leveraged from the api that loads history for a specific issue. |
|
Thanks Victor. Maybe we should resolve this one and open another issue to follow up on an eventual change in history API to accomodate for your proposed approach, assuming it's cost-beneficial to implement it (no idea what kind of effort is involved here). |
|
MantisBT: master afacf2ec 2015-01-13 21:36 Details Diff |
Don't process history entries outside date range Don't process history entries outside date range The following queries cut the number of queries in half: - Remove skip() method from events class since history api does the filtering. - When processing history events for an issue, only process ones within desired time range. Before: - Total queries executed: 1232 - Unique queries executed: 1231 - Total query execution time: 0.7097 seconds After: - Total queries executed: 574 - Unique queries executed: 573 - Total query execution time: 0.2581 seconds Issue 0017966 |
Affected Issues 0017966 |
|
mod - core/classes/IssueAssignedTimelineEvent.class.php | Diff File | ||
mod - core/classes/IssueNoteCreatedTimelineEvent.class.php | Diff File | ||
mod - core/classes/TimelineEvent.class.php | Diff File | ||
mod - core/history_api.php | Diff File | ||
mod - core/timeline_api.php | Diff File | ||
mod - core/timeline_inc.php | Diff File |