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

Service Desk Performance

Highlighted
Jason Langer_1
Occasional Advisor

Service Desk Performance

Hi All,

I have been tasked with administrating or company's SD implemenation and one of the 1st order of business is to address performance issues we are experiencing. From what I understand we have been using the app for roughly 1 year and it does not seem any maintenance has been done on the product. Can some one recommend some "general" health checks one should be doing to keep SD up and running and happy? I have been reviewing the documentation on Archiving, is this something that should be done?

Thanks in advance,

-Jason
12 REPLIES
Robert S. Falko
Honored Contributor

Re: Service Desk Performance

Jason,

I would start with identifying exactly what you find to be too slow, as this may be due to many different things.

If you find that your views are displayed too slowly, and if your business process allows for it, then you might want to archive data. Otherwise, I doubt that archiving will have a significant impact on other performance issues.

From time to time, Service Packs release fixes to certain performance problems. Check the support site for your specific problem to see if a fix exists.

There are a few configuration options that might have an impact of performance.

Otherwise, I would ask your DBAs to evaluate the possible interest of recreating some indexes, although unless you have a huge and highly volatile organization, I am not sure this would make much difference.

-Josh
Mark O'Loughlin
Honored Contributor

Re: Service Desk Performance

Hi Jason,

2 quick things to do at this point.

1) Check the size of the serverlog.txt file. This does not trim/roll by default and has to be manually cut down in size. Having a large serverlog.txt file may slow the system down

2) Check if you are using the default memory settings which are not optimal for servers with a good reserve or ram.

have a look at the attached file ref the memory settings.
Mark O'Loughlin
Honored Contributor

Re: Service Desk Performance

and the file.
David R Baldwin
Regular Collector

Re: Service Desk Performance

We had some issues with speed for remote users (i.e. US and Australia). Looking at the hardware, I would check that you have a good network speed and we also looked at the RAID settings on the server.

We are also looking at putting in distributed servers into the remote sites to try and speed things up.
Henrik Brattlie
Acclaimed Contributor

Re: Service Desk Performance

Can you elaborate a bit on the first point please? How large a serverlog.txt file is a too large serverlog.txt file? (We are currently at slightly less than 3MB.) How do trim it? Just rename it and create a new one?
Mark O'Loughlin
Honored Contributor

Re: Service Desk Performance

Hi,

3MB is fine. I would aim to keep it below 20mb if that is possible, defintly below 50mb. To rename it you need to stop the application server which is a pain. You could script it so that a service is stopped and the logs rolled automatically which would keep them at an acceptable level.
Robert S. Falko
Honored Contributor

Re: Service Desk Performance

Regarding the question of remote servers, I think the connection speed between the application server and the database is much more important than the speed between the application server and the client.

-Josh
Jason Langer_1
Occasional Advisor

Re: Service Desk Performance

All,

Thanks for the responses. In an effort to clarify the issues. The main source of user contention is during the startup of the applictation. I have seen it take upwards of 3 minutes for the app to intialize and I am only a few feet from the app servers. Also when clicking on "Advanced Find" the app can go "Non-responsive" for 2 minutes before actually opening the dialog box.

Mark - I checked each of the 2 app servers for a serverlog.txt file but neither had one, is this a potential issue? Also I have configured the JVM per the doc prior and still have been having issues.

Thanks for the help,

-Jason
Robert S. Falko
Honored Contributor

Re: Service Desk Performance

Jason,

Very poor performance during opening may have something to do with the caching of forms. We found that when there is a large number of code values which determine which subform to use, then we have poor performance. You can either put the poor performance at startup time, by caching the forms, or at open form time, by not caching the forms. The only way to improve performance is to reduce the size of the list of options (defined in the generic relations) for opening the forms. To my knowledge, this is poor performance due to poor programming, and is not due to poor maintenance of OVSD by its administrator.

Of course, if you do not use subforms, then this issue is unrelated to your problem.

-Josh
Jason Langer_1
Occasional Advisor

Re: Service Desk Performance

Josh,

Thank you for the quick reply. As a new admin to SD, how would I verify if I am using "subforms"?

-Jason
Robert S. Falko
Honored Contributor

Re: Service Desk Performance

Jason,

First of all, subforms are available in ver 4.5 only from Service Pack 18 on.

Secondly, when you define a form in the admin console, you will see the option to make a form a subform, or not.

Thirdly, and this is the key to the performance issue, check in generic relations (again, only from Service Pack 17 and later) for a relationship between a value (typically, the code field category) and forms. If you have such a relation and if the list of matched values in that generic relation is long, then this might create a performance problem.

-Josh.
Ken Briscoe
Honored Contributor

Re: Service Desk Performance

A long shot about the slow startup. I'm no network guy, but we had this problem where the client could address the application server by IP address, but not ny name...ie a DNS issue. But HPSD, once it connects to an app server, then tries to connect in future via the server name...until in our case it timed out and regressed to using the IP address. This would show in the client log as a timeout of the server by its name, even thought the user accoutn setting had the server specified as an IP address.
Test this by pinging the app server by name from the client....in our case, this failed but the ping of IP address worked.
I hope that makes sense....and may be totally irrelevant in your case, but once fixed with us, the startup time reduced dramatically.
In any case, worth looking in the client HPSD log to see what happens at startup.
My email is kenilian@bigpond.com.au
//Add this to "OnDomLoad" event