Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Oracle E-Business Suite Information Discovery Performance Guide O R A C L E W H

Oracle E-Business Suite Information Discovery Performance Guide O R A C L E W H I T E P A P E R | A P R I L 2 0 1 6 Table of Contents 1. Overview 1 2. Oracle Endeca Server 2 2.1. Performance Issue Indicators 2 2.2. Tuning the Dgraph Process Cache 2 2.3. Multithreaded Mode 5 2.3.1. Monitoring CPU Utilization 5 2.3.2. Tuning the Dgraph Computed Threads 7 3. Oracle Endeca Studio Server 9 3.1. Monitoring Performance of Studio Portlets 9 3.1.1. Measuring Loading Time for Portlet Client Studio Pages 9 3.1.2. Measuring Individual Portlet Performance 10 3.2. Monitoring Query Performance 12 3.2.1. Configuring the Metrics Data to Record 12 3.2.2. Metrics Log File 13 3.2.3. Optimizing EQL 14 3.2.4. Performance Metrics Page 14 ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE 1. Overview Oracle E-Business Suite Information Discovery extends the Oracle E-Business Suite applications by leveraging Oracle Endeca Information Discovery. Oracle Endeca Information Discovery is an enterprise discovery platform for the analysis of information from both structured and unstructured sources, providing the ability to search for and visualize data in many different ways. The goal of this document is to give users an overview of the performance of Oracle E-Business Suite Information Discovery and some basic instructions on how to enhance performance for Oracle E-Business Suite Information Discovery products. 1 | ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE 2. Oracle Endeca Server Oracle Endeca Server query performance depends on many characteristics of your specific deployment, such as query workload, query complexity, data domain configuration, and the characteristics of the loaded records, as well as the size of the data domain's index. In view of these characteristics, a hardware sizing must be performed prior to deployment, to assess memory consumption and other hardware needs of your deployment. Also, performance depends on the number of cores; the computed number of threads must be adjusted to utilize the full capacity of a multithreaded environment. The Oracle Endeca Server application services requests for one or more Endeca data domains. Each Endeca data domain has one Dgraph process, or, if you implement clustering, a set of one or more Dgraph processes, that handle end-user query requests. The Dgraph uses proprietary data structures and algorithms that allow it to provide real-time responses to client requests. It stores the data files that were created from loading the data into it. After the data files are stored, the Dgraph: » Receives client requests through the application tier » Queries the data files » Returns the results The Dgraph is designed to be stateless. This design requires that a complete query be sent to it for each request. The stateless design facilitates the addition of Dgraph processes for load balancing and redundancy. 2.1. Performance Issue Indicators Performance issues that users could face while accessing Endeca pages might be related to the utilization of the cache or threads. Some indicators of performance issues are: » An Endeca page takes too much time to load. » Portlets time out. » Bulk load takes too much time. » The UI becomes nonresponsive. 2.2. Tuning the Dgraph Process Cache The Dgraph cache is a storage area in memory that the Dgraph uses to dynamically save potentially useful data structures, such as partial and complete results of processing queries. Oracle Endeca Server uses caching of results for the Dgraph processes extensively, for many types of queries. Allocating more memory to the cache improves performance by increasing the amount of information that can be stored in it. Thus, this information does not have to be recomputed. Such a caching strategy allows the computing resources to be utilized better, and therefore improves throughput of the Oracle Endeca Server. Access the Dgraph statistics page for each Dgraph process running for your data domain, using the following URL: http://<host>:<port>/endeca-server/admin/<data_domain>?op=stats Replace < host> and <port> with the host name and port of the Oracle Endeca Server, and <data_domain> with the name of your data domain. Note: If your data domain runs on more than one Oracle Endeca Server instance, you should access this page on each system hosting the Oracle Endeca Server for this data domain. On the Dgraph statistics page, examine the Dgraph cache, in particular the number of evictions. If this number is high and the hit ratio is low, it means that the default value is insufficient for your data domain, as shown in Figure 1. 2 | ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE Figure 1 Eviction Time On Linux-based systems, you can use operating system tools such as top, ps -efl, or ps -aux to look at the size of Dgraph processes to determine the process’s resident set size in the physical memory on the machine, and the actual amount of memory the given process consumes. For example, Figure 2 shows the sample output for the top command: Figure 2 Sample Output for Memory Usage Using the Top Command Use the following recommendations when tuning the performance of your applications running on top of the Oracle Endeca Server. » Check the current configuration setting for the Dgraph cache using the following command: 3 | ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE ./endeca-cmd get-dd-profile FND_EID_DD_DEFAULT_PROFILE where FND_EID_DD_DEFAULT_PROFILE is the default name of the profile used by your data domain. This command returns the setting for the --compute-cache-size for all Dgraph processes serving your data domain, as shown in Figure 3. This setting represents the amount of RAM, in MB, allocated to the result cache on each Dgraph node in the data domain. Figure 3 Computed Cache Size The default is 0, which is interpreted as follows: when an absolute value is set to 0, the default Dgraph cache size is computed as 10% of the amount of RAM available on the Oracle Endeca Server node hosting the Dgraph node. Alternatively, you can check the cache size for each Dgraph by running the grep command from Linux, as follows: ps aux | grep dgraph Figure 4 Cache Size Using grep Command » Experiment with gradually increasing the Dgraph cache size. For example, you might start by changing the cache size to 20% of memory instead of leaving it at the default value. You should have enough memory in the system to accommodate the new value based on the number of data domains that you have on the system. If you later find that queries are getting canceled because there is not enough available memory to process them, then you should decrease this amount. Note: To specify the new value; you would need to calculate the size in MB that corresponds to 20% of the memory, based on the size of the RAM on the system hosting the Oracle Endeca Server. 4 | ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE Be careful when increasing the cache size significantly, such as to 50% of memory, because the disadvantage of having a large cache size is that memory used by the cache is not available for query evaluation and is not released back from the cache. To specify a new Dgraph cache size for a data domain, perform the following steps: 1. Modify the EidConfig.properties file: » Set the FND_EID_DD_PROFILE_PRODUCTS parameter to a list of the products whose cache you want to tune. » Set the FND_EID_DD_CACHE_SIZE parameter to the new cache size value. 2. Run the postSetup.sh script and select Option 2 - Create DD Profile. 3. Run the command endeca-cmd get-dd-profile FND_EID_DD_DEFAULT_PROFILE to return the new setting for the --compute-cache-size parameter. 4. Monitor the Dgraph cache again on the statistics page, where you should see that the number of evictions is low and the hit ratio is high. 2.3. Multithreaded Mode Oracle Endeca Server always runs in multithreaded mode, with the total number of threads set to 4 by default. Oracle recommends increasing this number to maximize the use of system resources. On processors that are hyperthreading or multicore, multiple query threads can use a single processor at the same time. 2.3.1. Monitoring CPU Utilization On Linux, you can examine the CPU utilization using standard tools, such as the top command. Figure 5 CPU Usage You can check CPU usage and throughput for the Dgraph by accessing the statistics page: http://<host>:<port>/endeca-server/admin/<data_domain>?op=stats 5 | ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE Figure 6 Endeca Server Statistics You can use command-line tools to review your current configurations. To check the number of available cores, use the following command: less /proc/cpuinfo Figure 7 Available Cores To check the number of threads for each Dgraph, which is set to 4 by default, you can run the grep command from Linux as follows: ps aux | grep dgraph 6 | ORACLE E-BUSINESS SUITE INFORMATION DISCOVERY PERFORMANCE GUIDE Figure 8 Computed Threads Alternatively, you can run the following endeca-cmd command: ./endeca-cmd get-dd-profile FND_EID_DD_DEFAULT_PROFILE Figure 9 Number of Computed Threads 2.3.2. Tuning the Dgraph Computed Threads You can specify the number of computational threads in the Dgraph node's threading pool using the parameter ---num-compute-threads. The value for this parameter must uploads/Management/ performance-guide 1 .pdf