This section describes some of the common problems that might affect performance.
See Also: Query Performance Considerations
To investigate what part of a query is affecting performance, you can use the IDOL Admin performance analysis feature. See Improve Query Performance for information about interpreting the analysis results . You can also set the LogLevel to FULL for the query.log, and use the information in Improve Query Performance to review the log data.
For a slow query, use the following points to identify performance issues:
What is slowing the query down (certain query parameters or steps in the query)? Add query parameters and clauses one by one and see what difference each change makes. For example, you might find that your query includes a setting such as Predict=False, which slows the query down but is not required for your business purpose.
Check why you are sending the query, to make sure that you use the results. Are you sending any unnecessary queries?
Check that you are using optimized field types, for example MatchType fields for MATCH FieldText operators.
Find out whether you can reduce the number of queries. For example, could you get the data required from a single query, rather than five separate queries?
After you find the slowest parts of your queries, see Query Performance Considerations for more information about steps you can take to improve performance. You can also see FieldText Optimizations for information about the impact of various field optimizations for FieldText queries.
See Also: Configure the Content Component for Speed
The Content component performs document indexing and processes queries. When you are trying to improve performance, consider the following questions to determine whether you have sufficient resources for your purposes. There is no right answer to these questions, but it might help you identify areas where you can improve performance.
How many Content servers do you have? In cases where content servers handle many simultaneous queries, you might want to set up additional mirrored servers with a DAH to distribute the load and reduce individual query times.
How many documents and document sections do you have per server? You can distribute documents between more servers to reduce the query load. For example, if you have 20 million documents in one server, and you experience poor performance, you might want to split the content between two servers with 10 million documents each.
How many terms do you have per server, and are all of them useful? A large number of unnecessary terms can result in slow performance for text-based queries. You can often set these terms as stop words to improve the performance.
You can check for unnecessary terms by using IDOL Admin, or by sending the TermGetAll action with TermAnalysis set to True.
Check the memory management of the servers in IDOL Admin or by using the MemoryReport action. For example, you might notice that the numeric index is taking up more memory than expected, because a particular field is configured as numeric even though it is not used for numeric queries.
Are your Content servers under a heavy index load? In this case, you might consider mirroring query servers, or scheduling indexing to take place when the query load is low.
What number of threads have you given each Content server? You might find that you have configured too many threads, and they are all contending for physical resources.
Consider your DAH thread count, and whether this number is in line with the number of threads you have across its servers.
A computer has a number of CPUs, which in turn has a number of cores. Cores are the processing units, and each core can do one thing at a time. A four-core machine can do four simultaneous actions. It is better to have more cores, because this means that the server can perform more actions at one time.
Threads are the channels through which you send commands to the cores. You can configure more threads than cores for better memory management. Generally, Micro Focus recommends configuring one thread per core, and one spare thread, but you should experiment on your system to find the optimal value.
You must distribute the total number of threads for the machine between the services that you have running on it.
For performance, you generally need only consider query threads (set in the Threads parameter in the [Server] section of the configuration file).
Unless you have multiple data sources all trying to index into IDOL simultaneously, there is little point in increasing the number of Index threads from its default value. The configuration limit affects how many threads can simultaneously receive data. However, the incoming index actions are committed to the index queue in the order in which the data uploads finish (not begin) and there is only one processing thread consuming jobs from the queue.
The optimal number of Content servers you can run on one machine requires a balance between query times and the number of threads per server. The more non-mirrored Content servers you have running on the machine, the fewer threads you can use for each Content server.
If you have 12 query threads available, and four non-mirrored child Content servers, you can have three threads per Content server. If you have 12 non-mirrored Content servers, you can have only one thread per Content server.
In non-mirror mode, the DAH queries each child server to return one set of results. In the first example, each Content server can process queries on three threads. In the second example, each Content can process only one query at a time. It is worthwhile switching from the first setup to the second setup only if it improves the query response times by more than three times.
|
|