Most Recent

Friday, May 29, 2020

how to Troubleshoot performance issue in ATG-Endeca Integration?

As part of peak load or during load test if following symptoms are seen in ATG-Endeca integration. Out of Memory in store instance. Sto... thumbnail 1 summary
    • As part of peak load or during load test if following symptoms are seen in ATG-Endeca integration.

    1. Out of Memory in store instance.
    2. Store instance takes lots of time to process a request.
    3. Promote content from Endeca takes lots of time to apply
    4. Dgraph CPU usage looks correct and no issue seen in Dgraph instance.
    5. High network I/O in Dgraph instance.



    Troubleshoot`/Debug from Endeca/Assembler side

    1. Get Dgraph request log from all Dgraph instance. Dgraph log can find out under below folder /LLM/logs/dgraphs/<<Dgraph_Name>>/<<Dgraph_Name>>.reqlog.

    2. Run Request log analyzer to see the issue at each Dgraph level. Following parameters needs to be observed from log analyzer output

    • Query Queueing time - See if Thread size is defined correctly for Dgraph
    • Query response delay in Dgraph
      • Get MDEX statistics using http://<Draph_server>:<port>/admin?op=stats.
    • Endeca MDEX Performance Statistics
    • Large Response Size 
      • Unnecessary supplement objects are getting returned from Assembler Cartridge
      • Select clause in ResultsList/Spotlight cartridge not used to get Endeca record object from Dgraph
    Endeca Statistics Large Endeca query response Size


    Click here to see Endeca Query Performance Tuning

    Click here to see Slow Query Response Time

    Click here to see Cartridge select clause implementation


    Troubleshoot/Debug from ATG side

    1.Enable loggingDebug on the following components and try to replicate the issue.

    • /atg/endeca/assembler/AssemblerTools
    • /atg/endeca/assembler/NucleusAssemblerFactory
    • /atg/endeca/assembler/AssemblerPipelineServlet
    2. Enable Performance Monitor in ATG store insatce for some times and collect information to debug it further and turned it off.

    3. Run Top Command to see which process is taking more time.

    4.  See if port 8007 has number of connection due to promote content. This is set as part of /atg/endeca/assembler/cartridge/manager/DefaultWorkbenchContentSource componet.


    From Author

    Was this post resolve the solution you are looking for? am I missing any points that can be added here?
    Provide your comments

    Tuesday, April 5, 2016

    Endeca Performance Tuning : Slow Query response time

    Endeca maintains internal Dgraph cache at Dgraph level. Endeca Dgraph cache gets flushed during baseline and partial update process. Behavi... thumbnail 1 summary
    • Endeca maintains internal Dgraph cache at Dgraph level. Endeca Dgraph cache gets flushed during baseline and partial update process.

     Behaviour

     Most of the client utilize Endeca partial update, for inventory update , product updates etc., in every 30 minutes or so. There could be a possibility to have slow Endeca query response time and delay to process the request. 

     Solution

     Dgraph performance can be improved by warming the internal Dgraph cache after an update has been processed. 

     Specify the --warmupseconds <seconds> flag to the Dgraph to warp the Dgraph Cache. The --warmupseconds flag instructs the Dgraph to store a client sample queries, and after an update is
    processed, the Dgraph internally re-runs a sample of those queries to warm the cache.

     All warming query URLs are tagged with the additional parameter &log=warming in Dgraph request logs.


    Click here to view Endeca Query Performance issues and Fixes.


    From Author

    Was this post resolve the Endeca Performance issue? what do you think, making above steps may resolve most of the issues? Provide your comments

    Friday, March 18, 2016

    Oracle Endeca : Return All Levels of a Hierarchical Dimension With a Single Record Search Query

    In application, the catalog tree are stored in a hierarchical tree structure in Endeca (a hierarchical dimension). Only the top level dimens... thumbnail 1 summary
    • In application, the catalog tree are stored in a hierarchical tree structure in Endeca (a hierarchical dimension). Only the top level dimension values are returned from the hierarchy during record search query. 

     Currently in a record search it is not possible to return all intermediate and leaf dimension values from all levels (essentially a whole "branch" of the tree hierarchy) with one query. It would require multiple queries to return dimensions values that were beneath the top level of the hierarchy in the left-navigation of a record search.

     Find out the way below to solve above issue:-

     The Dimension Search feature does allow you to return all dimensions values for a Dimension with the D=* and the Di= parameter where Di is a dimension ID, but this is a different mechanism than the Dimensions that are returned for the left-navigation of a regular record search. The Dimension search feature search againest only dimension values and fires a light weight query.

    Wednesday, March 16, 2016

    Oracle Endeca x.x - Search query processing order in MDEX

    This section summarizes how the MDEX Engine processes record search queries. The process outlined here assumes that other features (such as ... thumbnail 1 summary
    • This section summarizes how the MDEX Engine processes record search queries.
    The process outlined here assumes that other features (such as spelling correction and thesaurus) are being used.

     The MDEX Engine uses the following high-level steps to process record search queries:

     1. Record filtering
    2. Endeca Query Language (EQL) filtering
    3. Auto-correction (spelling correction and automatic phrasing)
    4. Thesaurus expansion
    5. Stemming
    6. Primitive term and phrase lookup
    7. Did you mean
    8. Range filtering
    9. Navigation filtering
    10. Business rules and keyword redirects
    11. Relevance ranking

     Step 1: Record filtering
    If a record filter is specified, whether for security, custom catalogs, or any other reason, the MDEX Engine applies it before any search processing.The result is that the search query is performed as if the data set only contained records allowed by the record filter.

     Step 2: Endeca Query Language filters
    The Endeca Query Language (EQL) contains a rich syntax that allows an application to build dynamic,complex filters that define arbitrary subsets of the total record set and restrict search and navigation results to those subsets. If used, this feature is applied after record filtering.

     Step 3: Auto-correction (spelling correction and automatic phrasing)
    If spelling correction and automatic phrasing are enabled and triggered, the MDEX Engine implements them as part of the record search processing.If the spelling correction feature is enabled and triggered, the MDEX Engine creates spelling suggestions by enumerating (for each query term) a set of alternatives, and considering some of the combinations of term alternatives as whole-query alternatives.

     Step 4: Thesaurus expansion
    The tokenized query, as well as each query alternative generated by spelling suggestion, is expanded by the MDEX Engine based on thesaurus matches. This topic describes the behavior of the thesaurus expansion feature.
    Thesaurus expansion replaces each expanded query term with an OR of alternatives.
    For example, if the thesaurus expands pentium to intel and laptop to notebook, then the query pentium laptop will be expanded to: (pentium OR intel) AND (laptop OR notebook) assuming the match mode is MatchAll.

     Step 5: Stemming
    Query terms, unless they are delimited with quotation marks to be treated as exact phrases, are expanded by the MDEX Engine using stemming.

    Step 6: Primitive term and phrase lookup
    Primitive term and phrase lookup is the lowest level of search processing performed by the MDEX Engine.

    Step 7: Did You Mean
    The MDEX Engine performs the "Did You Mean" processing as part of the record search processing."Did You Mean?" processing is analogous to the spelling correction and automatic phrasing processing, only that the results are not included, but rather the spelling suggestions and automatic phrases themselves are returned.

    Step 8: Range filtering
    Range filter functionality allows a user, at request time, to specify an arbitrary, dynamic range of values that are then used to limit the records returned from a navigation query. Because this step comes after "Did you mean?" processing, it reports the number of records before filtering.

    Step 9: Navigation filtering
    The MDEX Engine performs all filtering based on the navigation state after the search processing.This order is important because it ensures that the spelling suggestions remain consistent as the navigation state changes.

    Step 10: Business rules and keyword redirects
    Dynamic business rules employ a trigger and target mechanism to promote contextually relevant records to application users as they search and navigate within a data set. Keyword redirects are similar to dynamic business rules also use trigger and target values. However, keyword redirects are used to redirect a user's search to a Web page (that is, a URL). These features are applied after navigation filtering.

    Step 11: Relevance ranking
    Relevance ranking is the last step in the MDEX Engine processing for the record search. Each of the navigation-filtered search results is assigned a relevance score, and the results are sorted in descending order of relevance.

    Click here to get more topics related to Endeca basic concepts.

    Tuesday, March 15, 2016

    Oracle Endeca SEO - Avoid repository calls for category pages.

    Category pages require data like page title, keywords description for search engine optimization(SEO) from the category repository. There... thumbnail 1 summary
    • Category pages require data like page title, keywords description for search engine optimization(SEO) from the category repository.

     There are ways to get SEO specific information. ATG-Endeca Integration creates a product.category hierarchical dimension. OOTB integration does not add SEO related attributes/properties to the product.category dimension. As per best practices, get all SEO data using Endeca product.category dimension instead of making repository calls to ATG.

     Endeca provides a  feature to add properties to dimension and it can be added during data export from ATG process. Oracle Endeca commerce out of box provide below attributes:

     product.category > Women--;{DGraph.Spec=cat50001, category.ancestorCatalogIds=masterCatalog, category.catalogs.repositoryId=masterCatalog, category.repositoryId=cat50001, category.rootCatalogId=masterCatalog, category.siteId=storeSiteUS, record.id=atgrep:/ProductCatalog/category/cat50001?catalog=masterCatalog&categoryPath=/cat50001&locale=en_US}

     Add more Attributes to Product.category dimension

     Find out following steps :-

     1. /atg/commerce/endeca/index/CategoryToDimensionOutputConfig use category-dim-output-config.xml to add attributes. Create this file in another layer configuration and add required attributes and properties.

     2. Build Project.

     3. Run baseline from /atg/commerce/endeca/index/ProductCatalogSimpleIndexingAdmin. No coding required from handler perspective.

     4. Go to JSP and use code
        ${category.properties['category.title']}

     Find out the sample XML below :-

     <?xml version="1.0" encoding="UTF-8"?>

    <item item-descriptor-name="category" is-document="true">
      <text-properties>
         <property name="keywords" output-name="dimval.prop.category.keywords" type="string" is-multi="true" xml-combine="replace"/>
         <property name="longDescription" output-name="dimval.prop.category.longDescription" type="string"/>
         <property name="title" output-name="dimval.prop.category.title" type="string"/>
         <property name="noindex" output-name="dimval.prop.category.noIndex" type="boolean"/>
         <property name="noFollow" output-name="dimval.prop.category.noFollow" type="boolean"/>
      </text-properties>
    </item>
    Click here to get more information related to ATG-Endeca Integration.

    Thursday, March 10, 2016

    How Experience manager contents are Managed over multiple version and integrated with Assembler API?

    Business users use Endeca experience manager to create multiple pages using page templates, cartridges, page slot and content slots. Onc... thumbnail 1 summary

    • Business users use Endeca experience manager to create multiple pages using page templates, cartridges, page slot and content slots. Once contents get previewed, Contents needs to push from authoring to Live.

    As part of publishing content from authoring to live, ITL makes a /ws/config web-service call to each Dgraph and push updated pages, rules,thesaurus, keyword redirects and phrases to graphs. 

    Oracle commerce 11.2 Release resolved query response size issue.Find out reason below in the post.
    Sample lightweight query from 11.2 
    /graph?node=0&offset=0&nbins=0&opts=xsearchreport&log=reqcom%3dMdexContentRequestBroker&irversion =652

    Following changes can be seen over the period of multiple releases.

    Endeca 3.1.1 and 3.1.2 -  

    1. All Site pages are managed in Endeca IFCR repository.
    2. All Rules contents under Shared contents are managed in Dgraph. Each Rule contains meta-data, all cartridges, any HTML content and everything gets pushed to Dgraph. Each Rule size generally around 4-10 KB average.
    Find out sample content XML node for a rule at end of post

    Endeca 11.1 - 

    1. All Site pages and Rule content are managed in the zip file and zip file available to all application server.
    2. All Rules metadata under Shared contents are managed in Dgraph. Only Content Meta-data pushed to Dgraph Engine. Each Rule size generally around below 1 KB.

    Find out sample content XML node for a rule at end of post

    Endeca 11.2 - 

    All Site pages and Rule content with metadata are managed in a zip file and zip file available to all application server. Application server caches all rules in memory. 


    As per my one of the previous blogs explain how assembler works.

    Assembler makes  a super-lightweight query is executed that only returns Supplemental objects representing rules, location, properties name and few other information from Experience Manager.

    This query gives average response size over multiple versions below for 20 rules:-

    Endeca 3.1.1 and 3.1.2 -  Endeca query response size 160 KB.

    Endeca 11.1 -  Endeca query response 8 KB.

    Endeca 11.2 -  Endeca query response 0 KB as the call not required to get content however still makes a lightweight query to get other information.

    Published Content XML to Dgraph

    Endeca 3.1.1 and 3.1.2

    <sv:node sv:name="Test">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>endeca:unstructured</sv:value>
    </sv:property>
    <sv:property sv:name="contentType" sv:type="String">
    <sv:value>Page</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:created" sv:type="Date">
    <sv:value>2016-02-05T03:09:29.807-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:createdBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModified" sv:type="Date">
    <sv:value>2015-07-28T08:26:36.479-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModifiedBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    <sv:property sv:name="sling:resourceType" sv:type="String">
    <sv:value>endeca/page</sv:value>
    </sv:property>
    <sv:node sv:name="content.xml">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>nt:file</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:created" sv:type="Date">
    <sv:value>2016-02-05T03:09:29.807-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:createdBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    <sv:node sv:name="jcr:content">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>nt:resource</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:uuid" sv:type="String">
    <sv:value>1bba4fdc-e0ac-4df4-9e49-34a2289a8c1a</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:data" sv:type="Binary">
    <sv:value>PENvbnRlbnRJdGVtIHR5cGU9IlBhZ2UiIHhtbG5zOnhzaT50SXRlbUxpc3Q+CiAgPC9Qcm9wZXJ0eT4KPC9Db250ZW50SXRlbT4=</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModified" sv:type="Date">
    <sv:value>2015-07-28T08:26:36.479-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModifiedBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    </sv:node>
    </sv:node>
    </sv:node>


    Endeca 11.1: - This Does not contain Binary property as this contains rule data.

    <sv:node sv:name="Test">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>endeca:unstructured</sv:value>
    </sv:property>
    <sv:property sv:name="contentType" sv:type="String">
    <sv:value>Page</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:created" sv:type="Date">
    <sv:value>2016-02-05T03:09:29.807-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:createdBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModified" sv:type="Date">
    <sv:value>2015-07-28T08:26:36.479-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModifiedBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    <sv:property sv:name="sling:resourceType" sv:type="String">
    <sv:value>endeca/page</sv:value>
    </sv:property>
    <sv:node sv:name="content.xml">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>nt:file</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:created" sv:type="Date">
    <sv:value>2016-02-05T03:09:29.807-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:createdBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    <sv:node sv:name="jcr:content">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
    <sv:value>nt:resource</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:uuid" sv:type="String">
    <sv:value>1bba4fdc-e0ac-4df4-9e49-34a2289a8c1a</sv:value>
    </sv:property>
    \<sv:property sv:name="jcr:lastModified" sv:type="Date">
    <sv:value>2015-07-28T08:26:36.479-05:00</sv:value>
    </sv:property>
    <sv:property sv:name="jcr:lastModifiedBy" sv:type="String">
    <sv:value>admin</sv:value>
    </sv:property>
    </sv:node>
    </sv:node>
    </sv:node>

    Endeca 11.2: No content gets pushed to Dgraph

    Wednesday, March 9, 2016

    Oracle Endeca Dgraph Performance Tuning

    Find out steps below to resolve Endeca Dgraph Performance issue using Dgraph Flags or minimal configuration. Thread Count By Defaul... thumbnail 1 summary
    • Find out steps below to resolve Endeca Dgraph Performance issue using Dgraph Flags or minimal configuration.

     Thread Count

    By Default, Endeca configuration set dgraph thread count as 2. This can be changed to based on Number of core – 3 in DgraphDefaults.xml
          <arg>--threads</arg>
          <arg>2</arg>


    –whymatch debug flag

    Endeca App default sets --whymatch flag as true. 
    This flag is used for debugging, why a particular record is being returned and why it matched. This flag is not recommended for production environment.


    --cmem flag

    The Dgraph cache is used to dynamically cache query results.
    The default Dgraph cache size (specified by the --cmem flag) is 1024MB (1GB).
    This flag needs to be tuned at least double the index size to get better performance.

    Optimal use of dgraph group while setting up dgraph live cluster

    restartGroup property under dgraph node in LiveDgraphCluster.xml is used to push indexes to all dgraphs that fall under the same group. Value can be defined as A or B or any character. Make sure to create two groups of 50% each both for baseline and partial. 
    updateGroup is used for partial updates.



     Click here to view Endeca Query Performance issues and Fixes.


    From Author
    Was this post resolve the Endeca Performance issue? what do you think, making above steps may resolve most of the issues? Provide your comments

    Endeca Query Performance Tuning for optimal performance

    Find out the solutions below to resolve the Endeca Query performance issues . Following latest patches needs to be applied: - Patch 1734267... thumbnail 1 summary
    • Find out the solutions below to resolve the Endeca Query performance issues.

     Following latest patches needs to be applied: -

    Patch 17342677 : It reduces the number of supplemental objects that are returned by the queries, which helps performance. This is for ATG 10.1.2 and 10.2  and corresponding Assembler 3.1.1 and 3.1.2.To verify that the patch was correctly installed, make sure the request logs start including the following with the requests: &merchrulefilter=endeca.internal.nonexistent


    Verify properties and dimension returned by Endeca query response: -

    Properties/Dimension can be set as part of Endeca query fired by cartridge handlers. Cartridge handlers uses /atg/endeca/assembler/cartridge/handler/config/ResultsListConfig.properties from ATG to pass it to Endeca. Endeca would return all properties If fieldNames property is null in mentioned component.


    Records Per Aggregate Record set to one

    By Default, record per aggregate is set to ALL in ATG and this would bring all records for rolled up records including representative record.


    Verify if Preview is not enabled in Production

    /dyn/admin/nucleus/atg/endeca/assembler/cartridge/manager/AssemblerSettings: Verify if previewEnabled = false for production environment. Setting this to true will return back lots of merchandized rule data with the results. You can confirm this by looking at the Dgraph.reqlog, and looking for merchdebug=true in the queries.


    Use Endeca user segments in multisite environment.

    Content include cartridge makes a blanket query to endeca to fetch all possible rules from dgraph for given navigation state. This query would be find out in request log
    /graph?node=0&profiles=site.<<site_name>>&offset=0&nbins=0&irversion=640.
    Use site user segment always to get unwanted content as part of above query and this increases the response size.


    Don't expose all dimensions

    Never use ENEQuery.setNavAllRefinements(true). Using true would be very expensive in terms of response time and size too. Use UrlENEQuery.setNe() and pass in a string like "123+234+532".
    Looking through .reqlog, if you see &allgroups=1, that means somewhere someone has setNavAllRefinements(true).
    Click here to view Dgraph Performance Tuning


    From Author
    Was this post resolve the Endeca Performance issue? what do you think, making above steps may resolve most of the issues? Provide your comments

    Text Widget