How to login to Endeca Workbench, Select application and Experience manager? - Endeca Experience Manager

Experience Manager:  
Manages the presentation layer. Manage the customer experience by creating and modifying dynamic pages and content items. 
 Steps:
1)  Go to Endeca workbench URL
           Ex: http://localhost:8006
2) Use default username password admin/admin

3)  How to select application?
Once logged in, you will need to select your application. Hover over Administrative Tools area in upper left and Select application Ex: CRS

- Choose your application and click on Experience Manager

Oracle Commerce - ATG-Endeca Integration

ATG v10.1.1 and Endeca v3.1.0 Integration:
http://docs.oracle.com/cd/E35318_02/Platform.10-1-1/ATGEndecaIntegrationGuide/ATGEndecaIntegrationGuide.pdf

ATG v10.1.2 and Endeca v3.1.1 Integration:
http://docs.oracle.com/cd/E36434_01/Platform.10-1-2/ATGEndecaIntegrationGuide/ATGEndecaIntegrationGuide.pdf

ATG v10.1.2 and Endeca v3.1.2 Integration:
Version 10.2  : http://docs.oracle.com/cd/E35319_01/Platform.10-2/ATGEndecaIntegrationGuide/ATGEndecaIntegrationGuide.pdf

 Oracle Commerce v11.0: 
Version 11:  http://docs.oracle.com/cd/E41069_01/Platform.11-0/ATGEndecaIntegrationGuide/ATGEndecaIntegrationGuide.pdf

Oracle Commerce v11.1:
Version 11.1: https://docs.oracle.com/cd/E52191_02/Platform.11-1/ATGEndecaIntegrationGuide/ATGEndecaIntegrationGuide.pdf

Timeline and Release information:

Using Load balancer with Endeca - Best Practices

For all deployment architecture oracle recommends below best practices:  

1) Use load balancers with the MDEX Engine to increase throughput and ensure availability in the  event of hardware failure. 

2) Oracle recommends including two hardware-based load-balancing switches configured redundantly in your configuration. Having two load balancers ensures their availability in the event of a load balancer hardware failure.

3) Use http://[host]:[port]/admin?op=ping to check Dgraph availability in load balancer script and if it is not running then Load Balancer directs queries to the MDEX that is currently available.

4) Use "least connections"model algorithm for balancing traffic to the Dgraphs  

5) Make sure the response from Dgraphs is redirected directly to the client tier and does not pass back to the load balancer hardware.

Endeca Dimension search Performance Tuning - Best Practices

Performance of dimension search directly depends on number of dimension values and size of the resulting set of matching dimension values. If Dimension values returned are more than 1000 then it will cause big performance hit.
Compound dimension search is more expensive than non-compound request. if you are not using compound dimension feature then disable it. Here is the link on how to disable it:
http://ravihonakamble.blogspot.com/2015/07/endeca-few-items-on-dgrpah-side-to.html
 
In both the cases, You can limit the results by using advanced dimension search parameters.
Ex: Di parameter to specify the specific dimension or list of Dimension value Id's. 

D=avengers&Di=11378
D= Dimension Query Search Term
Di= One or more ID's of dimensions to search against

Endeca Search and performance Impact - Record Search|Wildcard Search|Boolean Search|Phrase Search

Record Search:
Record search is an indexed feature, each property enabled for record search increases the size of the Dgraph process. Only properties that are needed by an application for record searching should be configured.
Use Endeca Set Selection feature :  http://ravihonakamble.blogspot.com/2015/06/endeca-select-feature-aka-set-selection.html

Wildcard Search:
If wildcard search is enabled in the MDEX Engine (even if it is not used by the users), it increases the time and disk space required for indexing. Therefore, consider first the business requirements for your Endeca application to decide whether you need to use wildcard search. 
Recommendations:
1) Avoid wildcard searches with one non-wildcarded character, such as a* , since they are more expensive to process
2) Parse the queries to calculate their search term length to avoid very low information queries, such  as "a*". Avoid MDEX Engine wildcarding queries that contain fewer than 3 non-wildcarded characters. 
3) Remove all non-searchable characters from each wildcard query before issuing it to the MDEX Engine 
4) Exclude wildcard queries with quoted phrase searches.
FYI 
If search queries contain only wildcards and punctuation, such as *.* , the MDEX Engine rejects them for performance reasons and returns no results. 

Boolean Search:
 The performance of Boolean search is a function of the number of terms and operators in the query and also the number of records associated with each term in the query. As the number of records increases and as the number of terms and operators increase, queries become more expensive. If you notice unexpected behavior while using Boolean search, use the Dgraph-v flag when starting the Dgraph. This flag prints detailed output to stderr describing the running Boolean query process.

Phrase Search:

The cost of phrase search operations depends mostly on how frequently the query words appear in the data and the number of words in the phrase. You can improve performance of phrase search by limiting the number of words in a phrase with the --phrase_max <num> flag for the Dgraph. 

Using this flag improves performance of text search with phrases. The default number is 10. If the maximum number of words in a phrase is exceeded, the phrase is truncated to the maximum word count and a warning is logged.