Skip to main content

Performance Improvement in Hybris eCommerce

Below points will specially help grocery based projects where adding 50-60 products per cart is a common trend and where complex promotions are used using drools engine.

  1. Add/Update to cart  à In OOB Hybris whenever any new product is added to cart or quantity of existing product is updated in cart (from PLP, PDP, Search page etc) then calculateCart() method is called in order to calculate total price of the cart. This call can be prevented (to increase performance) in case the business requirement is to just show notification of add to cart without total price in minicart.

  1. View Cart à In case 50-60 products are added in cart and approx. 30% of the products have promotions applied then OOB Hybris view cart can take between 10-15 seconds to load (based on complexity of promotion). In order to avoid custom waiting 10-15 sec to see view cart this operation of can be split into below 3 steps so that every 3-4 seconds rendering of data starts and customer can see cart page data in parts.

    1. Step 1 : On click of minicart cart directly redirect (i.e. no wait of 15 sec) customer to cart page with just header, footer and loading(animation) icon in main content area with message that your cart is getting prepared.
    2. Step 2 : After step 1, trigger Ajax call to load list of cart entries including product name, image, quantity & price but without any promotion call as promotion messages ( potential or fired will not be shown at this instance). Also OOB recalculate() cart method is not called at this instance because we will not show total price, discount etc information at this stage.
    3. Step 3 : After step 2, trigger one more Ajax call to fetch list of promotions messaged per cart entry and also execute recalculate() cart to show total , subtotal & discount price.

  1. Caching Cart page promo messages : When potential promotion messages are shown per cart entry level then view cart can take significant time to load specially when promotions are complex and cart has 50-60 products added. In this case its recommended to cache potential promotion messages by creating dedicated EhCache and customization will be required to cache message per promotion id. (based on requirement).

  1. Promotion : As drools engine maintains multiple version of promotions, the entries in “promotion” and “droolsengine” increases exponentially so these tables should be cleaned regularly. Also custom promotion archival job should be created to archive (and undeploy) all versions of promotions rules that have end data in past.

  1. PLP /Search : Below recommendation are valid for both category & search page:

    1. In Product listing/Search page products are returned from solr and for each product several database calls are executed to fetch potential promotion messages, this can reduce the response time. Hence its always recommended to Index the Promotion messages in Solr to avoid all the database calls in the Category page (Product list page)/Search page. (Note : This might increasing solr indexing overall time).

    1. Implement Infinite Scroll approach for Category and Search pages: This approach consists in kind of pagination Solr calls triggered when user reaches end of page.

  1. Integrate SAP Page Caching AddOn: The Page Cache Solution Add-On is a set of extensions that enables the caching of HTML pages by adding a page cache container into the uppermost layer of the platform architecture to maximise performance. HTML pages won't be dynamically built, but instead will just be taken from the page cache container, meaning response times and CPU activity will decrease.

  1. Create explicit Entity Cache for PriceRows & AbstractRuleEngineRules : It is always advisable to create dedicated entity cache for item types that holds major space of the cache.

  1. HANA: Enable Prepared Statement caching :  The HANA JDBC Driver allows caching Prepared Statements. It is supported since driver version 2.3.4. This feature is disabled by default. Indexing time will also be improved with this change.

  1. Frontend optimization : Use free tool like GTmetrix to analyzes webpage page's speed performance. Tools like this uses PageSpeed and YSlow to generates scores of the pages and offers solutions to make site faster by offering suggestion like minification, gzip compression, media caching etc.

  1. Dynatrace : This tool helps a lot in identifying the bottlenecks of various pages/functionalities and with CCV2, Dynatrace is available externally (starting April 2019). This certainly opens doors to explore & optimize performance further.

Comments

Post a Comment

Popular posts from this blog

SmartEdit & its Personalization in Hybris

SmartEdit introduced  in 6.0 Hybris version and  Personalization (based on SmartEdit)  enabled in 6.1 Hybris version Onwards . SAP Commerce SmartEdit allows content managers to easily create and manage their website content on-the-fly in different inflection points and make it available to their customers with the click of a button. Personalization (based on SmartEdit) provides an integrated, user-friendly way of building experiences that are relevant to your customers, which is key to driving engagement and conversion.  Personalization encompasses modules and extensions that facilitate using Personalization Mode in SmartEdit to create a fully customized user experience. Personalization capabilities work across both content and commerce in an integrated way, so that you can build customer experiences consistently across channels and functionality. Using SmartEdit for Customer Experience, you can see the end-customer experience as...
Post a Comment
Read more

How does Disney Hotstar capture 5 Billion Emojis during a tournament?

  Here is my understanding of how the system works. 1. Clients send emojis through standard HTTP requests. You can think of Golang Service as a typical Web Server. Golang is chosen because it supports concurrency well. Threads in GoLang are lightweight.  2. Since the write volume is very high, Kafka (message queue) is used as a buffer. 3. Emoji data are aggregated by a streaming processing service called Spark. It aggregates data every 2 seconds, which is configurable. There is a trade-off to be made based on the interval. A shorter interval means emojis are delivered to other clients faster but it also means more computing resources are needed. 4. Aggregated data is written to another Kafka.  5. The PubSub consumers pull aggregated emoji data from Kafka.  6. Emojis are delivered to other clients in real-time through the PubSub infrastructure.  The PubSub infrastructure is interesting. Hotstar considered the following protocols: Socketio, NATS, MQTT, and gRPC, a...
Post a Comment
Read more