How the perfomance of Service Desk's CMDB can be increased? I mean what fields should be present in forms, views so that minmum time is required to retrive data from CMDB(eg: If more than 10 drop down are present on a form then performance degrades. Some kind of checklist that can be followed while designing views, forms.
I've not noticed any performance problems when using various types of fields on a form in Service Desk. I would hazard a guess that using large fields on forms, such as 4,000 and 64,000 character fields, would have more impact that adding a 255 text to the same form item but I've not seen or experienced any problems with specific field types.
In views, it's more important to choose your fields carefully because there is a larger impact to the database. For example, when you open an item with a form that contains a 64,000 character field, the system only needs to retrieve the single 64,000 character field for the item you opened. If you include a field this large in a view and your view pulls 10000 records, you will be pulling this large field for 10000 items instead. For this reason, I would not use any field larger than 255 characters in a view (plus, you can never see all of the information in a large field through a view anyhow).
You should also be careful when making filter conditions on long fields for the same reasons. Whenever possible, use operators that are more absolute, such as "equals", instead of using operators like contains.
Thanks for the replies. What about joint views in case of database. A form can contain fields from different tables. If all the fields are from same table then less time will be required to retrive data. But if the fields are from different tables then more time will be required. Will this affect the performance of the server?
The CIs are the most "heavy" entity of Service Desk. It has greater number of custom fields than the other entities and also has numerous "set relations", like "cis on workorders", "parent cis", "child cis", "related cis", "ci users", "ci orgs" and "and "Used by these business services".
The views of this relation sets will slow the opening of form because too many tables (to be listed here) will be probed. So, avoid unless it is needed to use this views on the forms most often used.
Also, unless is realy needed avoid having the views of "changes", "incidents", "service calls", "problems" because each time the form is opened, the tables "itsm_problems", "itsm_changes", "itsm_servicecalls" and "itsm_incidents" (and depending on the view, probably other tables) will be probed.
Also, each time a code is presented on the form, a join to itsm_codes (and its related tables) or rep_codes (and its related tables) is required. So, the more codes you have on the form, the longer it will take to open it.
Also, providing that the LAN connection is decent there will be absolutely no problem with text fields (*), no matter their size. If the lan connection is slow, well text fields will slow down the connection.
(*) the exception to this rule is the 4K fields because each one of these resides on its own table so a left outer join is required for every 4K field presented on a form.