UI: Stats trackers #4635
UI: Stats trackers #4635
Conversation
The maxLength is enforced by removing elements from the head of the list.
It follows the form of poll -> json parse -> append, Where append is defined in subclasses to add data from the new frame to long-lived rolling arrays of data.
It accumulates CPU and Memory usage for the allocation as a whole as well as by task.
DingoEatingFuzz
force-pushed
the
f-ui-stat-trackers
branch
from
912d3df to
f8c8c3c
Compare
| do { | ||
| yield this.get('stats').poll(); | ||
| yield timeout(1000); | ||
| } while (!Ember.testing); |
| cpu: computed('allocation', function() { | ||
| return RollingArray(this.get('bufferSize')); | ||
| }), | ||
| memory: computed('allocation', function() { |
There was a problem hiding this comment.
what's the difference between these and the cpu + memory that are returned on the hash from the tasks computed prop?
There was a problem hiding this comment.
These are aggregates for the whole allocation. In the case where there is only one task, they're in theory the same value.
| // the front of the array. | ||
|
|
||
| // Using Classes to extend Array is unsupported in Babel so this less | ||
| // ideal approach is taken: https://babeljs.io/docs/en/caveats#classes |
There was a problem hiding this comment.
Are there any additional implications since ember has prototype extensions on? Seems like you would still be able to call ArrayProxy methods on the returned array, is that right? And is it a concern? (tried to think of a way to prevent that but nothing's coming to mind)
There was a problem hiding this comment.
There are, which I have addressed in a future branch. Mostly addObject needs to behave like push does.
| return returnValue; | ||
| }; | ||
|
|
||
| array.unshift = function() { |
There was a problem hiding this comment.
Probably not a use case for it, but could be cool to support push and unshift (and probably not splice? or just push out both sides with splice?) and then you remove the surplus from the opposite side so that it's a SlideArray.
There was a problem hiding this comment.
Ah yeah, that could be cool. I want to keep this as specific as possible though. The next thing I'm likely to address (probably in a different array type) is some sort of rolling aggregation. So there is still fine-grained second-by-second resolution for recent figures, but on the early end of the array, the resolution would be something like one point per 10 seconds, or one point per minute.
Still a nebulous brain noodle for now, but I may end up dabbling with it after I finish this first pass at everything.
There was a problem hiding this comment.
Hey, sorry bit late here, if you are avoiding closures, would Array.prototype.push.apply(this, arguments) help here? It would mean you wouldn't have to add your _push etc (polluting the array)
There was a problem hiding this comment.
Normally I hesitate to do that because there is no guarantee that array.push === Array.prototype.push, but in this case, the Array constructor is being invoked directly, so you're totally right that I can just use the methods on the prototype.
Good call, I'll make this change in my current branch 👍
|
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
This is part of a larger project to improve the cpu and memory usage charts in the UI
A
StatsTrackeris a new class that handles fetching data and using the resulting payload to append to an arbitrary number of long-lived stat arrays.This may sound a lot like what Ember Data does, but this isn't using Ember Data. This data isn't stateful (no writes), and it isn't necessarily globally persistent (created and deleted on demand). Although fetching and normalizing the data does overlap in behavior with adapters and serializers, given the nature of client and allocation stats, I think it makes more sense to keep this data out of the Ember Data store.
The purpose of
StatsTrackersis to build up data that can be used to power line charts for stats as stats are polled.StatsTrackersthemselves don't create line charts nor do they control polling. The expectation is for a controller or component to use ember concurrency or something else to set up a polling loop that callstracker.poll(), which handles fetching and appending of data. Then, the resulting data arrays in a tracker (tracker.get('cpu')) can be provided to a theoretical line chart component ord3.datacall to build a chart with.The structure of the
StatsTrackerclasses are modeled after theLogsuite of classes (Log,StreamLogger, andPollLogger). They are Ember Objects but exist outside of the registry/container environment. They expect dependencies (such as thetokenservice) to be provided to them. Computed Property macros were written to make them easier to use.