Memory adjustments

User can select, what should be the min and max memory (RAM) to be used by the SD Server.  Open the sd_server.bat or installservice.bat.  Then search for –Xms{a digit}  This is the digit for Min memory and next will be –Xmx{a digit}  and this is the max memory.
 
What I would recomed is to keep 30 % of the RAM for the OS and others, the dedicated the rest of the memory for SD server.  In a server with 2 GB RAM, I have configured as below and it is working great!
 
-Xms1024M -Xmx1536M
 

Scheduled tasks

If the number of scheduled tasks are more, the SD’s performance will be poor. Run the below query in the DB, to know what are the number of tasks, which gets loaded to RAM, when you start the server. (note : this is an SQL query)

select JAV_OID, JAV_ENTITY, LEFT(JAV_INSTANCE,30) as SEARCHCODE from rep_javaobjects
where jav_entity = (
select ent_oid
from ifc_entities
where ent_name = 'Scheduled Tasks' )

Then if the numbers are too high, delete them by running the below SQL query

  delete from rep_javaobjects
  where jav_entity = (select ent_oid
  from ifc_entities
  where ent_name = ' Scheduled Tasks')

Please note that this will erase all the scheduled task, which are created by DB and UI rules in SD.
 

Identify the culprit

Go to the command prompt, and the location where SD Client is installed.

ie: c:\Program Files\Hewlett-Packard\OpenView\service desk 4.5\client\bin

Then, give the command sd_client /benchmark.

This will give you a better insight on what is causing the slowness.  Whether it is the DB, Server, network or the client.  Then you can focus on that component.

Even though if you get the readings in good figurers, using the tips and tricks mentioned on this page will further boost the performance.

DB Rules

Try to reduce maximum number of actions in DB Rules.  Reduce the number of conduction checking.  If you can introduce one more custom filed, which are reduce the number of condition checking, just do that.

DNS

Make sure that the server name to IP and IP to server name resolution is happing form all the clients.

Data Exchange and DB

Fields that are used as primary keys in D.E. tasks should ALWAYS be indexed at the db level. Searchcode is, but source id isn't!

Sometimes multiple indexes are required: For example Source ID in one index and Source ID and OID in another index.

Forms

Use only the most required fields in the forms.  Reduce the number of tabs too

Entity reference and entity reference set type

Avoide having too many fields of entity reference and entity reference set type in the most used forms.

Examples of entity reference set: Service Calls, Changes, Incidents, Problems, Work orders on Configuration Items, Child Organizations in ORGS etc.

Entity reference fields are Codes (custom or built-in), persons, workgroups etc.

Index the DB, use multiple index if needed.

For items with very large volume of entries, besides setting query limits through Presentation/Search, fields most commonly used as criteria in search/view filters should be indexed at the db level. Multiple indexes may be needed.

For example, We have about 2500000 configuration items and 600000 persons. An advanced find using a non indexed field as filter may take as long as several minutes to be completed. Indexing together fields that are used in filters reduce search/time to present a view to seconds.

Views

For items with large volume of entries, avoid presenting too many entity reference fields in the views. Not only the views on client but the views that are "embedded" in forms for entity set relations (example CI users, Used services etc).

Do not use custom fields as primary keys for Data Exchange

For items with large volume of entries do not use custom fields as primary keys for Data Exchange tasks. Use "searchcode", "source-id" or even id if possible

Make the views smarter

In heavy views avoid having calculated fields (like remaining duration)