December 1998 Part Number: AR-400-AGV2-01.PDF

Transcription

1 December 1998 Part Number: AR-400-AGV2-01.PDF

2 by Remedy Corporation. All rights reserved. This documentation may not be copied in whole or in part without the prior written consent of Remedy Corporation. Remedy, the Remedy Corporation logo, Action Request System, AR System, ARWeb, Flashboards, and Remedy Powered are registered trademarks or other trademarks of Remedy Corporation. Apple and Macintosh are registered trademarks of Apple Computer, Inc. HP and HP-UX are trademarks of Hewlett-Packard Company. AIX is a trademark of International Business Machines Corporation. INFORMIX is a registered trademark of Informix Software, Inc. Microsoft, MS, and MS-DOS are registered trademarks, and Windows, Windows NT, and Internet Explorer are trademarks of Microsoft Corporation. Motif, OSF, and OSF/Motif are trademarks of the Open Software Foundation, Inc. NCR is a registered trademark of NCR Corporation. Netscape Communications, Netscape, Netscape Navigator, Netscape Navigator Gold, Netscape Communicator, and the Netscape Communications logo are trademarks or registered trademarks of Netscape Communications Corporation. Oracle and SQL*Plus are registered trademarks, and Oracle8 is a trademark of Oracle Corporation. Silicon Graphics and IRIS are registered trademarks, and IRIX is a trademark of Silicon Graphics, Inc. Sun Microsystems, NFS, and PC-NFS are registered trademarks of Sun Microsystems, Inc. Solaris is a trademark of Sun Microsystems, Inc. SPARCstation is a trademark of SPARC International, Inc., licensed exclusively to Sun Microsystems, Inc. Sybase is a registered trademark of Sybase, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd. Verity and TOPIC are registered trademarks of Verity, Inc. All other products mentioned in this document are protected by the trademarks or service marks of their respective companies or organizations. U.S. GOVERNMENT RIGHTS. Use, duplication, or disclosure by the Government is subject to Remedy Corporation s commercial software license(s). If you are the U.S. government, you agree that these written materials are commercial computer software -related documentation licensed pursuant to the terms of Remedy Corporation s commercial computer software license(s) in accordance with 48 C.F.R of the Federal Acquisition Regulations and its successors and 48 C.F.R of the DoD FAR Supplement and its successors. Unpublished rights are reserved under the copyright laws of the United States. Part Number: AR-400-AGV2-01.PDF

3 Table of Contents Preface... xv Audience...xv Overview of This Document...xv Related Remedy Documents...xvii Conventions Used in This Document...xix Chapter 1 Performance Issues Gathering Performance Information Using Flashboards to Gather Baseline Data Using AR System Log Files to Gather Baseline Data Common Performance Tuning Tips Check Query-by-Example (QBE) Match Qualify Searches Avoid NOT Operations in Searches Avoid Macros in Run Process Actions Check Escalation Frequency Build Obvious Indexes Optimize the Number of Indexes Use the Server for Set Fields Operations Avoid Sending Notifications to Groups Minimize the Use of Diary and Unlimited Text Fields Performance Improvement Areas Hardware Operating System Database Shared Cache Network Other Applications User Actions iii

4 AR System Components Indexes Multi-Processing Server Configuration Notification System Configuration Archiving Data Environment-Specific Issues Database Administrator Extensions Chapter 2 Log Files Installation Logs ar_install.log (UNIX) arinstall.log (Windows NT) arerrorlog Server Error Log arserverd Trace Modes SQL Log Filter Log User Log Escalation Log API Log Thread Log (Windows NT) Distributed Mapping Log Full Text Search Log Other Trace Modes Chapter 3 AR System Servers How the arservtcd Process Administers Servers Administering the AR System Windows NT Server Stopping the AR System Windows NT Server Starting the AR System Windows NT Server Logging Server Activity Administering the AR System UNIX Server Stopping the AR System UNIX Server iv Action Request System Administrator s Guide, Volume 2

5 Starting the AR System UNIX Server Using Signals with AR System UNIX Servers Logging Server Activity The Multi-Processing Server Feature and the AR System Administration Server Fast Servers List Servers Escalation Server Flashboards Server Private Servers Multi-Processing Server Lock Files Log Files Specifying a Server Name Configuring the Multi-Processing Server Feature Accessing Servers Without a Portmapper Configuring Clients for AR System Servers Assigning TCP Port Numbers to Servers Configuring Clients Windows Clients UNIX Clients Macintosh Clients Notification System The Notification Server User Logins Notification Delivery from AR System Server to Remedy Notifier The nfy Configuration File Chapter 4 Full Text Search What Is Full Text Search? Accruing and Weighting Results with FTS Sorting Requests by Weight Using the Ignore Words List Who Can Perform a Full Text Search? v

6 Using FTS Performing a Search in a Field Indexed for FTS Using the Accrue Operator Combining FTS and Non-FTS Fields Search Strategies and Issues Limitations of FTS Administering FTS Selecting Fields for FTS Indexing Reindexing The FTS Server (arservftd) Process Debugging FTS Moving the FTS Index Licensing Users for FTS Configuring FTS in the AR System Configuring FTS Options Modifying the Ignore Words List Rebuilding the Full Text Search Index Defining a Field for FTS in the Field Properties Window Estimating the Size of the FTS Index Moving the FTS Index Displaying FTS Weight in a Results List Chapter 5 Electronic Mail Support Using the AR System Electronic Mail Interface Using Electronic Mail to Submit Requests Establishing a Mail Address Setting Up the Mail Handler Starting the Mail Handler Using Mail Templates Searching Through Electronic Mail Overview Formatting Additional Configuration File Options Preparing the Electronic Mail Template vi Action Request System Administrator s Guide, Volume 2

7 Using Electronic Mail for Notifications Notifications For UNIX Servers Notifications For Windows NT Servers Troubleshooting armail on Windows NT Setting Up a Windows NT Account Additional Troubleshooting Tips Chapter 6 Dynamic Data Exchange Overview DDE Time-Out Settings Third-Party Applications and Macros DDE Server Name and Remedy User Path Supported DDE Topic and Function Example Program and Buffer Assigning Active Link Values Through DDE Microsoft Excel Example Microsoft Word Example DDE and Reports Chapter 7 Using OLE to Enhance the AR System Understanding What OLE Can Do for You Combining Other Application s Features with Your Forms Creating an OLE Automation Active Link Sample Exercise: Using OLE Automation Linking to an ActiveX Control Understanding the Supported OLE Automation Servers Chapter 8 Moving from Development to Production Overview Preparing for the Move to Production Upgrade the Nonapplication Production Environment Test the Application vii

8 Enumerated Values Changing Fields Changing Menu Lists Plan a Time to Move to Production Prepare Your Users Find Inconsistencies Backup Structures and Data Moving to Production Exporting/Importing Manual Changes After the Move to Production Chapter 9 Technical Essays Resolving Conflicts in the Cache File Abstract Overview Access Control Process Changing a Server Name Abstract Overview Migrating to a New AR System Server or Database Abstract Overview Converting AR System Dates to Database Dates Abstract Overview Pushing Field Values Between Forms Abstract The Macro The Active Link Changing the Next Available ID for New Requests Abstract The Request ID Field viii Action Request System Administrator s Guide, Volume 2

9 SQL Databases Flat-File Databases Changing the Request ID Field Length or Prefix Abstract The Request ID Field Preserving Existing Request ID Field Values Changing Existing Request ID Field Values to the New Format Chapter 10 Using the Remedy ODBC Driver Creating Multiple Data Sources Using Crystal Reports with the AR System Selecting Report Fields in Crystal Reports Understanding Considerations for Join Forms Limitations When Using Crystal Reports Using MS Access with the AR System Appendix A AR System Configuration Files...A-1 ar...a-2 ar.conf (ar.cfg)...a-3 ardb.conf (ardb.cfg)...a-15 nfy.conf (nfy.cfg)...a-17 ar.ini...a-19 Appendix B AR System Server Utilities...B-1 arcache (arcache.exe)...b-2 arimport...b-5 armaild (armailex.exe)...b-6 arreload (arreload.exe)... B-11 arservdsd (UNIX Only)...B-13 arserverd (arserver.exe)...b-15 arservftd (UNIX Only)...B-17 ix

10 Glossary Index arservtcd (UNIX Only)...B-18 ntserverd (ntservd.exe) and ntsendd...b-19 x Action Request System Administrator s Guide, Volume 2

11 List of Procedures Assigning a Port Number to a Notification Server Assigning a Port Number to an AR System Server Attaching a Request to an by Using the Notify Filter Action Changing the Existing Request ID Field Format Through an AR Export File Changing the Ignore Words List Changing the Length of the Request ID Field Changing the Next Available ID for Flat-File Databases Changing the Next Available ID for SQL Databases Changing the Prefix of the Request ID Field Configuring a 16-Bit or Windows 95 Client to Avoid the Portmapper Configuring a Private Server Configuring a Windows NT Client to Avoid the Portmapper Configuring Macintosh Clients for a Private Server Configuring the FTS Options Configuring UNIX Clients for a Private Server Configuring UNIX Clients to Avoid the Portmapper Configuring Windows Clients for a Private Server Converting the Date and Time Format for a Sybase or MS SQL Server Database Converting the Date and Time Format for an INFORMIX Database Converting the Date and Time Format for an Oracle Database Creating Additional ODBC Data Sources Creating an Template to Search for a Field Creating an Template to Search for a Request ID Creating an Template to Search Using the Advanced Search Bar Format Creating an OLE Automation Action Link Procedure 1: Creating the Form Creating an OLE Automation Action Link Procedure 2: Defining the Active Link Creating an OLE Automation Action Link Procedure 3: Defining Action xi

12 Creating an OLE Automation Action Link Procedure 4: Defining Action Creating an OLE Automation Action Link Procedure 5: Defining Action Creating an OLE Automation Action Link Procedure 6: Defining Action Creating an OLE Automation Action Link Procedure 7: Defining Action Creating an OLE Automation Action Link Procedure 8: Testing the Active Link Creating the Push Field Active Link Creating the Push Field Macro Defining a Field for FTS Defining Full Text Search Information Disallowing Unqualified Searches Displaying FTS Weight in a Results List Editing the AR Export File Enabling FTS Debugging Entering Windows NT User Account and Password Estimating the Size of the FTS Index Exporting the AR System Definitions and Data Giving the Windows NT Account the Correct Permissions Importing the AR System Definitions and Data Licensing a User for FTS Logging on to the AR System Server from Crystal Reports Moving the FTS Index Manually Preparing to Rename the Server Rebuilding the FTS Index Removing the Dependency of the AR System Server on Remedy Portmapper Renaming the Server Restoring the AR System with a New Server Name Selecting Forms and Fields for Crystal Reports Sending a Report to Another Windows Application Setting the Multi-Processing Server Feature Environment Specifying Report Information in the dde.ini File Starting the AR System Server xii Action Request System Administrator s Guide, Volume 2

13 Starting the Thread Log Starting UNIX Servers Stopping the AR System Server Stopping the Thread Log Stopping UNIX Servers Troubleshooting Your Windows NT Account Updating Your Environment by the Export/Import Method Updating Your Environment Manually Using the arserverd -c Option xiii

14 xiv Action Request System Administrator s Guide, Volume 2

15 Preface Audience This guide is written for administrators who are responsible for setting up and maintaining the Action Request System (AR System ). It is intended to aid new and current administrators of the AR System. This guide builds upon the topics and strategies discussed in the Action Request System Administrator s Guide, Volume 1: Using Remedy Administrator. If you are a current AR System administrator, this guide enhances the ease of use and performance of your AR System environment. If you are a new AR System administrator, this guide helps you create an effective and efficient AR System environment. Before you explore the topics discussed in this guide, ensure that you understand the terms and concepts discussed in the Administrator s Guide, Volume 1, because that book contains all the required information for setting up and administering a basic AR System environment. Your knowledge of basic administrative AR System tasks is crucial if you are to implement the tuning strategies discussed in this guide. You must know how to use the AR System, including Remedy Administrator, Remedy User, and Remedy Import. Refer to the Action Request System User s Guide, and the Action Request System Administrator s Guide, Volume 1 online documentation for additional information. Overview of This Document Chapter 1, Performance Issues, provides information and instructions for fine tuning your AR System environment. This chapter helps you organize your AR System to run faster and more efficiently. Chapter 2, Log Files, provides troubleshooting information for various log files and trace modes. Preface xv

16 Chapter 3, AR System Servers, describes the AR System servers and how to administer these servers. This chapter includes information about the administration and performance of the Multi-Processing Server Option for the AR System. Chapter 4, Full Text Search, discusses the capability, performance, and administration of Full Text Search with the AR System. Chapter 5, Electronic Mail Support, describes how the AR System uses electronic mail ( ) to enable users without direct access to the AR System server to submit and search for AR System requests and receive notifications. It describes how to set up and use the electronic mail handler (armaild) so that users can submit or search for AR System requests. This chapter also describes how users can receive notifications by . Chapter 6, Dynamic Data Exchange, explains how you can use Dynamic Data Exchange (DDE) to integrate the AR System with third-party applications. Chapter 7, Using OLE to Enhance the AR System, explains how you can use Object Linking and Embedding to enhance the capabilities of the AR System. This chapter describes how to communicate with third-party Windows applications such as OLE Automation Servers. Chapter 8, Moving from Development to Production, explains how to move the AR System from a development environment to a production environment. Included are tips and guidelines for a smooth transition, methods for updating the production application, and tips for stabilizing the new application. Chapter 9, Technical Essays, is a compilation of essays concerning the AR System and the platforms on which it runs. Chapter 10, Using the Remedy ODBC Driver, describes how to use the Remedy ODBC (Open Database Connectivity) driver to integrate ODBC clients such as Seagate Crystal Reports. This driver provides a gateway to access data defined in Remedy forms. Appendix A, AR System Configuration Files, provides information about the AR System configuration files. Appendix B, AR System Server Utilities, provides information about the AR System server utilities. The Glossary lists and describes the terms with which you should be familiar. xvi Action Request System Administrator s Guide, Volume 2

17 Related Remedy Documents Related Remedy Documents The Action Request System Installation Guide details installing and licensing the AR System software. Installation guides are available for Windows 32-bit and UNIX platforms and are provided in both printed and online (PDF) formats. The Action Request System Quick Start Guide provides a general overview, establishes a foundation for use, documents interactive demonstrations, and describes implementing the AR System. This manual pertains to Windows 32-bit platforms. It is provided in both printed and online formats. The Action Request System Concepts Guide defines the key components of the AR System and explains how they work together to address your organization s needs. Read the Action Request System Concepts Guide before undertaking any of the procedures described in the Action Request System Administrator s Guide, Volume 1. This manual pertains to Windows 32-bit and UNIX platforms. It is provided in both printed and online formats. The Action Request System Administrator s Guide, Volume 1: Using Remedy Administrator describes how to use Remedy Administrator (the Administrator tool) to set up the AR System and define its local operations. This manual focuses on the Administrator tool s control over forms and applications. It also describes using workflow to create filters, escalations, active links, and guides. This manual pertains to Windows 32-bit platforms. It is provided in both printed and online formats. The Action Request System Administrator s Guide, Volume 2: Performance and Configuration (this manual) is an online manual that discusses advanced AR System administration topics such as performance issues, database servers, log files, full text searches, ODBC drivers, and advanced active links. This manual pertains to Windows 32-bit platforms for Remedy Administrator and includes information for both the Windows and UNIX versions of the AR System server. It is provided in online format only. The Action Request System Programmer s Guide is a reference guide for programming with the AR System application programming interfaces (APIs), based on C, and its Object Linking and Embedding (OLE) Automation interfaces, based on the Microsoft Component Object Model (COM). This manual pertains to Windows 32-bit and UNIX platforms. It is provided in online format only. Preface xvii

18 The Action Request System Error Messages Guide provides information about AR System exception messages that helps you identify and solve problems within the AR System. This documentation pertains to Windows 32-bit and UNIX platforms. It is provided in online format only. The Action Request System Distributed Server Option Administrator s Guide provides information about operating the AR System in a distributed, multiple-server environment. This manual pertains to Windows 32-bit and UNIX platforms and is available by contacting your authorized Remedy representative. The Flashboards Installation Guide for UNIX helps you install and license the Flashboards product and set up Flashboards users on UNIX and Windows. The Flashboards Administrator s Guide for UNIX describes how the Flashboards administrator can use the UNIX Administrator Tool to create flashboards and statistics, request data, collect history data, and use the Flashboards Performance and AR System Performance variables. The Flashboards Administrator s Guide for Windows describes how the Flashboards administrator can use the Windows Administrator Tool to create flashboards and statistics, request data, collect history data, and use the Flashboards Performance and AR System Performance variables. The Flashboards Troubleshooting and Error Messages Guide describes error messages generated by Flashboards, and it provides troubleshooting tips to help solve common situations. The Flashboards Getting Started Guide leads you through an online demonstration showing the use of Flashboards in a sample help desk environment and describes how you can use the sample flashboards supplied by Remedy Corporation. The Flashboards User Tool Quick Reference Card provides information helpful to anyone using the User Tool. Five Quick Reference Cards are provided for each purchased user license. The Flashboards User Tool and Administrator Tool provide you with application online help that describes how end users and Flashboards administrators can use the User Tool and Administrator Tool respectively. To see a list of the available help topics, choose Help Contents. xviii Action Request System Administrator s Guide, Volume 2

19 Conventions Used in This Document Conventions Used in This Document Some terminology has changed in the user interface of the Remedy client tools in this release of the AR System. In particular, schemas are now called forms, and entries are now called requests. Because the AR System API calls and data structures documented have not changed to match the new client terminology, some documents continue to use the terms schema and entry. bold italic courier <italic_courier> bold courier Indicates a new or important term. Example: filters Indicates a reference to another document or to a different section within the current document. Example: See AR System Documents. Italic type is also used for emphasis. Example: All users will have access. Indicates computer output and names of various infrastructure components (such as files, directories, machines, and underlying data structures). Example: # Remedy AR System Daemons Indicates a variable directory, file name, or string that users replace with the actual directory, file name, or string. Example: <ar_install_directory> Indicates data to be entered by the user. Example: Type <ar_install_directory>/bin/aruser. Indicates a series of menu selections. Select the last item specified. Example: Choose File Exit. Used in the left margin to indicate a step-by-step procedure. Preface xix

20 xx Action Request System Administrator s Guide, Volume 2

21 Chapter 1 Performance Issues As an AR System administrator, you can design your forms, set system values, and establish operating rules for your users that can enhance the performance of your AR System. This chapter describes how to make your AR System environment run faster and more efficiently. You will learn how to adjust the components of your environment to improve your system response time. The response time is the amount of time it takes to complete an AR System task, such as logging in to the server, searching for data in the database, or running an escalation. You will most likely become aware of a performance problem when your users alert you. Users might call when the system responds slowly or when they receive RPC time-outs on AR System operations. Other symptoms your users might report are active link actions that perform slowly or menu lists that take too long to load or display. This chapter provides some guidelines for you to follow, including: Gathering Performance Information Common Performance Tuning Tips Performance Improvement Areas Performance Issues 1-1

22 Gathering Performance Information If you must diagnose a performance problem on your system, begin by asking yourself and your users the following questions: What is your AR System configuration? Do you run remote databases? If so, what type? How many PCs are part of your system? Do your client tools run remotely? Are you running the Multi-Processing Server feature? Is performance slow only when logging in to the AR System server? Does the problem happen only when submitting an AR System request or also when modifying a request or searching for data in the database? Is there a specific time of day the system responds slowly? Are all the users experiencing the same performance problem, or is it isolated to a particular user? What non-ar System applications are running on the client or server? What type of performance is normal for the network? If you are experiencing time-outs, what RPC number appears? If you are receiving error messages, what message number appears? What is the text of the message? Gather as much information as you can about when and where the performance problem occurs. The more you know, the better you can direct your investigation. When you have answers to your preliminary questions, gather data to determine the baseline for your system. Baseline data represents the normal operating levels for your system. When you have determined your baseline data, you can identify behavior that is unusual for your system. Two methods of gathering baseline data are through Flashboards and through diagnostic log files on your AR System server. Work with your system, network, and database administrators to monitor overall system performance. 1-2 Action Request System Administrator s Guide, Volume 2

23 Using Flashboards to Gather Baseline Data Using Flashboards to Gather Baseline Data Flashboards is a Remedy product licensed separately from the AR System. You can use Flashboards to monitor and represent graphically the performance trends of your AR System server. Trends provide clues to trouble areas, such as the high use of resources at a particular time of day. Flashboards helps you understand the types and numbers of operations. These operations include filter actions, escalation actions, active link actions, searches, and submissions of new requests. You can use Flashboards to gather data about your database. This data might describe the demand put on your database and the types of operations performed by your database. The data you collect can lead to a reorganization of your database indexing. Some of the displays you might create with Flashboards include: API Statistics Displays the processing time for each API call. You can customize your display to include different types of API calls. Percentage CPU Utilization Displays the percentage of the CPU that the AR System is using. Watch for periods of heavy CPU usage and peaks in processing load. Request Statistics Displays the percentage of blocked requests due to the server performing another operation. You can include information about the average number of requests in the queue, the number of requests blocked per second, and the average number of requests in an unempty queue. If these numbers are high, consider increasing the number of AR System server processes you are running. See the Action Request System Administrator s Guide, Volume 1 for more information about server processes. Database Statistics Displays the processing time for database operations. You can include the number of database operations per second and the percentage of total time used for database operations. Workflow Statistics Displays the number of filters run per second, the percentage of time required for processing filters, the number of escalations run per second, and the percentage of total time used for processing escalations. Multi-Process Statistics Displays the statistics of CPU use for server processes that are running. Performance Issues 1-3

24 Using AR System Log Files to Gather Baseline Data The AR System provides log files as a resource for gathering data. Much of this information helps you investigate the performance trends of your system. Some log files are generated automatically, while others must be enabled before they begin to log operations. For more information, see Chapter 2, Log Files. Note: Running a log file requires a portion of your system resources. You do not need to have a log file enabled at all times. If you have some idea as to what actions might be the cause of poor system performance, enable a log file, perform the operation in question, and then turn off the log file. This gives you a short log of only the actions performed for that operation. See the Action Request System Administrator s Guide, Volume 1 for information about starting and stopping log files. Common Performance Tuning Tips The performance tuning tips presented in this section are the most common areas for improvement of your AR System performance. Many of these subjects are also discussed in Performance Improvement Areas on page 1-7. Check Query-by-Example (QBE) Match The default setting is Anywhere for both the Match preference in Remedy Administrator and the QBE Match property of character fields. When a user searches the AR System with the Anywhere setting, the search returns requests with field values matching any part of the criteria specified in a field. For example, an Anywhere search for requests matching the word turn returns all the requests containing any part of the word turn, such as right turn, left turn, turned, return, turned left, and user returned. These searches consume system resources. 1-4 Action Request System Administrator s Guide, Volume 2

25 Qualify Searches To improve performance, change the QBE Match preference in Remedy Administrator and the QBE Match setting of character fields to Equal or Leading. While more limiting to your users, these searches are more efficient than Anywhere searches. Qualify Searches Do not allow unqualified searches, as described in the following procedure. These searches return every request for a form, up to the maximum number of requests allowed. Disallowing Unqualified Searches 1. Select a server. 2. Choose File Server Information. 3. Click the Configuration tab. 4. Ensure that Allow Unqualified Searches is not selected. 5. Click OK to save your changes. Avoid unqualified searches in your workflow. For example, an active link that performs a set fields action based on the contents of a field should include a qualification that the field cannot be empty (!= NULL). Avoid NOT Operations in Searches Because indexes are not used for NOT operations (for example, Status!= "Closed"), an operation searches the entire database table if NOT is the only operation for that search. Avoid using NOT operations in searches. Performance Issues 1-5

26 Avoid Macros in Run Process Actions Avoid creating workflow that causes Remedy User to run a macro from the command line because this might result in slower system performance. If these operations are a part of your primary workflow, take into consideration the resources required to run these processes. Also consider that these processes run in parallel on the server. If several users run these operations simultaneously, system performance slows. Check Escalation Frequency Escalations that are set to run at intervals shorter than the time required to finish the previous process can cause performance problems. An example is an escalation that searches the database for 30,000 requests but is set to execute every minute. Multiple escalations that are set to run simultaneously can also cause performance problems. For example, three escalations one set to run at 15- minute intervals, one at 30-minute intervals, and one at 60-minute intervals set to run the final time each day at the same time will run simultaneously every 60 minutes. Build Obvious Indexes Use indexes for each of the following fields: Fields that search for additional information. For example, a user presses Return in the Last Name field, starting a set fields action that searches for more information based on that field. Fields used in search menus Fields used in the macros of active links defined to open a results list Fields used commonly in searches Optimize the Number of Indexes While indexes can speed system performance, too many indexes can slow your system. Create no more than five indexes per form. 1-6 Action Request System Administrator s Guide, Volume 2

27 Use the Server for Set Fields Operations Use the Server for Set Fields Operations For submit and modify actions, have the server (filter) perform a set fields action rather than the client (active link). For example, an active link that performs a set fields action on submit pulls information from the server, only to push that information back. Your system performance will improve if you use a filter to perform the set fields action at the server. Avoid Sending Notifications to Groups The notification server is single threaded. If you have workflow that sends notifications to members of a group, and that group has several people, the notification server is inaccessible until notifications are sent to every member in the group. When possible, avoid sending notifications to large groups. Minimize the Use of Diary and Unlimited Text Fields Diary and unlimited text fields require large amounts of system resources, making searches and other workflow processes time consuming. Performance Improvement Areas To improve the response time of your system, you might need to modify one or more of the following areas of your environment: Hardware Operating system Database Shared cache Network Other applications User actions AR System components Indexes Configuration of the Multi-Processing Server feature Performance Issues 1-7

28 Notification server Archiving data Environment-specific issues Database administrator extensions Hardware The CPU performance of the clients or servers in your environment can impact AR System performance. The individual machines might require upgrading to speed the response time of your overall environment. This is especially true for the servers. If a server runs slowly, even the fastest client might have performance problems. The amount of physical memory on your clients and servers can also affect system performance. Lack of physical memory might cause slower virtual memory to be used (see Database on page 1-8). Work with your system administrator to determine hardware performance solutions. Operating System The amount of virtual memory on your system affects performance. With less virtual memory, your applications and processes might run slower. The overall system load on your machines also affects performance. In general, the more applications you have running, the slower your systems run. Work with your system administrator to determine operating system performance solutions. Database The following guidelines help you set up a database that runs efficiently with the AR System: If your system is storing more than 5,000 requests, run a relational database. A flat-file database is not robust enough to handle the workflow and performance demands associated with a large number of requests. 1-8 Action Request System Administrator s Guide, Volume 2

29 Shared Cache Allocate enough shared memory to the database where you run your AR System. If your database does not have enough shared memory or data cache, your system might perform poorly. Allocate as much memory as you can spare (see Hardware on page 1-8 and Shared Cache on page 1-9). Use Remedy Administrator to index fields where searches are performed. Proper indexing is one of the most significant performance improvements you can implement. If your AR System is sharing a database server with other applications, your AR System might run slowly. You might need to dedicate a database server for the AR System. If you spread your AR System database over multiple devices, you can improve database performance, especially if you have a large AR System database. If you run remote database servers, you increase the traffic over your network, resulting in slower system performance. In addition, remote databases consume other operating system resources on the local machines, such as memory. Ensure that your network does not decrease performance if you run a remote database. Tune your database by using the methods suggested by your database vendor. You might modify your database parameters, kernel parameters, and the physical storage device. Work with your database administrator to determine database performance solutions. Shared Cache Without a shared cache, each server process on a machine loads a copy of the AR System structures from the database. Whenever a structure is changed (for example, by adding a field to a form), each server process reloads its cache. Because a server is inaccessible to users while it accesses the database, administrators of machines without shared cache should make changes to AR System structures during nonwork hours. Performance Issues 1-9

30 With a shared cache, AR System servers can access database information in a cache shared by all the server processes on a machine. When one server process changes a structure, it changes the cache at the same time it modifies the database. All other processes on that machine will then use the new structures in the shared cache. This enables servers to retrieve structure information without having to access the database directly, improving system performance and enabling administrators to make changes during work hours. Shared cache is available for machines configured to run with shared memory and semaphores. Windows NT Windows NT machines always use a shared cache and need no special configuration. Use of the shared cache cannot be disabled on Windows NT. UNIX UNIX machines run without shared cache by default. To enable shared cache on UNIX, add the line Enable-Shared-Cache: T to your /ETC/ar.conf file (F disables shared cache). You might also need to add or modify the Shared-Cache-Segment-Size value of the ar.conf file for the amount of shared memory you want to allocate. If the Shared-Cache-Segment-Size line is not present, a default value of 4 MB is used. To determine the necessary size of each shared memory segment, run arserverd with the -c option. Using the arserverd -c Option 1. Determine whether any AR System servers are active. The arserverd process can conflict with other active AR System servers. Although arserverd does not interfere with the functionality of other servers, it does detect them and fail to load its cache. If you have active AR System servers, run arserverd as a private server. 2. If you are not running any other AR System servers, type the arserverd executable as follows: arserverd -c 1-10 Action Request System Administrator s Guide, Volume 2

31 Shared Cache If you are running other AR System servers and need to run arserverd as a private server, include in the command an unused RPC program number from within the private server range ( ). For example, if you are running a system with only administration, fast, list, escalation, and Flashboards servers, you can run arserverd as a private server by typing: arserverd -c -r The process returns the number of bytes consumed by a single copy of the cache (if the cache resides in shared memory) and the recommended size you allocate in the Shared-Cache-Segment-Size line of the ar.conf file. The output is formatted as follows: Total bytes used for initial cache Recommended bytes per cache The arserverd process returns the number of bytes currently consumed for its cache. Allow at least 25 percent extra space for your cache to grow (or more if you expect to make many administrative changes); this is the number arserverd returns as the recommended bytes per cache. In the example, arserverd returns 1,045,800 bytes for the currently consumed cache, and recommends 1,307,250 bytes for each shared memory segment. 1,045,800 * 1.25 = 1,307,250 When you know the amount of space needed, use that number in the Shared-Cache-Segment-Size line of the ar.conf file (the default value is 4 MB). The following example shows the shared cache lines of the ar.conf file for an AR System running shared cache and having a segment size of 1,307,250 bytes: Enable-Shared-Cache: T Shared-Cache-Memory-Size: You might need to adjust the available shared memory in your environment to provide space for the AR System. The maximum amount of shared memory that AR System servers can consume is the amount of memory per cache multiplied by one more than the number of AR System servers to be run. Performance Issues 1-11

32 For example, if you run an administration server, a fast server, and two list servers (4 servers total) and arserverd recommends 1,307,250 bytes for a copy of the cache, the most shared memory your AR System consumes with shared cache enabled is 6,536,250 bytes. 1,307,250 * 5 = 6,536,250 Note: If you do not allocate enough shared memory, your applications that access shared memory might behave unpredictably, particularly your database application. Network Your network plays a role in the overall performance of your system. Know the peak periods of activity on your network. Schedule your escalations to run at times other than these peak periods. When you back up data over the network, you leave less bandwidth for the AR System server to communicate with the clients, temporarily slowing system performance. Work with your network administrator to determine network performance solutions. Other Applications Other applications running in parallel with the AR System contend for the same resources. These applications can demand hardware resources on the server or client. They also might access the same database as the AR System, resulting in slower performance. Major system and network activities during peak work hours might compete with the AR System for resources, so be aware of how other applications are being used Action Request System Administrator s Guide, Volume 2

33 User Actions User Actions The following actions by users can affect the performance of your system: Running other applications on their computers, which compete for resources with the AR System Running large reports during peak work hours or running unqualified or poorly formatted searches, which contend for system resources. Users should design reports to return only the data needed. Setting up automatic polling for results lists. Users should eliminate automatic polling or increase the polling interval. Running Remedy User through a remote X command, which increases network traffic. Users should run the AR System from their native clients rather than through a remote X command. Work with your users to identify user-based performance solutions. AR System Components The following sections describe how you can modify the components of the AR System to improve overall system performance. Do not make any structure changes during production hours. Performing structure changes during production hours impact your users significantly. Designing Searches Searches are the most common AR System transactions against a database. Optimizing search performance should be a primary goal. Searches are used in many aspects of your system, not just in searches through Remedy User. Most AR System operations are designed around searches. Examples of these operations are active links, filters, and escalation qualifications. You can improve the efficiency of these processes with welldesigned searches. For example: For an active link, escalation, or filter that performs a set fields action based on the contents of a field, include a qualification that the field cannot be empty (!= NULL). Performance Issues 1-13

34 For searches that reference indexed fields, include the field name on the left side of the operator in order to make use of the index. If the field name is on the right of the operator, the search instead does a table scan. For example, Create Date < $TIMESTAMP$ - 60*60*8 is more efficient than $TIMESTAMP$ - Create Date > 60*60*8 if the Create Date field is indexed, because the field name is to the left of the less-than (<) operator. You can require users to better qualify their searches by disallowing unqualified searches and limiting the number of requests that can be returned by a search. You can also modify the fields on your forms. QBE searches configured for Anywhere do not limit users, but they put the most strain on the database. Use Remedy Administrator to change the QBE Match setting for fields to Equal or Leading. Equal is the most efficient method of searching. You can modify Full Text Search (FTS) options to expedite searches on diary and long character fields. For additional information see Chapter 4, Full Text Search. Designing Search and SQL Menus To speed system performance, design your menus to search indexed fields. Also, be careful to design equal or leading qualifications for your search menus. Design your search menus to return the fewest possible values. When you use search menus, select a Refresh of On Connect whenever possible. The On Connect setting causes the menu to refresh only when the user opens the menu the first time after opening the form. An exception to this rule is when you have a search menu that depends on a field value in a form. In this case, you must have Refresh for the menu set to On Open. Otherwise, the menu does not update when the value that sets the menu changes. Warning: Frequent menu retrievals can impact performance. Only select a Refresh of On Open when absolutely necessary. With SQL menus, which allow any valid SQL statement to be run, use an efficient SQL statement. For example, rather than using select * statements, specify the two columns to be used as the value and label Action Request System Administrator s Guide, Volume 2

35 AR System Components Designing Join Forms Generally, join forms behave like regular forms. However, be aware of the following issues when you create join forms: If you create multiple layers of join forms, you might see a decline in the speed of database and system performance. Ensure that you only join fields that have been indexed. Joins on nonindexed fields can slow system performance. Designing Fields To improve performance, shorten data fields that are greater than 255 characters in length. Long fields are inefficient for searches and occupy more space than shorter fields. Also, maintain a minimum number of diary fields, because the greater the number of diary fields in a form, the greater the impact on performance is for that form. Designing Form Views If you are maintaining multiple form views with trim or control fields, do not duplicate screen objects unnecessarily. Whenever possible, share screen objects between views. The more screen objects you create (data fields, control fields, and trim), the larger you make your forms and the longer it takes Remedy User to load, display, or switch to another view. Avoid having too many toolbar buttons with different bitmaps in multiple views. This also increases the form size. Designing Active Links Limit the number of active links for a given form. It is possible to slow the workflow with too much background activity. However, because active links execute locally, they do not impact the server as filters can. With one exception, if you can design an active link that accomplishes the same actions as a filter, do so wherever possible. (The exception is for set fields actions. Use filters for set fields actions.) Performance Issues 1-15

36 To improve active link performance, improve active link conditions. Where possible, simplify the qualification for active links. Also, you can choose to have an active link activate for more than one type of operation. This is more efficient than designing two active links that are identical other than their Execute On selection. For example, you might want your users to have the option of clicking a button or pressing Return to open a selection menu list. Design both of these Execute On actions in the same active link. Designing Filters To improve filter performance, improve filter conditions. Where possible, simplify the qualification, and combine filters that use the same qualification. Use the filter log to identify when filters are run and the actions the filters take. You might learn that an active link is better suited for the purpose. Turn off the log after analysis, or the log occupies disk space and can slow system performance. Designing Set Fields Actions For active links, filters, and escalations, you can specify set fields actions that submit a search to the server. Avoid putting slow searches in set fields actions, especially if workflow executes the search frequently. For efficient searches, define where the system looks for the data. Though less important to performance than a well-defined search, you can improve performance by designing your set fields actions to retrieve only the columns needed. Designing Escalations The following guidelines help you design efficient escalations: Keep the number of escalations to the minimum required for your workflow. Try to run escalations only on indexed fields. Streamline your escalations by including all available criteria in the qualification. By limiting the search, your escalations run faster. Stagger your escalations to run at different times. Escalations that run simultaneously can impact the performance of your AR System, especially during work hours Action Request System Administrator s Guide, Volume 2