Hello,

I'm currently using PRTG API to retrieve performance of each sensors for further processing and use in our own system.

We have around 3 thousand sensors and we first retrieve a sensortree for having the complete list of device + sensors.

This part works fine, but then, we need the values for each channel of each sensor, this can be achieved we an API call (content=channels) but this implies around 3 thousand API requests.

We notice high CPU and high response time when querying 60 sensors at once (php multi curl, these 60 last approx. 5 sec, ie 12 API requests/s)

IS this too much? is there a solution to get rid of this perf issue?

The full perf stuff need 10 minutes, but we'd like to go under 5 min.

Cheers,

Yannick

Article Comments

We have not implemented any API limitations in our code. The only limiting factor is the performance of your PRTG server (which is affected by the specific API function, the amount of data that you request and complexity of requested data).

Please keep in mind that overloading the core server by putting heavily multithreaded pressure (60 simultaneous complex API requests!) on the web server can significantly affect your monitoring results, you may even loose monitoring data which can't be written to disk due to performance problems. Keep an eye on this, this may need some testing.

So my recommendation is to use the biggest box (regarding CPU performance) that you have for your PRTG server and to try not to overload the system.


May, 2011 - Permalink

Hello,

I think I finally found why this process was so slow. After looking with process explorer, I found that it seems that PRTG launches a new thread for new TCP connections.

In my software, I didn't care much about how TCP connections were closed or not. And this is the error: each connection was closed immediately after API request.

I've rewritten the calls so that the software uses the same connections and it's a bit faster.

Can you confirm the thread creation for each connection?

edit: I changed some wrong thing I wrote.


Jun, 2012 - Permalink

Every new TCP connection to the webserver is a new thread (not a individual process). However, using a keep-alive you can use the same connection several times successively (just as a browser would do).


Jul, 2012 - Permalink