CacheManager 可以说是LiteBlog的核心,是高效响应的重要和决定性关联项

从下面这份CacheManager的配置讲起吧

• configs/config.json

"cache_config": {
        "//": "this used to cache the rendered pages, default is in memory,if use_disk is true, it will cache in disk and using.",
        "use_disk": false,
        "max_cache_size": 2147483648,
        "max_cache_items": 1000,
        "expire_time": 3600
    }

• use_disk: LiteBlog的主要功能,用于将请求的页面缓存到本地磁盘,仅在调试开发时推荐设置为false,其他时候均可以设置为true.
• max_cache_size: 决定LiteBlog的缓存最大大小,单位为字节,计算方式为所有缓存的文件大小相加不能超过这个值.超出则进入缓存删除方法.
• max_cache_items: 决定LiteBlog的缓存最大文件数,超出则进入缓存删除方法.
• expire_time: 决定每个缓存文件的最大存活时间,超出这个时间的缓存文件会被自动删除,并替换为新的缓存文件.

缓存超出删除队列根据以下规则:

• 读取每个缓存文件的超时时间戳,若超出这个最大时间则自动删除.
• 统计当前缓存目录下文件个数和缓存文件大小,若超出最大缓存数max_cache_items或最大缓存大小 max_cache_size 则根据修改时间从末到前删除缓存文件

为博客优化的缓存方法和异步渲染模块

• 由于LiteBlog秉持轻量,前端JS为主计算组件,所以所有页面(除了API)基本全都可以被缓存.
• 由于为博客优化的缓存方式,导致后端cpu和内存消耗可以忽略不计,
• 异步渲染和缓存优化使得LiteBlog在处理一个需要渲染的页面时,消耗的时间可以从800微妙缩短到80微妙.极大的减小了LiteBlog的运行性能需求,以至于可以在一台0.1c的VPS上运行.甚至毫不费力
• 也是由于这个存在,使得LiteBlog可以被转为完全静态运行,参见 - LiteBlog - 全静态模式

以下是一个正式运行时的 CacheManager 配置示例

"cache_config": {
        "//": "this used to cache the rendered pages, default is in memory,if use_disk is true, it will cache in disk and using ",
        "use_disk": true,
        "max_cache_size": 2147483648,
        "max_cache_items": 1000,
        "expire_time": 3600
    }

那么这个有什么缺点吗

缺点肯定是有的

1. 他极大的受到磁盘IO的影响.

• 所以为了降低IO读写延迟导致的问题, LiteBlog 使用了 DeliverManager(教程也还没写好) 来降低IO对同步缓存导致的延迟问题,将非必要的IO延迟转为异步处理,将80微秒的请求延迟再次降低至50微秒

2. 好像找不到了,我以后再找找

有好的建议和意见都欢迎右键Add comment或github issue,pr提出哦