We have our SD 4.5 (SP15) operational about three months, and the performance is getting slower and slower as the number of calls rise. There are now over 8000 calls in the database and when we try to open a view like "All closed calls" it could take a minute or more to open.
Server (Solaris) shows 3-5% load. Database seems ok. Client shows 100% load during loading of views.
I agree with Steven. We never give users the ability to open more than about 1000 service Calls. In fact often only 500. After all, what on earth are you going to do with 8000 records displayed! Just limit the number of records returned via Tools->System->Presentation-> Search (in V4.5). In V5 these limits are role based, but I can't recall if that came into later SP's in V4.5
Thanks for the benchmark tip. When I run the test during off-hours it shows values in the 'very fast' segment for all. I will try the test during peak hours later today.
About restricting the max entries, when I try to do that the message
'This view cannot show all items because the Query restriction of 1000 for service call is exceeded. To show all items, either refine your view filter, or ask your system administrator to increase the query restriction.'
That means only 1000 entries are shown but the user doesn't know if they are the oldest or newest ones and he cannot expand the search. This view is then without value to us.
Ashly: About UI/DB rules, how can I identify those that could be bad?
Hi Michael - unfortunately you can't control which 1000 records are returned - that's true (This capability is added either in either in V5.1 or maybe in a very late V4.5 Service Pack?). But the idea of the limit is to advise the user that there are too many records for his query (or view) and that he needs to think about his search more to refine it. For example he could look for closed calls of a certain category or closure code etc.
One way is to set up an Explorer View of (for example) Service Calls by Category, or by CLosure Code, or By Classification etc. so that the user can just select the subset he wants. But in the end, if searching closed calls, the user has to be trained to do specific searches. Otherwise in a few years time you could return 50 or 100,000 records!!!
I agree with Ken. Although it can be difficult, it's important to keep the number of records returned low, which means using views that efficiently find data for the customer and provide value daily.
Many people were using views in place of reports in our organization. An example of a view that could be replaced by a report is "All calls resolved by XXXX workgroup this month", which really isn't a metric that is measured daily but customers like seeing it. Although it doesn't seem like a major concern, most of these "summary" types of views take much longer to execute than ones that simply filter work assigned to a workgroup or person.
We encountered a bug in SD 4.5 views: performance drops considerably if the field "Registered" is included in the view. Use "Registration Created" instead, this reduces the time to display the view by 70-80%.
You should also take into account that if you use SD views for reporting purposes, the person viewing the views should have System administrator roles. This eliminates the checking of user's authorization for viewing each row.
I think that by "bad rules" one is referring to a rule that needlessly wastes processing time. This can be due principally to three things:
1) rules that refer to codes that have been disabled or deleted (yes, this can happen)
2) rules that run many times when you expect them to run once.
3) rules that fail to run correctly due to bugs in OVSD.
For 1), try exporting a view of the rules and search for unexpected text where a code value ought to be.
For 2), look in the list of pending rules executions to see if you have a lot of pending rules that you do not expect.
For 3), enable extended debugging of rules and check the server and the client logs for error messages associated with the execution of DB and UI rules. Also, check the list of known errors for OVSD on the support site.