Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seem reindexing is Flusing magento page cache #38705

Open
2 of 5 tasks
ia-gaurav opened this issue May 7, 2024 · 9 comments
Open
2 of 5 tasks

Seem reindexing is Flusing magento page cache #38705

ia-gaurav opened this issue May 7, 2024 · 9 comments
Assignees
Labels
Issue: needs update Additional information is require, waiting for response Reported on 2.4.x Indicates original Magento version for the Issue report.

Comments

@ia-gaurav
Copy link

Preconditions and environment

We are using Redis for cache and page cache , after reindexing redis seems flushing page cache in redis

Steps to reproduce

1: wait for redis page cache size to grow
2: Key in page_cahe of redis is around 20 k
3: we did reindexing on magento php bin/magento index:reindex
4: Keys in page_cache went down from 20 k to around 1.5k

Expected result

Reindexing should not flush page_cache in redis

Actual result

Page_cache in redis is flushed with number of keys in page_cache database of redis goes down

Additional information

No response

Release note

No response

Triage and priority

  • Severity: S0 - Affects critical data or functionality and leaves users without workaround.
  • Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
  • Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
  • Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
  • Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Copy link

m2-assistant bot commented May 7, 2024

Hi @ia-gaurav. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:


Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

@m2-community-project m2-community-project bot added this to Ready for Confirmation in Issue Confirmation and Triage Board May 7, 2024
@engcom-Hotel engcom-Hotel added the Reported on 2.4.x Indicates original Magento version for the Issue report. label May 8, 2024
@engcom-Delta engcom-Delta self-assigned this May 9, 2024
Copy link

m2-assistant bot commented May 9, 2024

Hi @engcom-Delta. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

  • 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  • 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
  • 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
  • 4. Verify that the issue is reproducible on 2.4-develop branch
    Details- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
  • 5. Add label Issue: Confirmed once verification is complete.
  • 6. Make sure that automatic system confirms that report has been added to the backlog.

@engcom-Delta
Copy link
Contributor

Hi @ia-gaurav ,

Verified the issue on 2.4-develop and we see there is a decrement in the cache keys but we think it is as intended, as it is starting afresh.

Steps to reproduce:-

1: wait for redis page cache size to grow
2: Verify Key in page_cache of redis
3: Perform reindex on magento php bin/magento index:reindex
4: Keys in page_cache went down

We want know which keys shouldn't be deleted or cleared as particular, so that it will be easy to debug.

Please refer the attached screenshots

redis cache before reindexing

Screenshot 2024-05-14 at 6 18 07 PM Screenshot 2024-05-14 at 6 25 04 PM Screenshot 2024-05-14 at 6 25 16 PM

perform reindexing
Screenshot 2024-05-14 at 6 41 47 PM

redis cache after reindexing

Screenshot 2024-05-14 at 6 29 22 PM Screenshot 2024-05-14 at 6 30 14 PM

@engcom-Delta engcom-Delta added the Issue: needs update Additional information is require, waiting for response label May 14, 2024
@m2-community-project m2-community-project bot moved this from Ready for Confirmation to Needs Update in Issue Confirmation and Triage Board May 14, 2024
@engcom-Delta
Copy link
Contributor

Hi @ia-gaurav ,

Waiting for your reply on this issue to move further.

Thanks,

@ia-gaurav
Copy link
Author

yes - we should look for way to clear specific categroy or detail page cache instead of full cache flush,

Also for product details page is there way to ignore utm and show cached data

@hostep
Copy link
Contributor

hostep commented May 22, 2024

yes - we should look for way to clear specific categroy or detail page cache instead of full cache flush,

If you do a full reindex, it will go over every single product & category, so it makes sense that almost the entire cache will be emptied out. But a full reindex is something that almost never should happen on a production environment.

During normal operation, where you don't run a full reindex all the time, only products/categories that are changed will then cause a partial reindex and only a small amount of cache should get flushed.

Also for product details page is there way to ignore utm and show cached data

No idea if this is possible with Redis page caching, probably not, but switching to Varnish for FPC and using the default VCL Magento ships with, should already ignore the utm param from the query string and don't cause double unnecessary cache entries:

# Remove all marketing get parameters to minimize the cache objects
if (req.url ~ "(\?|&)(gclid|cx|ie|cof|siteurl|zanpid|origin|fbclid|mc_[a-z]+|utm_[a-z]+|_bta_[a-z]+)=") {
set req.url = regsuball(req.url, "(gclid|cx|ie|cof|siteurl|zanpid|origin|fbclid|mc_[a-z]+|utm_[a-z]+|_bta_[a-z]+)=[-_A-z0-9+()%.]+&?", "");
set req.url = regsub(req.url, "[?|&]+$", "");
}

@ia-gaurav
Copy link
Author

@hostep thank for you valuable information ,

1: is there way i can ignore marking query string using redis FPC
2: is there way to do reindeing for specific category ids only

@hostep
Copy link
Contributor

hostep commented May 22, 2024

  1. probably not, unless you write some custom code yourself (or find a module that has already done that)
  2. yes, don't run a full reindex manually and let the system handle it for you (when indexers are set to "update by schedule" mode, and you've setup the crontab correctly to run once per minute, than the indexers will only index entities (products/categories) that were recently changed)

@ia-gaurav
Copy link
Author

@engcom-Delta @engcom-Hotel - can you please guide how to ignore marketing query string for Redis FPC also can this be added in future releases as it cause issues with high server response time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: needs update Additional information is require, waiting for response Reported on 2.4.x Indicates original Magento version for the Issue report.
Projects
Development

No branches or pull requests

4 participants