This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Crashing NPM With Rapid Fire Browser Requests

hpstech over 5 years ago

I have found that if I rapid fire open separate tabs by right clicking on multiple links one after the other within any NPM or SAM page, I can crash SolarWinds quite easily. And at the same time you're doing this, throw in a heavy AppInsight or multi-component SAM template test, and watch it melt.

The main symptom is the Results Notified Error counter goes haywire, and a reboot is needed.

This is concerning because we give clients access to the console. So if Johnny Clicker is bored or on crack and wants to open 50 Node summary pages by opening tabs, he will crash the active polling engine.

Our system runs fine, but throw a bunch of rapid fire browser based requests at it and it will bring down our main polling engine quickly. I really don't see any performance issues (RAM/CPU/DISK) coming from our AWServer to any PE that would cause this drama. Any thoughts out there?

Top Replies

bogdan.stan over 5 years ago in reply to hpstech +1

Do you have the same problem using the webconsole from the main orion server? If you are using an AWS there is like i said some small comunication with the pollers; check also the Infirmation service v3…

0 bogdan.stan over 5 years ago

Do you have AWS and the main web server in a load balancing? How many APE do you have? What Solarwins modules are you using?
What is happening in your enviroment makes no sens since opening a new webpage from an AWS dose not need communication with the APE unless you have somekind of custom widget that dose live polling.
If you only have the main poller then there is some small comunication from the AWS to the main pooler some times mostly for licence checking and building the top menu bar , but nothing that would crush the poller.
Cancel
Vote Up 0 Vote Down

Cancel
0 hpstech over 5 years ago in reply to bogdan.stan

1 MPE
1 HA Standby
1 AWS (no LB - just 1 front end AWS)
NPM, SAM, NTA, IPAM, HA
Its so easy to crash that its frightening.
Cancel
Vote Up 0 Vote Down

Cancel
0 hpstech over 5 years ago in reply to bogdan.stan

I tried to hammer the Orion Demo site and re-create it there but it was robust and happy to deliver all the open tabbed pages requests. That was good to see.
Would be great to figure out what can crash our's so easily but I know it might not be simple to pinpoint.
Cancel
Vote Up 0 Vote Down

Cancel
0 bogdan.stan over 5 years ago in reply to hpstech

Do you have the same problem using the webconsole from the main orion server?
If you are using an AWS there is like i said some small comunication with the pollers; check also the Infirmation service v3 resource usage on the main poller.
I tried yestarday to recreate your scenario but even opening multiple tabs untill the webserver crushed still it did not affect any APE.
At this point i recomand opening a ticket with support and provide them with a full diagnostic file. Try to open the ticket durin early Europe. Morning so you have better chance to get the Europe support team as they are the only ones that actually know what they are doing.
Cancel
Vote Up +1 Vote Down

Cancel
0 hpstech over 5 years ago in reply to bogdan.stan

Thanks for your comments.
I'm chasing an abundance of different Orion issues so in the meantime, i hope click happy people do not get really happy.
Cancel
Vote Up 0 Vote Down

Cancel