Showing posts with label Endeca Design and Best Practices. Show all posts
Showing posts with label Endeca Design and Best Practices. Show all posts

Endeca Tips for troubleshooting long processing time - Core Endeca

         Is the long processing time for the Engine caused by limitations of hardware resources? 
o Identify whether long query time is caused by CPU, memory, or disk I/O utilization.

          Is a high number of records being returned by the MDEX Engine?
o Identify how many records are being returned per query by looking for large nbins values in queries as reported by Cheetah(Performance Monitoring Tool).  If this number is high, this can be expensive to compute and affects performance.

          Are all dimension refinements (dimension values) exposed for navigation? 
o Identify whether all dimension refinements are exposed by looking forallgroups=1 in the Dgraph request log (request URL parameter) or in Cheetah reports 

          Are your longest queries similar?
o Check the longest queries for similarities, such as whether they all use the same search interface with relevance ranking, wildcard search, or record filters.

          Is record search being used?
o Identify whether a record search is being used by any queries by looking for “attrs=search_interface_name” in a query. This indicates that a record search is being used which means that possibly expensive relevance ranking modules can be contributing to high computation time

          Which relevance ranking strategies are being used?
o Check the CRS.relrank_strategies.xml file for the presence of Exact, Phrase and Proximity ranking modules and test the same query with these modules removed.

          Is sorting enabled for properties or dimensions?
o Identify whether sorting with sort keys is enabled, for which properties and dimensions it is being used and whether it is needed. 
o The first time a sort key is issued to a Dgraph after startup the key must be computed which can slow down performance. To isolate this problem, test the query in the staging environment by removing the sort key. 
o If you confirm sort keys are the issue, consider using sort keys in a representative batch of queries used to warm up the Dgraph after startup. 
o The sorts will become cached and these queries will be faster. 

How to Handle Special Characters in Search? - Endeca Best Practices

Endeca uses only alphanumeric characters to be searchable by default as part of Endeca search query.

Problem Statement:
If any search term contains any special characters then Endeca replaces special characters by "space" and makes endeca query. This may not give intended results.

Ex: If a search term is β Antibody, Endeca internally replaces search term special chars with space and search term would be Antibody".

Solution:
For Forge-based Application:
1. Open  /opt/app/endeca/apps/CRS/config/pipeline/CRS.search_chars.xml

2.  Add all characters that you want to make searchable.
3.  Run baseline
update 


For Forge-less  Application:
1. Open  /opt/app/endeca/apps/CRS/config/mdex/CRS.search_chars.xml
2.  Add all characters that you want to make searchable.
3.  Run baseline
update


Pipeline Changes Looks like as below:

Managing users in the Workbench - Best practices

Oracle recommends the following best practices for managing users in the Workbench -

• Consider adding all users to groups to make managing permissions simpler

• Do not share the predefined admin user account. This makes it difficult to track who has made changes to Workbench. Create an account for each user or group that administers Workbench

• Do not let business users share accounts. Again, this makes it difficult to track changes in Workbench

• Create administrators in addition to the predefined admin. If one administrator loses a password, another administrator needs to reset it

• If you use LDAP, consider creating an LDAP group of administrators to add to the Administrators group in Workbench

Endeca Search and Browse Features : Search Within

The search within function enables users to find specific information within an existing search result set.

Benefits and Usage:
Use the search within function when:
  • Users prefer or expect keyword search refinement to reach specific information targets.
  • The body of content is large or rich enough that the risk of returning no results is minimized, and keyword search refinement will most likely enable users to quickly find specific targets.

Example:
User Searches for "Metal Detector" 



Further user wants to search specific information within search result set and searches for "alminum"


Challenges:
  • If the search and search within functions are both accessed through a common search box, users may have difficulty recognizing and distinguishing between the two functions.
  • The search within function can generate no results, unlike faceted navigation.