Search Latency:
No. of hits returned – The fewer hits to be returned the less searching required and the less sorting by the QR server.
No. of partitions – Excessive numbers of buckets will take a lot longer to search.
Dedicated Server – Searching is resource hungry so avoid placing Crawling and Doc Processing nodes on the same server as they compete for the same resources.
Feeding Rate – If the feeding rate is too high, the cache is flushed regularly so we cannot benefit from quick retrieval.
Disk Speed – Search requires a high number of reads so the disks must be 15K RPM Scuzzy at the very least.
4GB+ RAM – With more RAM we can cache results in memory to provide faster retrieval rates. caching to increase performance
Quad-Core – Using a quad core CPU will enable us to maintain a high QPS even when several users are searching simultaneously.
QR Pipeline – We can remove superfluous stages from the QR pipeline in order to reduce search latency. Avoiding unnecessarily large dictionary loads similar to the document processing pipeline will reduce latency.
Documents per node – The less documents we squeeze onto a box the better search performance we will get.
Offset Size – The more results we request the more search computation and also the greater the clogging of the network pipe. If all 1000 users are bringing back 4000 results for each query we start to diminish query performance.
Multiple Rows – By replicating the index by having additional rows we can start to serve queries in parallel as well as providing redundancy.
Query Complexity – The more specific the query the less work the QR server has to do to split it out into its different permutations.
Search Feature Enablement – Enable query and search features only if necessary.
wildcards/Lemmatization – These increase indexing time, CPU and disk usage as well as QPS. This is because it takes a longer time to generate the different permutations of a query, and a longer time to look up all these queries on disk.
deep navigators – Navigators increases memory usage & latency. The more unique navigator values the worse as more calculation is required.
binsize – By reducing the bin size we calculate the rank for fewer documents and thus reduce latency. Too low can compromise ranking accuracy.
neocollapse – Collapsing is memory intensive. The more results we need to collapse on the more memory we require. If there is not enough memory available collapsing operations are queued.
scope search – Again, The more specific the query the less work the QR server has to do to split it out into its different permutations.
Deployment Considerations – Content Volume:
Finally, the last deployment consideration is content volume. When optimizing for large data volumes, the goal is to build a system using as few servers
as possible still providing the required capabilities in terms of performance (both feeding
and search) and fault tolerance.
Optimizing Disk Space - If the Indexer node runs out of disk space, it will not be possible to index new content.
Disk usage per document is decided by a combination of the index profile and the size of the submitted documents.
Disk space is used to store the documents (in data_fixml) before indexing, and to store both completed indices and indices under construction.
Document sizes – In many cases we do not need the entire data from the source content. We can often strip out formatting noise.
Index expansion - The more content side linguistic expansion required the larger the index will grow as the target keywords are expanded.
Available memory – By having too many navigators and sortable fields we can steal memory from the indexers. The limiting factor when building large indices will often be the memory usage of the indexing or search processes. If indexing takes up too much memory, this will lead to repeated indexing failures, and it will be impossible to successfully index the content.
If a finished index takes up too much memory when searching, this will be seen as repeated search failures preventing successful search.
No. Of Partitions – The memory usage during both indexing and search always applies to each partition individually. Therefore, to be able to hold more documents per host, it is beneficial to spread the documents across more than one partition. For example, if a partition can hold at most 5 million documents before it runs out of resources, it is still possible to index 15 million documents on the host by spreading the documents evenly across 3 partitions.
No comments:
Post a Comment