Below is general performance tuning guidance from Remedy support. We decided to increase the number of available thread on the fast and list thread based on high wait times on our AR and database servers. I conservative increase from three to six threads paid on considerably in our environment.
- Damon Thank you for contacting Remedy Technical Support! This is in response to your asking for feedback on your fast and list thread configuration, specifically in regards to your plan to increased minimum and maximum configuration. If you have determined that there is bottleneck on the ARServer from many long running API queries on list threads, your plan to increase to 3 minimum / 6 maximum is well within a reasonable increase. This is especially true for the increase for list threads. The goal for thread configuration is "enough but not too many". This is going to be different for every system and it is not possible to use a strict correlation between the number of users and the number of threads required to handle the load on the server. There are systems supporting 1500+ users very well with 4 minimum / 6 maximum fast and list threads. If you have four or more CPUs on the server, you may want to consider increasing your minimum thread configuration to 4 for both your fast and list threads. To determine what is "enough but not too many" for your system will require reviewing how well the current configuration is handling the load on the server. You want each thread working to its top capacity the majority of the time without creating a condition where API calls are queued up waiting for a thread to be available for it to be worked. A thread, specifically a fast thread which does UPDATE, INSERT, DELETE type actions, has the capacity for handling hundreds of API calls per minute. Reviewing an API log with output from 30 - 60 minutes worth of output during the heaviest part of the processing day will give you a general idea of how well the current thread configuration is handling the load on the server. The goal is to have minimum idle time for each thread where idle time is the time interval between the time a thread finishes one API call and starts another API call for a different user. If you are seeing a consistent pattern for excessive idle time (1+ minutes) on the threads, you probably have more than are required for the load on this server. If you are seeing a consistent pattern for very little idle time (x.00xx seconds or less) on the threads, there may be cause for (conservatively) increasing the number of threads. It is strongly recommended that you take performance benchmarks prior to increasing the threads, increase only by a few threads at a time and take performance benchmarks after increasing the threads. Comparing the benchmark performance times will give you objective evidence of whether increasing the threads was helpful. Please be aware that having too many threads has more often been a cause of performance issues than not enough threads. Your proposed increase is well within the bounds of a reasonable thread configuration, especially for a very busy server. Until you have benchmark evidence of a change in server performance, it is not possible to justify whether increase of the thread configuration will result in increased performance. If you note that the load on the list threads is exceptionally heavy, you may also want to consider creating a few private queues to be used by your users who use the system mostly for reporting type activities; i.e., searches in forms. The ARServer is an OLTF architecture by design and is extremely fast and handling standard INSERT, UPDATE, DELETE type transactions. If you have a large user base who access the system to get the data, rather than enter or update the data, having them work through private queues will leave the standard pool of threads available for the "normal" type operations. Please let me know if the above information is helpful to you. I will be happy to discuss it with you further. From the information you provided, the recommendation is that you proceed with your plan to increase the threads. This increase can be most objectively weighed for improvement in performance if you have some type of benchmarks prior to making the change to compare to similar benchmarks after the change is made. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Richard Baird Sent: Tuesday, August 01, 2006 8:43 AM To: [email protected] Subject: Tuning fast and list servers Hi folks, Does anyone have basic rules of thumb for tuning the fast and list servers. I understand the proper way to approach it is to turn on API logging and look for waiting api calls, but are there any other guidelines to follow without getting the api log info. As an aside, how much of a perf hit does API logging impart on the server? Haven't used it on a busy prod server before. Thanks for any comments/suggestions. Richard ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
