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?
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.
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?
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.
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.
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.
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.
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.
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.