wp请求响应过程
wordpress响应请求大致分为如下几个过程:
Nginx接收请求 -> php-fpm进程运行指定php脚本 -> php在mysql内查询相应数据 -> 处理返回给Nginx -> Nginx响应用户请求
因为不存在缓存的过程,所以每次处理请求都要重新查询数据库,所以wp有很多流行的静态缓存方案;
wp缓存方式
1.文件缓存
初次请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> php在mysql内查询相应数据 -> 缓存本次请求产生的页面数据到文件A -> 处理返回给Nginx -> Nginx响应用户请求
缓存之后的请求过程如下:
缓存之后的所有请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> 判断是否存在缓存文件 -> 输出缓存文件的内容给Nginx -> Nginx响应本次请求
相较于没有缓存的情况,大大的减少了Mysql的查询次数,所有文件缓存是比较流行的一种方式,但是这种方式在数据量很大的时候,能起到的作用还是比较有限的。
2.内存持久化缓存
初次请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> php在mysql内查询相应数据 -> 缓存本次请求产生的页面数据到Redis -> 处理返回给Nginx -> Nginx响应用户请求
内存持久化缓存最常见的是将页面缓存到Redis,缓存之后的每次请求直接从Redis获取数据;因为每次查询都是操作内存,所以速度非常快,响应过程大致如下:
缓存之后的所有请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> 判断Redis是否存在缓存 -> 输出缓存文件的内容给Nginx -> Nginx响应本次请求
缺点就是数据量大的时候,占用的内存比较多,所以这种方式相较于文件缓存,使用的比较少。
Nginx+文件缓存
Nginx响应静态文件请求出了名的快,所以我们可以将响应请求的方式调整成如下过程:
缓存之后的所有请求 -> Nginx接收请求 -> Nginx判断当前请求是否有缓存文件 -> 直接响应本次请求的缓存文件
页面生成缓存之后,响应请求不再经过PHP和Mysql等以外的程序,直接通过Nginx完成所有事情。实现方式如下:
1.针对初次请求生成缓存文件
本次只是简要的说明可行性方案,有示例代码,无插件;编辑根目录的index.php,在define( ‘WP_USE_THEMES’, true );后加入如下代码:
2.修改Nginx伪静态匹配规则
修改之后的匹配规则变为,首先判断请求的文件在不在,然后判断cached目录下面又没有这个文件,然后判断有没有这个目录(目录内有没有index文件),最后将请求重定向到wordpress入口文件index.php。
如果缓存文件存在,将会在cached目录内匹配到请求的目录,然后直接响应用户请求。
3.最后总结
还有很多细节需要完善,比如如何处理缓存更新,比如有些主题移动端、PC端页面代码不一致时如何处理等等。
但是总得来说,通过这种方式加速后,访问速度能快一个量级。
评论(0)