Mix/Max/Avarage bps Chart too slow

Hello

I have a problem about slowness on NPM graphs.

I am using "Mix/Max/Avarage bps" graphs for interfaces on NPM. I am using chrome or explorer for solarwinds.

When I want to show 1 day data, it waits 1 munute at least. But sometimes it takes just a few seconds. I think when it want to create a png for graph it takes lots of time.

I investigate on browser about the delay for the graph and chart png takes 1.2 min !

Is it about my custom chart type? And what wolud you suggest for min max avarage bps graphs most effective using solarwinds?

Browser network console png result:

Here my graph:

Thanks

Find more posts tagged with

npm web page slow

avg_minmax

npm monitoring

npm 12.2

Accepted answers

All comments

mesverrum

You'll probably need to investigate your database, in the environment I'm in now that kind of chart with the same level of detail renders in less than 4 seconds.

The main factors being the number of interfaces you have, how often you poll them for stats, how long do you retain the data (this all factors into how many rows the db has to sort through) and then how quickly your database is able to supply info, so does it have enough RAM? Do you have a low cache hit ratio? Does it have fast enough disks? Is there something weird causing tables to lock?

desscartes

Thanks for answer,

Actually I investigate SW database and took diags, it looks fine . All hardware (Ram CPU Disk ) controlled and all of them upgraded.. For the tables we write a script for fragmantation and control lock. We poll 27K interfaces and poll them every 1 minute. We retain raw data for 45 days.

But the problem do not repeat all the time. Sometimes the chart comes too fast. But sometimes it takes a long time.

mesverrum

1 minute intervals is pretty high frequency (default is 9 minutes for interface stats) so I'm not shocked that the tables are large, I would expect that the times where it comes back quickly are when the data you need is still freshly cached either in IIS or on the SQL side in memory and not on disk from other things that had been displayed in the UI. It should never take a minute to load a 24 hour chart when everything is going well, but on the other hand at that high of a polling interval you are having to parse 38 million records every time you want to pull a 24 hour chart so your read speeds need to be pretty snappy, plus having a healthy chunk of ram on the primary application and web server. You might try using the Huble tool to get a bit more visibility into how much of the wait time is web frontend issues versus database delays

Turn on and use Hubble - SolarWinds Worldwide, LLC. Help and Support