You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some ideas for features would be great, but they may stress a piwik server.
This ticket is about making it possible to implement these features and giving ideas
why "performance reasons" shouldn't be a blocker.
A) Some reasons why "performance reason" it's not always a "killer" and why and how one can deal with it:
piwik is very often used on pages with very low traffic
one did not need all information on load of a page so one can display it when it's ready
performance of server hardware is growing very fast (Multicore CPU, tons of RAM, SSD, PCIe-NVME SSDs...)
Performance of software grows, e.g. PHP 5.6 => 7.0
sometimes one do not need the very exact number:
so one can "Stop counting" after a special amount of time and show something like "1000+"
one can reuse numbers
one can preindex values (on times when there is low server load)
data could often be (re-)used on several places
one can implement a switch in settings to activate all things which are great but power consuming (for users with a good quotient of vistors/server power and backend user/server power)
one can cut the worst case: do not show if segment is "all visits"
...
I'm no developer, but probably there are several more ideas to work with power demanding tasks in general...
B) of course not a solution but a demonstration, that others are working with perfect performance too (e.g. counting number of entries)
Yes of course it looks unfair because google has other "resources", but they also have other amounts of data to deal with ;-)
C) Would be good to have some kind of best practise guide for working on performance relevant things within piwik.
D) Would be good to have a new label for issues of type: "performance demanding"
so every one discussing or working on this issue is aware to take care for this
E) This is a list of things which were already dropped because of not possible because of performance reasons - maybe one can revise them again
BTW: There is also #6759 where we worked on some tweaks. Some of those issues might be actually not such a big deal anymore (I haven't looked at the one you mentioned yet).
Some ideas for features would be great, but they may stress a piwik server.
This ticket is about making it possible to implement these features and giving ideas
why "performance reasons" shouldn't be a blocker.
A) Some reasons why "performance reason" it's not always a "killer" and why and how one can deal with it:
piwik is very often used on pages with very low traffic
one did not need all information on load of a page so one can display it when it's ready
performance of server hardware is growing very fast (Multicore CPU, tons of RAM, SSD, PCIe-NVME SSDs...)
Performance of software grows, e.g. PHP 5.6 => 7.0
sometimes one do not need the very exact number:
data could often be (re-)used on several places
one can implement a switch in settings to activate all things which are great but power consuming (for users with a good quotient of vistors/server power and backend user/server power)
one can cut the worst case: do not show if segment is "all visits"
...
I'm no developer, but probably there are several more ideas to work with power demanding tasks in general...
This is an extract of write up #9110
B) of course not a solution but a demonstration, that others are working with perfect performance too (e.g. counting number of entries)
Yes of course it looks unfair because google has other "resources", but they also have other amounts of data to deal with ;-)
C) Would be good to have some kind of best practise guide for working on performance relevant things within piwik.
D) Would be good to have a new label for issues of type: "performance demanding"
so every one discussing or working on this issue is aware to take care for this
E) This is a list of things which were already dropped because of not possible because of performance reasons - maybe one can revise them again
F) This is a list of all issues where performance should be observed:
Please add all your ideas and findings to A)...F)
The text was updated successfully, but these errors were encountered: