Révision cb81debf papers/2014/kwapi/paper.tex
| b/papers/2014/kwapi/paper.tex | ||
|---|---|---|
| 276 | 276 |
\label{fig:cpu_usage}
|
| 277 | 277 |
\end{figure}
|
| 278 | 278 |
|
| 279 |
We also evaluated the CPU consumption of the REST API data consumer under the scenarios described in Table \ref{tab:parameters_usage}. In addition to these scenarios, two conditions were assessed, namely (i) the REST API working as a consumer requesting data from drivers at a one-second time interval (REST API only); and (ii) the API requesting data at one-second interval and also answering a call every second to provide the collected data to an external system (REST API + 1 req/s). Figure \ref{fig:cpu_usage_consumer} summarises the obtained results. The CPU consumption is in general low, and even when message signing is enabled and the API serves a query, its consumption is below 20\%. The small variation between the scenarios without message signing is caused by the manner ZeroMQ accumulates data on nodes prior to transmission.
|
|
| 280 |
|
|
| 281 |
\begin{figure}[!ht]
|
|
| 282 |
\center |
|
| 283 |
\includegraphics[width=1.\columnwidth]{figs/cpu_usage_api.pdf}
|
|
| 284 |
\caption{API consumer CPU usage under the evaluated scenarios.}
|
|
| 285 |
\label{fig:cpu_usage_consumer}
|
|
| 286 |
\end{figure}
|
|
| 287 |
|
|
| 279 | 288 |
Although the CPU usage often depends on the drivers, data consumers, and their complexity, and whether message signature is enabled, the experiments show that a large number of probes can be managed by a single machine. In our environment, a management machine per site is more than enough to accommodate the users' monitoring needs. The drivers and API can reuse a machine that already serves other monitoring purposes. |
| 280 | 289 |
|
| 281 | 290 |
\begin{figure}[!ht]
|
Formats disponibles : Unified diff