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 );后加入如下代码:

/* 如果访问的不是后台 */
if(strpos($_SERVER['REQUEST_URI'],"wp-admin") === false){
	ob_start( function ( $html ) {

		/* 判断文章密码 */
		if(is_single()){
			$post = get_post();
			if ( !empty( $post->post_password ) ) {
				return $html;
			}
		}

		/* 小程序 */
		$location = $_SERVER['REQUEST_URI']; //路径

		/* 去除参数 */
		$match = preg_replace( '/(\?.*)/', "", $location );
		$query = $_SERVER['QUERY_STRING']; //查询的参数

		/*
		 * 纯目录和html文件
		 * */
		if ( ( strpos( $match, '.' ) === false ) || ( strpos( $match, '.html' ) !== false ) ) {


			$dir  = WP_ROOT_PATH . "/cache" . $match . '_' . $query;
			$file = WP_ROOT_PATH . "/cache" . $match . '_' . $query . '/index.html';

			if ( ! file_exists( $dir ) ) {
				mkdir( $dir, 0777, true );
			}

			if ( ! file_exists( $file ) && ! empty( $html ) ) {
				file_put_contents( $file, $html, LOCK_EX );
			}
		}


		return $html;

	});
}

2.修改Nginx伪静态匹配规则

location / {
    if ($request_method ~ ^(POST)$){
	rewrite / /index.php?$args last;
    }	
    try_files $uri $uri/ /cache/$uri /cache/${uri}_${args}/index.html /index.php?$args;
}

修改之后的匹配规则变为,首先判断请求的文件在不在,然后判断cached目录下面又没有这个文件,然后判断有没有这个目录(目录内有没有index文件),最后将请求重定向到wordpress入口文件index.php。

如果缓存文件存在,将会在cached目录内匹配到请求的目录,然后直接响应用户请求。

3.最后总结

还有很多细节需要完善,比如如何处理缓存更新,比如有些主题移动端、PC端页面代码不一致时如何处理等等。

但是总得来说,通过这种方式加速后,访问速度能快一个量级。