Terrible NPM website performance - am I the only one ?

The Website performance is directly related to the Disk Performance of the Database. 

Have you added a lot of extra resources to the Website?

Do you have a lot of users with no Website Timeout configured, or a lot of concurrent users on the Website?

What is the RAID Array configured on the SAN, and if there are any other Databases on the same array using the drives simultaneously? 

This guide should assist in assessing SQL Performance on the SQL Server.

SQL Performance tuning Guide:

The DB server uses a dedicated fiberchannel link to it's own LUN on our SAN (which is in no way heavy loaded and not servicing any other db servers) I'm certain that we have no issues with performance here.

We have about 5 charts in each 'view' - I assume this is pretty normal - It's only the charts that are genrated slowly everything else is displayed instantaneously. 

The Log files however are located on the DB servers local RAID5 disk array though (4x 10k RPM drives).

We're logging users out after 30 minuttes of inactivity and automatic page refreshing has been completely disabled.

Can you try perform some similar report in Orion Report Writer? So we know that issue is related to DB or WebSite?

We found a big improvement in performance by defragmenting the indexes in the database.

For some strange reason the performance is amazing 24 hours after upgrading to 10.2 - during the first 10 hours after the upgrade the installation was unusable.

I think the update to v10.2 helped us.  I've done the following tasks, along with the .pdf referenced earlier (which, btw, has some good points about SQL performance counters):

• Defragment all drives (SQL data, web site, SQL log file locations); I use Defraggler for this.
• Reindex of ALL tables, not just the ones which are defragmened; I have a couple of nice T-SQL queries for this.
• Shrink the Orion database.

And what about try to backup database and remove from page lot of other resources and try to let there some chart resources. It maybe help to find which resource cause performance issue.

Or first remove from view all chart resource, try to refresh and check how quick refresh was and gradually start adding one chart from set of chart you first remove and again measure time to refresh page. It can also help to identify whether it is caused chart resource and if it is chart so identify which exactly it is.

Hi uscallesen,

from the top of my head - upgrade to NPM 10.2 invokes upgrade of Syslogs table (optimizing indexes, changing structure). We did our best to make this transparent to end-users, but in case there are dozens of millions rows in Syslog table that could temporarily decrease  DB performance right after upgrade.

Can you please check how many rows you have in Syslog tables? Despite I haven't heard this from other folks, potentially this could be the reason.

thanks