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

Improve dashboard performance: streamline 2 http requests #3065

Closed
mattab opened this issue Mar 22, 2012 · 12 comments
Closed

Improve dashboard performance: streamline 2 http requests #3065

mattab opened this issue Mar 22, 2012 · 12 comments
Assignees
Labels
Bug For errors / faults / flaws / inconsistencies etc. c: Performance For when we could improve the performance / speed of Matomo. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Mar 22, 2012

When loading the dashboard, there is a noticeable slowness since recent changes. I think there is aneasy way to make the dashboard fast again.

explanation: when loading dashboard, the following http requests are made:

  • first: index.php?module=Dashboard&action=embeddedIndex&idSite=1&period=month&date=2012-03-21
  • Then, once loaded this triggers 2 requests
    • Get dashboard layout for user: index.php?module=Dashboard&action=getDashboardLayout&idDashboard=1&token_auth=anonymous&idSite=1
    • Get available widgets: index.php?module=Dashboard&action=getAvailableWidgets&token_auth=anonymous&idSite=1
  • Then, standard widgets are displayed once these 2 are finished loading.

The requests 2) and 3) should be streamlined and included in the output of the first one module=Dashboard&action=embeddedIndex

This way, the dashboard should be fast again :-)

@sgiehl
Copy link
Member

sgiehl commented Mar 22, 2012

I'll have a look at that.

@sgiehl
Copy link
Member

sgiehl commented Mar 31, 2012

(In [6142]) fixes #3065, refs #3011 initial version of multiple dashboard feature
refs #2857 fixed id collisions in modal confirm windows by using an role attribute instead of id

@mattab
Copy link
Member Author

mattab commented May 3, 2012

(1) In trunk when loading /piwik/ there is still an extra http request: index.php?module=Dashboard&action=getAvailableWidgets&token_auth=XYZ&idSite=1

This can be seen

  • Loading data...
  • Few seconds later: & Dashboard appears
    • here request fires to getAvailableWidgets
  • 1s later: All widgets load

For performance improvement the request getAvailableWidgets could be included in the response of embeddedIndex.

(2) Also, another way to slightly improve perf: the JS that is inlined in embeddedIndex could be put instead in a JS file so that it's loaded only once in the big minified JS rather than on each dashboard load.

(3) A small UX feedback which maybe is related: after the response from getAvailableWidgets currently comes back, I can see the [Widgets&dashboard] menu moving to the right a few pixels. Instead it should be at the right position from the start so that there is no "pixel" jumping when the content loads.

@sgiehl
Copy link
Member

sgiehl commented May 7, 2012

(In [6253]) refs #3065 moved js code from template to additional js file

@sgiehl
Copy link
Member

sgiehl commented May 7, 2012

(In [6254]) refs #3065 fixes UX regression

@sgiehl
Copy link
Member

sgiehl commented May 25, 2012

well, it would be quite easy to include the seperate request for the widgets. But that would mean we would have to transfer that data whenever the user switches to a dashboard. that would be useless, as we need that data only once.

@mattab
Copy link
Member Author

mattab commented May 25, 2012

What I propose is that the request to Dashboard controller returns directly the Menu data, Widget data for the dashboard loaded by default, and layout of dashboard loaded by default.

Then when clicking on another dashboard the http request would return layout, widgets available for this dashboard in the same http request.

  • index.php?module=Dashboard&action=getAllDashboards
  • index.php?module=Dashboard&action=getAvailableWidgets

Maybe these requests still need to be made when a widget is added/ a dashboard renamed/removed. Could we then just trigger in these functions the requests above to update the json data?

Streamlining these 2 json objects in the main request to the embed dashboard will speed up embed dashboard speed quite a lot and is experienced by all users as the first thing in piwik.

@sgiehl
Copy link
Member

sgiehl commented May 30, 2012

(In [6409]) refs #3065 include available widgets in embeddedIndex, so no additional request is required

@sgiehl
Copy link
Member

sgiehl commented May 30, 2012

now index.php?module=Dashboard&action=getAvailableWidgets is not requested anymore. the allDashboards request ist not required to render the page, it only updates the dashboard list in the menu, which is allready available before.

@mattab
Copy link
Member Author

mattab commented May 31, 2012

Nice change!

It seems the widgets are not recorded anymore: when I add a widget to dashboard 2 it adds it to dashboard 1 as well.

  • The problem is that click on another custom dashboard does not update "idDashboard" in the menu, it is still idDashboard=1

Regarding performance:

  • getAllDashboards is not required to render, but the http request is queued before any of the widgets. Could we force the http request to queue like 1s later on ?

Thanks!

@mattab
Copy link
Member Author

mattab commented Jun 1, 2012

It can be improved a bit more as per previous, but definitely the main things have been fixed and it is not a blocker for release anymore. Thanks Stefan!!

@sgiehl
Copy link
Member

sgiehl commented Nov 7, 2012

I had another look at this issue and I don't think that can be improved that mutch.
Requests for widgets are already queued before the getAllDashboards request.

@mattab mattab added this to the 1.12.x - Piwik 1.12.x milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. c: Performance For when we could improve the performance / speed of Matomo. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

2 participants