1. Database Indexes - Fragmented database indexes tend to be the most common cause of performance issues. We recommend setting up a weekly SQL Server job to run the one of the SQLs found in this KB article.
     
  2. Database File Fragmentation - Sometimes the MDF/LDF databases files get fragmented which can hinder performance, especially if the database has recently grown in size or the system was recently upgraded from one version of Spira to another:
    1. Check the hard drive that the MDF/LDF files are stored on and make sure that the drive is healthy and in the case of RAID arrays, make sure that there are no failures reported by the RAID controller.
    2. Size the MDF file to be at least 20% larger than the current size so that it has room to grow. Make sure that the MDF has an Auto-Grow size set to at least 20% of the current database MDF file size.
    3. Size the LDF to be at least 20% of the MDF and ideally pre-size it to be twice the largest size it has ever previously been. Also set the Auto-Grow to be at least 20% of its current size.
    4. Detach the database and perform a file-level defragmentation of the MDF and LDF files (e.g. use the SYSINTERNALS contig.exe application). Then reattach the database.
       
  3. Database Transaction Log - Unless you have a dedicated SQL Server DBA, we recommend using the "Simple" recovery model and then do a scheduled full backup of the database every evening into the SQL Server .BAK file format. Not only does this make sure you have a reliable backup in place, it will also make sure that your transaction does not grow uncontrollably, which will degrade performance.
    If you don't use Simple recovery mode, or do not create backups often, be sure to Shrink the log file to reduce the size of Database transaction log:
    a. Right Click on Database ->Tasks ->Shrink -> Files
    b. On the Shrink File window, change the File Type to Log
    c. Click OK
     
  4. Database Auto Close - Make sure that this setting inside SQL Server is set to FALSE. The default is often set to true, but Microsoft recommends all production databases should have it set to FALSE. To do this, make sure that the model database has this set to FALSE.
     
  5. Upgrade SQL version  - if you use SQL Server Express edition, that may significantly affect the application performance, since it has a number of limitations: Limiting resources to 1 CPU and 1 GB of RAM, and database file limits of 10Gb.
     
  6. Antivirus Software - Make sure that your antivirus software on both the web server and database server excludes the folders in use by the system. For web servers that would be the C:\Program Files\SpiraXXXX folder and the C:\Windows\Microsoft.NET folders. For database servers that would be the location of the Spira/KronoDesk MDF/LDF files as well as the master MDF/LDF files.
     
  7. Web Browsers - Performance will be suboptimal with older browsers such as IE7/8. We recommend using the latest versions of IE, Firefox, Chrome, Safari or Opera.
     
  8. Adware/Spyware - Have your users check to make sure that they don't have any web browser extensions installed that contain adware/spyware that will interfere with the application, sadly this is becoming an all-too common cause of issues. Try running the browser in "safe" mode with non extensions running to see if it makes a difference.
     
  9. Firewalls/Proxies - Sometimes appliances/devices on your network such as firewalls or proxy servers can intercept the AJAX web traffic between our application and the server. You can use the Net tab of most modern browsers' development tools (e.g. Firebug in Firefox) to view the requests. If you see certain requests being delayed, then a device on your network could be the cause.
     
  10. Network Latency - The speed of the network between the web browser and the server will have a large impact on performance. We recommend first using traceroute to see the general path that web requests are taking and then use the web browsers' Net tab to see how long web requests are individually taking. One option for slower networks would be to turn on IIS compression for static and dynamic content.
     
  11. Virtual Machines (VMs) - Whilst we do use VMs at Inflectra, and they are 100% supported, we have found for maximum IIS and database performance that physical machines are better. So if you are using VMs and items 1-8 haven't helped, please try installing the application on a physical machine to see if that improves things. If you are using a VM, make sure that the underlying physical machine is sufficiently powered and that the VM has been granted sufficient resources (RAM, # CPUs, #cores, etc.)
     
  12. Event Log. After performing the steps 1-3, make sure you delete all the entries in the Event Log tables (TST_EVENT in Spira and KRN_EVENT in KronoDesk). Having large numbers of old events can degrade performance after you've done database optimizations.

    The command for doing this for Spira is as follows:
    USE [Database Name]
TRUNCATE TABLE [TST_EVENT]
GO


    For KronoDesk, the corresponding command is:

    USE [Database Name]
TRUNCATE TABLE [KRN_EVENT]
GO