My navegation is to slow how to improve a best performance
are you asking about how to navigate things better? then you could watch: [VIDEO] SolarWinds Lab #29: Orion Cribs - View, User, and Resource Customization or if that link doesn't work Orion Cribs - View, User, and Resource Customization - SolarWinds Lab #29 - YouTube
There are also probably a bunch of posts around about specific customization on thwack too if you look around
If you're talking about the server being kinda slow, take a look at how many devices you are polling and your hardware specs, I had to upgrade ours recently b/c it started running a little slow with our 10,000 monitored elements
Just curious what version are you running of NPM? I've previously applied one of the newer hot fixes recently (Hot fix 3) that addresses a few things, one of which is- Improved the page load time on the Web Console.
I see now that Hot Fix 4 is out, and that encompasses all of the previous hot fixes, may be worth your investigation if you haven't already applied them.
You could also enable "hubble" and that may help you identify what is slow on your webpages. To enable Hubble run the "logadjuster" (<installdir>\solarwinds\orion) and then enable Hubble. You can try it in verbose mode also.
aside from the other suggestions whenver I've found the webUI slow it has been because the database is currently being locked up by some process (normally UDT cleaning up something)
Don't forget most folks don't use IE to access Orion. Chrome is the most popular, followed by Firefox. Both are MUCH faster and reliable than IE for accessing Orion.
I had similar experiences once I reached 10,000 elements per poller with NPM two versions back. Ended up having to poll less frequently, which helped performance, but degraded statistics.
In one version back I started seeing NPM auto-adjusting polling to complete 100% each cycle on its own--a handy feature, but unexpected.
Now on the latest version I'm seeing no issues with polling completion, and have 40,000 elements to poll without any slowness so far.
Try to use the Navigation Tabs . This will reduce the amount of load on single page to load .
Reduce the amount of Resources added on single tab
Only Add "Resources" which you really need to load on the First Tab
Do not use High resolution MAP background Even not to use any
page will load extremely quick
Move extra load to other tabs you do not need to view on summary page .
move the resources to each Tab / Add more tabs if needed Do not over load single Tab
When using any Resources try to use the Less Hours / or less amount say Last 10 Events / Last Hour
Use Top XX Type of Resources and Try to use less amount to load such as 10 / 5 Top
Try not to use more then 2 Column unless you really need to do that and do not overload with Resources.
you're running 40k elements on 1 polling engine? and what are your server's specs?
That might not be on single poller so i think he mentioned all together on APE's .
Sorry if I made it sound like 40K elements were on one poller; there are four pollers, each with "unlimited" (a.k.al SLX or 10,000-element) licenses. I find it funny they call 10,000 "unlimited", but hey--it's Marketing!
However, prior to going that route, I had some slowness history at earlier versions of NPM which resolved by themselves when we upgraded to newer versions. Those newer versions were working perfectly acceptably at 13,000 elements on one poller. That's a huge improvement over our first NPM deployment that couldn't even handle 8,000 elements.
Some things I've done:
- Remove as much data as you can on pages people use (by doing the things GoldTipu (Malik) mentioned above)
- I had some issues where I tried to make some views that, behind the scenes, were making a *lot* of queries to determine what access to what devices a user had ( think lots of account limitations that were based on groups that were "dynamic" groups). Some people had access to ~500+ devices so it would take awhile to determine what they had access to so some resources would load slowly ( about 30-60 sec for a single resource to complete). I fixed this by using custom properties on their devices and then adding a single account limitation for those properties.
- I've had issues with Orion slowly crawling to a point where it will start having issues. There are many causes/remedies, but I'd open a support ticket and have them take a crack at it just to see what they find. I've had them fix some things I was not aware of. It still occurs occasionally.
- If you have SNMP traps/syslog going to Orion, check that you are not being flooded by traps/syslogs.. I've had this causes system slowness as it's much slower than "normal" when this occurs.
- if you can, extend the default polling time(s) ("ping", system statistics collection, discovery, etc.) of your devices to be as long as you can get away with to lessen the overall load on teh system. Some people aren't comfortable pinging every device less than once per minute, others don't care if it's once every 5 minutes.
- Some IIS changes you may want to consider:
http://thwack.solarwinds.com/message/73137#73137
http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx
I set my system to:
- IIS config: Recycling worker processes tuning
Process: Application Pool -> Recycling: Set from once every 1740 minutes to recycle @ 5:00 PM
- Set to write event to event log
- IIS config Set idle time out to 0 from default of 20
Process: App pool -> Advanced Settings -> Idle time out.
- Orion Console -> Web Settings: Set page refresh to 30 min, from 5.
- Orion Console -> Web Settings: Set session timeout to 120 min, from 25
For reference, how slow is your system? Is it just a single page or certain pages? I ran some tests on my Orion environment in the past and the response times I have (averages, timed using the built in Firefox browser development tools) are:
1. Load login page: 0.39 - 0.96 sec.
2. Login: ~4.3 sec
3.Search for the Orion app server: 3 - 3.5 sec
4. View the Orion server: 6.13 - 6.36 sec
5. Logout: 3 requests: 0.2 - 0.3 sec
Where I'm at it's considered "responsive enough". I have 6369 "elements" on a single poller/app server on NPM 11.0.1 (with SAM, NCM, IPAM, UDT) but I'm not running the system very hard:
Polling Rate: 29%
SAM Application Polling Rate: 21%
The other pollers are at 0%
Database is on a separate server, but before it was moved off the response times were essentially the same,
I'd also recommend that you upgrade to Orion 2015.1 and the latest/greatest version of any modules that you have installed. We noticed better performance post-upgrade without any sort of specific tuning.
If to exclude nr of element per Polling Engine then I'd suggest to consider server and array possible issues. I have experienced performance problems with recent NPM, NCM, NTA, IPAM, UDT and Toolset versions iinstalled on Orion server, FSDB server and MSSQL server. Number of nodes were above 300 and interfaces below 2000 so it was not possible to have so slow performance because of high nr of elements. Even running website from Orion server itself via Remote Desktop gave teens of seconds delay. All 3 servers are virtual running (with 2 others) on the same hardware host. First suspect was RAID issues (it is 6 DP), then IIS and situation that it is the same host for SQL and Orion servers which is not recommended. There was not any antivirus software.
The root cause was that array and host were connected via different VLANs even on the same switch. When it got corrected and additionally MTU increased from default 1500 to 9000 on virtual servers as well as on the host the problem got solved.
I'm configuring now another instance of Orion for 8 modules (recent versions) together on virtual server which runs in another subnet than SQL server. It may cause problems with performance as well as Symantec AntiVirus. When run SW diags - Antivirus and Collation were listed on "yellow" as potential cause of problems. But Collation has nothing to do in that case, I think. My suspect is communications between subnets (Orion to/from SQL) especially if it goes through firewall.
If array is physically connected to another switch than host for SQL then it may dramatically decrease performance. I'm working with network team on that but cooperation of servers' team was requested to solve the issue.
In both cases there were nothing to tune up on IIS.
What version?
Regards
Version no matters. I use newest and it is not any solution.
The current version as of September 2015.
- As performance can be effected due to any bottleneck therefor its needs some investigation on each environment
- FULL Diagnostic needs to review in order to determine the root cause of the issue - for that you must open Support Ticket so we can guide you exactly what to check -
- Orion have tool called DB Response that can give you a quick summary from the DB response -
SWDBMaintenance.log can also gives you an outline how much time its taking to complete and if there is any issue within the tables .
Again its recommended to consult with support to check your environment if you have any performance issues.
From the web part just don't overload the pages unnecessarily .
I run all SW diagnostics available (SolarWinds.Diagnostics.DBResponse.exe and SolarWinds.Diagnostics.exe) and Permission checker. They gave me no answer why I have poor performance. So my suspect is still array connectivity, MS SQL server located on another subnet and physical connection via switches/firewalls etc. on standard poor MTU=1500 except 9000 on direct fiber link as should be.
It sounds like it's time to install the NPM QOE client on your NPM server and on the SQL server hosting your database.
Your physical links should all be clean--no errors. If you've got a speed/duplex mismatch on any of them, you're wasting cycles in retransmits due to collisions.
Verify L1 is perfect, then move on to confirming L2 is good. L3 has to be OK or you couldn't traverse the subnets at all, but make sure your path is perfect. You know the drill--utilize the OSI model to troubleshoot until you find and correct the problem.
QOE can make some upper layer issues jump right out at you in red, thus saving you a lot of time troubleshooting areas with which you may have limited access or expertise.
