Enhancing Application Performance

1. Enhancing Application Performance Root Causes and Quick Solutions

2. Enhancing Application Performance:Root Causes and Quick Solutions Application performance always has the potential to burden a Clarity instance and discourage users. In this session, Rego’s team of Clarity experts will review the root causes of Clarity performance issues and help you identify steps to take that will improve performance within the application and supporting infrastructure.

3. Enhancing Application Performance:Root Causes and Quick Solutions Application performance always has the potential to burden a Clarity instance and discourage users. In this session, Rego’s team of Clarity experts will review the root causes of Clarity performance issues and help you identify steps to take that will improve performance within the application and supporting infrastructure. • Importance of solid performance • Components impacting performance • Addressing performance problems • Real-world problems • Application sizing • Database tuning & I/O • User portlets & configuration • Reports

4. Performance is critical to Clarity deployment and usage Performance issues impact the usability, dependability, and scalability of a system

5. Key levers we can use to improve performance Items driving performance are typically resolved by adjustments to the application configuration, application server, and database environment. • Process Changes • Hardware Investment • Functional & Technical • App Configuration • Job timing • Job conflicts • Page layout • Security model • Slice settings • Period settings • Code optimization • Inactivate resources • Purge investments • App Server • Memory • Cores • JVM Architecture • JVM Memory • JVM GC Settings • Maintennance • DB Environment • Memory • Cores • Shared usage • Storage speed • Query performance • Long sessions • Maintenance jobs • Parameters • Reporting demand

6. Application configuration tends to force functional settings Application configuration issues typically require a mix of both functional and technical changes. The changes are often caused by suboptimal configurations. • Job timing • Leverage evening downtime window but coordinate with DBA • Run database and system maintenance jobs after Clarity jobs complete • Avoid large data changes (e.g. post timesheets regularly) • Job conflicts • Avoid conflicts between slicing, posting, etc. • Security model • Use global rights if possible • Minimize the use of instance rights • Page layout • Browsers and the application have ‘real limits’ to what they can digest • Slice settings • Minimize slice time ranges • Period settings • Close time and fiscal periods. • Code optimization • Suboptimal SQL and Gel is the number one issue we see!

7. Application server issues are hardware related Application server issues typically an increase in the capacity of the application servers. Key indicators of an application server issue are high application cpu and heap dumps. • Memory • 6 GB for the app JVM is great – but 7 GB is worse • Never less than 2 GB for the BG – typically 2.25 GB is good • Cores • 1 Core per JVM or BG • 1 Core for the OS • 1 Core for GC • JVM Architecture • 1 or 2 BGs • 50 to 150 concurrent users per JVM • Leverage a XOG / Admin / Scheduler JVM • JVM GC Settings • Parallel garbage collection if more than 1 core • Maintenance • Weekly restarts may be necessary, but can typically be avoided if architecture sized correctly.

8. Database server issues are typically tuning related Database issues are often a mix of hardware, customization, and maintenance. • Memory • Most common problem. Clarity LOVES memory! • Cores • Uncommon problem – start with tuning and memory • Shared usage • Applications need to ‘play nice’ • Storage speed • Clarity demands a high speed SAN. Memory compensates for IOPs…. • Query performance & Long running session • Second most common problem! Efficient SQL is critical. • Sessions persist after there are not visible on the application! • Maintenance jobs • Do not run standard Oracle database stats job • Parameters • Contact Rego for environment specific database parameters • Reporting demand • Monitor and plan for Crystal and Webi reporting

9. Performance data exists in a variety of data sources There are a variety of sources providing key information on performance. Rego Exchange has portlets that help monitor jobs, processes, and database (Oracle) performance. • Log & ConfigFiles • App Logs • BG Logs • App Access Logs • Process engine • Infrastructure • Diagrams • Confirm Cores • Confirm Memory • Confirm IO • Confirm Network • GC Performance • Database Reports • Oracle advantages • Deadlocks • Waits • Physical IO • Cache Memory • Long sessions • Top SQL by CPU • Top SQL by IO • Table fragmentation • Table configuration

10. Performance is an iterative process • Critical Configuration • Hardware & Tuning • Systemic Addressing performance issues is an iterative process!!! Start with the low hanging fruit. Issues often ‘mask’ the more systemic issues. • JVM Config • Query Tuning • DB Health • DB Locking • Job Schedule • App HW • DB HW • DB Config • Query Tuning • Performance Assessment • Maintenance Program • Configuration Assessment

11. Discussion & Questions Any questions before we continue?

12. Real-world Case: Application Sizing Symptom • Application heap dumps, out of memory warnings, and periodic slowness • Database appears to be healthy Clues • Clarity 13 requires additional capacity (memory & cores) • JVMs heaps were 1.5 GB or the app and 1.0 GB for the BG • Application JVMs spending significant time garbage collecting • Symptoms appear during peak usage time • Database is healthy Resolution • Increase memory for JVMs to 6 GB for the apps and 2 GB for the BB • Increase cores to 1 core per BG, 1 core per APP, 1 core for OS, and 1 core for GC. • Add JVM for XOGs / Admin / Scheduler Result • Stable Dev environment • Pushing to production • If cores are limited, try memory increase first and watch GC performance

13. Real-world Case: Database I/O and Tuning Symptom • Frequent & persistent application slowness • Database CPU and application CPU are inconsistent Clues • Long running sessions on the database (more than a few minutes) • Blocking sessions • High physical I/O Resolution • Moved to the Clarity stats job (Oracle) nightly & disabled the Oracle cron job • Increased the size of the database cache (PGA and SGA) • Rebuilt indexes associated with long running SQ Result • Stable and consistent production environment • Exposed additional queries that needed to be tuned • Exposed need to establish tuning and maintenance process

14. Real-world Case: User Portlets and Configuration Symptom • Select users long waits with select portlets and pages • Periodic system slowness • Oddly high database CPU Clues • Long running sessions on the database (more than a few minutes) • Top SQL includes portlet queries with poor SQL Resolution • Tuned the queries causing the issue • Changed the page configurations to render on filter only • Set default filter for the portlets Result • Improved portlet speed • Eliminated long running sessions (led to system issues) • This can also apply to WebI and reports

15. Agenda • Integration Basics • Triggers • Methods • Comparing Methods • Quiz • Keys to Success • Exercise – Develop an interface • Common Interfaces

16. Integration Basics – Triggers • Event Based • This type of Interface is triggered by event in the system. (Either something got created or updated or deleted) • Batch • This type of interface is scheduled and triggered at a set time (nightly or at certain interval, etc.). Since, batch interfaces will handle multiple instances, you want to address transaction managements (what happens when a record fails – one fail, all fail?) • Manual • This type of Interface is manually started by the user when they are ready for data transmittal.

17. Integration Basics – Methods • Flat File • A .CSV file ftp'd onto a server can be pulled into Clarity. The file can be processed by custom GEL script that can be scheduled or started manually. (This is CA’s preferred method of integration for the On-Demand Clients) • Web Services • XML based messaging that makes a call via URLs, or over HTTP to request data from or push data into clarity. This method could leverage GEL scripts, Java classes, or Stored Procedures in the DB • This is the most common approach used by any industry for Integrating different systems. Most of the big software vendors like SAP, Oracle, HP, CA have web service API’s developed for bi-directional data exchange with their systems. • Database Links • Establish a link from the Clarity DB to another system database and just pull data from one system to another using a stored procedure or SQL statement. Best practice in this form is to create a “view” in the source system vs. the core tables. (This is not an option for the On Demand Clients) • Third Party Tools • Leverage a third party integration tool like ITROI, etc. to build integrations. • Leverage an integration service – Pervasive or Task Top

18. Comparing Methods *With an integration, effort is needed on both the sending and receiving application. This means that any Clarity integration will require some effort form the support team of the system you are integrating to. The level of effort depends on the type of interface

19. Quiz • You are an On-Demand customer and you want to bring in Actuals from your financial system. • You are an On-Premise customer and have a million Resource Assignments that have to be loaded into your HR System for populating Resource timesheets. • You want to import all your support-inbox emails into Clarity as incidents or some other custom object • You want Clarity and your Project Accounting system to be in sync and you want the changes to be sent over instantly • A project created in Clarity needs to be sent over to your Financial System for Budget Approval. Upon approval in your Financial System, Clarity needs to be updated so that the Project Plan is sent over to your Timekeeping system. How would you implement this?

20. Keys to Success • Simpler is Better • With integrations, the more complex the interface is the more difficult it will be to build and maintain. One Direction vs. Bi-Direction is simpler. • Get it Right the First Time • We love agile and iterative development, but not when building an interface. Interfaces are best done with solid waterfall requirements and signoffs. • Integrations are recurring jobs. • Integration are not for performing one time data loads. Integrations are for exchanging data between two systems on a regular basis. • Data Ownership is Key • You must determine which system is the “master” vs. the “slave” of the data. One source must be the owner of the data in case there is a conflict. Do not make the mistake to think Clarity will be the “source” of everything. Leverage other systems to pull summarized data vs. all detail.

21. Keys to Success • Error Handling / Transaction Management • Errors are inevitablewhen two different systems are being integrated. Therefore plan to developing an error handing mechanism to handle data errors, connectivity errors, and system outages. • Equally important is transaction management and performance considerations • Trial First to Avoid Errors • Before you build the complete interface – try a semi-automated load to ensure the “process” you have defined is correct. • Have a Testing Environment. It is really important to have test environments that mirror the productions as much as possible and that the data is representative of actual production data. 

22. Exercise • Create a csv file on your server with data for the following columns • Project ID, Amount Approved, Amount Requested, Date Approved, Approved By • Create a custom object in Clarity (can be a Master Object or a sub-object of Project ) with the following attributes • Project ID, Amount Approved, Amount Requested, Date Approved, Approved By • Create a Workflow with GEL script that will read the .csv file on the server and load data into the custom object using XOG.

23. Common Interfaces • Single Sign On • Using a common ID, authenticate users in Clarity for login. • Time • Push time from Clarity into an HR or time pay system like Ceridian, PeopleSoft, etc. • Financials • Pull actuals, budgets, or rates from a financial system into Clarity • Human Resources • Pull resource related data from an HR system into Clarity. This may include manager, cost center, country, rates, skills, OBS, RBS, etc. • Help Desk • Escalate tickets from a help desk system into Clarity for work management and assignments. Potentially a feed from Clarity back to the help desk system upon resolution. • Sharepoint • Push data from Clarity to sharepoint, including project information to allow users in sharepoint to see high level information – status, fields, milestones, etc.

24. Common Interfaces

25. Questions Contact US 888.813.0444 Email Contact info@regoconsulting.com Web Site www.regoconsulting.com Thank you. Presenters: Raghu Bongu Bishnu Chattopadhyay