This section gives general advice on how to configure Service Desk to optimize its performance. Ivanti Console configuration advice gives information additional to this section, regarding optimizing the performance of the console only. The advice in the General configuration advice section will also improve the performance of the console.
If you are getting a lot of deadlock error messages on your system, first consider rebuilding indexes and updating statistics on the database (see Database maintenance planning).
If this does not help, and you are using Microsoft SQL Server, check whether or not Snapshot Isolation is enabled on your Service Desk database, and if it is not, consider enabling it.
By default on databases created in 7.8 or later, this should be enabled, but on databases created in prior versions this might be disabled.
For more information, see the following community article:
For more information about Snapshot Isolation, see Microsoft's documentation:
If you use the Process Workload business object to generate your Workload List, each time a process or process assignment is created or modified, or users or groups are modified within the Administration component, data is immediately entered into the database. If you do not use the Process Workload business object as the basis for your Workload list, you can disable this action, which will mean that processes are logged and updated more quickly. To do this, you modify the tps.config file.
Add the line:
<add key="PopulateProcessWorkload" value="False" />
See also the following article on the community: http://community.ivanti.com/support/docs/DOC-6463.
If you have a large number of users or a high volume of data being entered, creating more than one copy of the Service Desk Framework web application to point to your database could improve performance. This is because all database traffic (except for Web Access and reports that you run outside of Service Desk) goes through the Service Desk Framework. For information on how to create more than one copy of the Service Desk Framework using the Ivanti Configuration Center, see Creating the Web Applications.
We recommend that you create an instance of the Service Desk Framework on the same server as your services (that is, on the Application Services server) and that the services (Mail Manager, Data Import, and so on) use this instance of the Framework. Instances of the Framework on the Web server will then be used exclusively by Service Desk users.
To see if creating multiple instances of the Framework improves performance, point just one of the Service Desk users (preferably one who uses the software heavily) to a copy of the Framework just for their use. If after a few days of monitoring they have seen an improvement, implementing multiple instances of the Framework could improve system performance significantly.
If you are sharing a web server with other web sites or applications, we recommend that you create a separate application pool for Service Desk called Ivanti Applications and move each Service Desk web application into this pool. We also recommend that you create a separate application pool for Web Access.
In addition you could further separate each of your Ivanti web applications into separate application pools and then ensure that each Ivanti application uses a different one. This will allow multiple dedicated worker processes and should help performance.
For more information on IIS, see the Microsoft IIS website: http://www.iis.net
You can switch off the options to re-cycle application pools in IIS, or set these to recycle out of hours or during a period of reduced activity. Re-cycling an application pool is effectively the same as restarting the application, which then disconnects everyone and so reduces performance while the cache is refreshed. However, this can clear memory that has been taken up by the worker process.
You can configure the Ivanti Application Server engines to log different levels of event messages. Make sure that these are all set to log either Error or Critical. If they are set to Information or Trace for more than a short period of testing, the Application Log will quickly fill.
For more information about configuring the log severity for the Ivanti Application Server engines, see Application Services server engine settings.
Logging IIS activity is disk intensive. By default, IIS logs all web activity to each website or web application. This is not usually required, so you can consider disabling this within IIS.
Inbound Mail Manager reads through all of the e-mails in the inbound mailboxes each time it polls, so we recommend that you regularly move or archive read e-mails in these mailboxes. Consult with your Mail Administrator on setting this on your Mail server.
Outbound Mail Manager creates entries in the tables tps_user_message and tps_user_message_recipient. These tables can fill quickly and so cause performance problems. A stored procedure is available from Ivanti that archives these entries to a different table. We recommend that if you use Mail Manager regularly, you schedule this stored procedure to run regularly.
Also refer to the following community article:
MS SQL: http://community.ivanti.com/support/docs/DOC-4949
Make sure that Service Desk Framework message logging is not set to all messages (for example information level) and left on, as this can affect performance. Error logging level can be left on permanently as this logs errors only when there are errors and so should not affect performance.
You set the TraceLevel for Service Desk Framework message logging on the Service Desk Web server in the file C:\ProgramData\LANDesk\ServiceDesk\servicedesk.Framework\tps.config.
We recommend that a regular backup and maintenance plan is in operation against the Service Desk database.
The implementation of such plans is the responsibility of the customer’s Database Administrator.
Regular re-indexing of tables or defragmenting of indexes helps to optimize database performance. Also, monitor database statistics (especially after large data imports). We recommend that DBAs review index fragmentation in the database and if necessary rebuild.
Microsoft SQL Server provides a standard maintenance plan to rebuild indexes on a database. We recommend that you schedule this to run on a weekly basis.
Microsoft SQL Server provides a stored procedure called sp_updatestatsistics that updates information about the distribution of key values in the database. We recommend that you run this stored procedure after importing data. Consider scheduling this stored procedure to run every overnight.
Indexing a database can significantly improve performance by providing faster searching. However, take care with indexing, because it can affect data writing and deleting because the indexes also need to be updated. Indexing also makes the database larger. We recommend that you use this only after all other performance options have been explored.
Microsoft SQL Server provides tools that enable you to identify and implement database indexes that will optimize the performance of procedures that are perceived to be slow.
On a test copy of the system, time the procedures, add the indexes using the procedure below, and then time the same procedures again.
If there are no recommendations, then the performance issue isn't likely to do with the database itself.
This script can be run on a copy of your database and will create the necessary indexes.
The script may need to be edited. At the top of the script will be: USE <databasename> GO <databasename>. This either needs to be corrected to show your database name as it is on site, or the whole "Use, Go" statement can be deleted if you make sure you are running the script on the correct database.
These tools can sometimes advise to remove indexes. Do not remove any existing indexes from the database.
If you have applied statistics to your Service Desk database (possibly recommended by the Database Engine Tuning Advisor), you may encounter problems when modifying attributes using Object Designer. Some changes to an attribute require the database to drop and recreate a database column, which is prevented when statistics are present.
You can overcome this issue by dropping the statistics from the database, making the change in Object Designer, then reapplying the statistics.
A number of customers have started using ESX server, which can improve performance because:
Areas that have been seen to affect performance on an ESX Server environment usually come down to how the server or guest operating system has been configured, or the ESX server id being under-specified to run the number of guest operating systems. For example:
Check with VMWare for their recommendations on configuring virtual machines for best performance.
This section is equally valid if you run reports in the Service Desk Crystal Reports component or directly against your database.
Running reports that return a large number of rows from the larger tables within your database can temporarily lower the performance of Service Desk for all users, especially if the reports include large text fields.
Ideas to reduce these effects:
Service Desk enables you to e-mail the results of queries to one or more people. For queries containing no prompts this works fine, but if you e-mail the results of a prompted query, the query is executed and ALL data is returned ignoring the prompted criteria. We recommend that you do not e-mail prompted queries as this can cause very noticeable drops in performance on a live system.
Copyright © 2019, Ivanti. All rights reserved.