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 的解决方案
519 0
|
3月前
|
JSON PHP 数据格式
PHP Allowed memory size of 134217728 bytes exhausted (tried to allocate 10489856 bytes)
PHP Allowed memory size of 134217728 bytes exhausted (tried to allocate 10489856 bytes)
71 2
|
4月前
|
缓存 监控 时序数据库
influxdb报错:cache-max-memory-size exceeded
influxdb报错:cache-max-memory-size exceeded
158 0
|
前端开发 API PHP
php内存溢出:Allowed memory size of 1342bytes exhausted (tried to allocate 8192 bytes)本地配置和宝塔配置解决方案
php内存溢出:Allowed memory size of 1342bytes exhausted (tried to allocate 8192 bytes)本地配置和宝塔配置解决方案
157 0
|
缓存 应用服务中间件
Tomcat 警告:consider increasing the maximum size of the cache
Tomcat 警告:consider increasing the maximum size of the cache
539 0
Tomcat 警告:consider increasing the maximum size of the cache
|
前端开发 Java 关系型数据库
记录:The field files exceeds its maximum permitted size of 1048576 bytes...【亲测有效】
记录:The field files exceeds its maximum permitted size of 1048576 bytes...【亲测有效】
1132 0
The Soft Link between IM Level Storage Location and WM level Storage Type?(1)
The Soft Link between IM Level Storage Location and WM level Storage Type?(1)
The Soft Link between IM Level Storage Location and WM level Storage Type?(1)
The Soft Link between IM Level Storage Location and WM level Storage Type?(2)
The Soft Link between IM Level Storage Location and WM level Storage Type?(2)
The Soft Link between IM Level Storage Location and WM level Storage Type?(2)
|
Oracle 关系型数据库 数据库