Have the elasticsuite tracker hit return the empty HTTP/200 response to the client, asynchronously performing the recording of the hit, to improve performance

[dufrygrant]

We are currently using the Elasticsuite product on a Magento 2.2.x site.

Each page is performing a hit to the h.png file (in reality, the tracker URL), but this ordinarily takes ~1.5 seconds to return the empty HTTP/200 response to the user.

Can this in future be refactored to return the HTTP/200 response to the user 'early' (ie not synchronously waiting for the recording of the hit with ElasticSearch to return successfully, unless the product is in some sort of debug mode to deliberately force the current behaviour)?

The issue is that the user's browser is needing to wait for the infrastructure backend when it does not need to (ie no meaningful data is being provided back to the client).

Example hit:
https://bengaluru.websitename.com/en/elasticsuite/tracker/hit/image/h.png?page[store_id]=92&page[type][identifier]=brandboutique_brand_index&page[type][label]=&page[product_list][page_count]=1&page[product_list][product_count]=6&page[product_list][current_page]=1&page[product_list][sort_order]=position&page[product_list][sort_direction]=asc&page[product_list][display_mode]=grid&session[uid]=xxxxxxx-31b8-9b4f-f08e-b54438ca63a1&session[vid]=xxxxxx-1802-0398-e5b3-d82be00ca14c&page[site]=bengaluru.websitename.com&page[url]=%2Fen%2Fbrands%2Fbacardi&page[title]=Bacardi%20%7C%20Duty%20Free%20Bengaluru%20Airport%20Shops&page[referrer][domain]=bengaluru.websitename.com&page[referrer][page]=%2Fen%2Fbrands%2Fabsolut&page[resolution][x]=1920&page[resolution][y]=1160

[southerncomputer]

might be your backend is congested.. I'm only seeing avg 80ms response!

[rbayet]

Hello @dufrygrant,

@southerncomputer points something I thought about yesterday : are your crons running correctly ?

There may be a situation where the events are stacking into the dedicated DB elasticsuite_tracker_log_event table without being flushed regularly into the Elasticsearch dedicated indices.

Regards,

[romainruaud]

This cronjob should empty the table regularly : https://github.com/Smile-SA/elasticsuite/blob/2.8.x/src/module-elasticsuite-tracker/etc/crontab.xml#L20

But can you please give us the detailed version of ElasticSuite you are using ?

[dufrygrant]

2.6.9 on Magento 2.2.9

Ran that specific cron job; no luck - size did not reduce (of the table); I'm presuming the speed of the hit (the original question) remains unchanged.

Considering the table is now 3Gb+ in size, any possibility of an interaction with this?
#1110

(It seems there is an interaction; 2.6.9 has the 10k 'chunk size' patch in it, but it seems we need to be running the cron more frequently; I'll queue it up and then re-update tomorrow to see where we're up to on both table size and performance)

Update: The # of rows is dropping; 10k at a time. We're a rather busy site so we've upped it to 30k per chunk and it seems to be running fine. Waiting until the total rows in that table drop before advising on the performance increase.

[southerncomputer]

one thing you can do is wrap the sendtag calling function in a delay setTimeout to push it back after pageload to make it appear less blocking..

setTimeout( function(){ smileTracker.sendTag();},10000);

[no-response]

This issue was waiting update from the author for too long.
Without any update, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.