Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

CMDB Optimization

SOLVED
Go to solution
Highlighted
Amol Badge
Occasional Advisor

CMDB Optimization

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.

Regards,
Amol
5 REPLIES
Tim Schmitt_4
Frequent Visitor

Re: CMDB Optimization

Hi Amol.

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.

Tim
Michel SILVA SO
Occasional Visitor

Re: CMDB Optimization

Hello Amol,

We have experienced that removing the field "Creation date" from the views increase display perfomance.

Hope this helps,
Rgds,
Michel
Amol Badge
Occasional Advisor

Re: CMDB Optimization

Hi All,

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?

Thanks & Regards,
Amol.
Michel SILVA SO
Occasional Visitor

Re: CMDB Optimization

Hi Amol,
For the join Views the performance will not necessary decrease. I think HPOVSD manage pretty well the tables indexes. But your DBA can have a look and benchmark the different tables.

We wanted to check this and ask DBA to create indexes if necessary to increase performance. But this has not been made yet.

Hope this helps,
Rgds,
Michel

George M. Meneg
Honored Contributor
Solution

Re: CMDB Optimization

Hello Amol,

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.
menes fhtagn
//Add this to "OnDomLoad" event