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
live widget could benefit from sleep mode / shared hosting scenario #6545
Comments
👍 |
Thanks for the suggestion, fetching real time visits only when the tab is actively viewed makes sense! |
see also Make Real time Live widget faster: one bulk HTTP request instead of two #6575 |
Great, thanks for taking it on the list! |
At first I used the window.blur/focus events but noticed it would also stop refreshing if tab is active but browser window is not active. I reckon many people might want to leave the browser open in one window and follow the live visitors while working on something else. That's why we should use the page visibility API which is supported by most browsers (I think not in <= IE9). I used a different library first but noticed it adds many event listeners like mousemove etc and it can make Piwik slow so used the visibility.js library in the end. If someone uses an old browser nothing will change compared to before so that should be ok. In a next version we could initiate a refresh immediately once the browser tab becomes active again.
If possible, this idea of sending the live plugin to sleep (which makes sense and is a good one, especially in that low-resource server scenario) should be an OPTION.. not a forced behavior for everyone. The best way i can think is to have it in config.ini. "Live refresh time= x seconds", "Live auto-sleep mode=disabled/enabled". Or something like that. I for one DO want the live widget to refresh itself every couple of seconds, even without tab focus.. and i also have some customized scripts and additional php code relying on the live widget auto-refresh. And the prospect of focusing the tab and syncing all of a sudden everything that had happened since my last tab focus would turn my desktop into a complete mess :) |
@Glisse1 - |
@Glisse1 would it be ok if, once you focus the tab again it automatically refreshes all the displayed data? This is already done partially for real time visitors not yet for the counter and map. I am personally not a big fan of too many options and would rather try to solve it this way. |
@tsteur the more I think the more i realize the wikiloops is right.. with respect to the fact that I, having a powerful server rented, with no problems regarding hits/day, and also in need of constant refreshing of real-time widget, am but a small minority of "power users".. if it is complicated to declare the option in config.ini, or just against the long-term vision of how piwik should be, then just drop it.. most likely there will be a way to make it auto-refresh directly in the code :) But refreshing all displayed data on tab focus i believe is not a good idea.. and will tend to become frustrating for the user, focusing on that tab maybe tens of times per day, because there are widgets which load pretty slow, several seconds, even 10 or more sometimes, the more widgets the longer waiting.. on focus the only autorefresh must be for the real-time widget in my opinion, that`s the one that matter, the one with the real-time component.. for other widgets eg. OVERVIEW i tend to manually refresh it at the end of the day and get the data anyway. |
Nice! The real time widget is already auto refreshing when focusing again. The live counter and real time map will simply update in their specified interval once the tab is focussed again. If you have defined an interval of 10 seconds it will take up to max 10 seconds until the other widgets will be updated but it could already update after 2 or 5 seconds... BTW: There is a little trick that works at least in Chrome I think. You can open the tab in a separate browser window so it will never lose focus and will always update. Use another browser window to browse the web as normal. FYI: It is neither complicated to add an option nor is it a long-term vision of Piwik. Some core developers even seem to love options as new ones are added quite often ;) I do not really believe in them. When we can solve it in a way to make 80% of the users happy without having to use an option it is easier for everyone. Of course this takes time and is more work than adding an option. By refreshing the data when the tab gets focus makes an option obsolete which is great as users won't have to worry about it. Most users wouldn't find the option anyway. Don't think many people actually read through all the possible config options. Probably many people don't even know about the config. In general: You can imagine that many users want to use Piwik in a different way and by adding new options all the time we end up in thousands of options which is not maintainable anymore. I'd currently rather remove some options :) |
Scenario:
I am running a project on a shared hosting account and have been told to move to a dedicated server for "causing too much load".
This issue may only be relevant for rather low traffic sites on similar hosting contracts, but maybe implementing it can be easily done, so I thought I'd adress the following idea:
When analyzing my log files it became quite obvious that about 15% of all http hits of my project are caused by PIWIK, while I am seeing 1400+ visitors and around 17k pageviews/tracked actions a day.
Looking closer, it turns out a lot of the hits created are caused by the live widget refreshing.
Looks like the live widget refreshes about every five seconds, and with me having PIWIK open in some browser tab all the time, the live widget causes about as many http hits in 24 hours as the users I am tracking.
Proposed fix:
If possible, could the live Widget go to sleep as soon as the browser tab looses
focus
or isblurred
, and wake up the moment the tab gains focus again ?I imagine there may be quite a lot of PIWIK lovers who can't help having a look at their live statistics every now and then and keep it running like I do... this fix would save around 5% of my http hits, and it may be even more depending on the number of visitors a site has.
p.s.
I'm fairly new to GitHub, so please excuse my throwing ideas at you without creating a fork myself.
I believe someone familiar with the code will be a lot quicker doing this. Thanks for PIWIK :)
The text was updated successfully, but these errors were encountered: