Magento Block Cache Queue For High Traffic Sites

简介:

This is the initial release. It has been tested in a few production environments, but as always use with caution and keep checking the Github repo

Requirements

What does this fix?

If you have a high traffic magento site this modification will ensure that a non-cached block is only being called once, so it can be properly cached and served to all users requesting said block.

Example Scenario:

> Single core machine. 
> Magento Nav Bar with 150 categories which takes about 0.5 seconds to generate for 1 user.

Lets assume that your Magento Block cache has recently been cleared by either Admin or Updates to your catalog (IE. Deleting Categories, Updating Products, etc). Immediately 5 users visit your homepage at the same time.Apache/Magento gets the requests and starts to render your Homepage block by block for all users simultaneously. For arguments sake lets say that the Navigation Block is the heaviest item to load because your navigation bar contains a category drop down with 150 Parent/Child elements. Normally this means that all 5 users will request from the database and then loop through the collection to generate the HTML.

Completing the nav bar block takes about 0.5 seconds for 1 user. But since we have 5 concurrent users it decreases the total CPU power available and now it takes roughly 5 times as long to generate each request.

User 1 <-- Queries the database and generates HTML (20% CPU Load) - 2.5 seconds 
User 2 <-- Queries the database and generates HTML (20% CPU Load) - 2.5 seconds 
User 3 <-- Queries the database and generates HTML (20% CPU Load) - 2.5 seconds 
User 4 <-- Queries the database and generates HTML (20% CPU Load) - 2.5 seconds 
User 5 <-- Queries the database and generates HTML (20% CPU Load) - 2.5 seconds 
Total time: 2.5 seconds

Solution

With this modification the request takes slightly longer for 1 user but the benefits come in when you have concurrent users.

User 1 <-- Queries the database and generates HTML (100% CPU Load) - 0.6 seconds 
User 2 <-- (Wait) Retrieve HTML from User 1 (0% CPU Load) - 0.7 seconds 
User 3 <-- (Wait) Retrieve HTML from User 1 (0% CPU Load) - 0.7 seconds 
User 4 <-- (Wait) Retrieve HTML from User 1 (0% CPU Load) - 0.7 seconds 
User 5 <-- (Wait) Retrieve HTML from User 1 (0% CPU Load) - 0.7 seconds 
Total time: 0.7 seconds

Since user 1 has 100% of the CPU available it is able to complete the request faster and serve it out to the other users in Queue. There is a very small lag between the User 1 and when the rest of users get the data.

Benchmark

Coming Soon…

TODO

  • This is the initial release. I would like to package this up in a proper plugin later this month.
  • Some code clean up would also help.
  • Get some benchmarks.

Download

https://github.com/asalce/Magento-Block-Cache-Queue

原文:Magento Block Cache Queue For High Traffic Sites

PS:转这篇文章并不是来推荐作者写的这个扩展,作者自己也说这个不是一个完善的版本,我也对作者应对这个问题的处理方式持保留态度。重点是这里针对Magento的缓存机制,在高并发的情况下所会遇到的问题进行了阐述,至于如何应对和处理这个问题,我觉得方式可能有很多种,留给大家去思考



目录
相关文章
|
存储 运维 Linux
【MinIO异常】Storage reached its minimum free drive threshold 的解决方案
【MinIO异常】Storage reached its minimum free drive threshold 的解决方案
637 0
|
9月前
Elasticsearch【问题记录 02】【不能以root运行es + max virtual memory areas vm.max_map_count [65530] is too low处理】
【4月更文挑战第12天】Elasticsearch【问题记录 02】【不能以root运行es + max virtual memory areas vm.max_map_count [65530] is too low处理】
105 3
|
9月前
|
Docker 容器
devmapper: Thin Pool has 162394 free data blocks which is less than minimum required 163840 free dat
devmapper: Thin Pool has 162394 free data blocks which is less than minimum required 163840 free dat
87 0
|
tengine 应用服务中间件 Linux
ModSecurity - Efficient and Free WAF Component for Mid- and Small-Scale Webmasters
ModSecurity is a free open source host WAF software (@http://www.modsecurity.org/).
2550 0

热门文章

最新文章