[Nodeshot] TX, RX rate

[nemesis]

 [CUT]


>> So to summarize, the questions are:
>
> Summarizing my opinions below:
>
>> * should every interface type have tx_rate and rx_rate or not?
>
> No.
>
>> * if not, which types?
>
> Only wireless 802.11 and wired ethernet.
>
>> * should link objects have tx_rate and rx_rate?
>
> Yes.
>
>> * if yes how should those values be determined?
>
> min_rate and max_rate instead of computing the average.

 do you mean:

 * min_tx_rate
 * min_rx_rate
 * max_tx_rate
 * max_rx_rate

 Sounds good. On the UI we could show an average with 
 besides/below/onrollover all these values.

 Will it be problematic to update all these info very often?

 Immagine the flow:

 1. system goes to find the tx/rx, dbm, ecc.
 2. updates Interface A
 3. updates Interface B
 4. updates Link object

 They're not very complex queries though, it should be ok.

 I was thinking to implement some realtime updating too, for example, 
 you open up a device in the web interface, and you get real-time data 
 through a websocket connection between the browser and the server, the 
 server retrieves the info via one of the "connectors" (SSH, SNMP, HTTP, 
 ecc) every x secs and sends it back to the all the listening browsers on 
 that channel (so each opened device page will be a channel in order to 
 avoid crashing the server in case of many users watching the same page).

 I'm worried that the final result will be heavy from a hardware 
 resource point of view (many queries, often). I already see that when 
 performing some operations many queries are generated, but maybe we can 
 take care of optimization later.

 Pheraphs here there are some optimization or profiling experts?

 Anyone has experience in profiling / automated performance testing / 
 stress test?