您现在的位置是：首页 > 教程 > WordPress教程WordPress教程
nginx中怎么优化wordpress
妙彤2023-11-25 23:37:16WordPress教程已有人查阅
导读Nginx下WordPress运行缓慢的解决方法：wordpress运行缓慢优化的方法1. 减少插件的使用这是首要的一点。大部分人往往都没足够的代码知识，更不可能做到每个插件的代码化，故大部分
Nginx下WordPress运行缓慢的解决方法：wordpress运行缓慢优化的方法
1. 减少插件的使用
这是首要的一点。大部分人往往都没足够的代码知识，更不可能做到每个插件的代码化，故大部分人都在用大量插件等。大部分的插件都会进行数据查询与生成，这在页面生成过程中 将耗费时间。如果刚好你的主机限制比较严格的话（为了均衡资源使用率），这个时间甚至会变得比较长。减少插件是非常必要的优化手段之一
2. 减少HTTP请求
每一次对于JS，CSS等文件的访问都是一次HTTP请求。插件用得少，HTTP请求数自然就更少。速度自然快了
WP在每一次的页面访问时，都会判断插件的使用情况。让WP做更少的判断就等于做更少的数据查询。解放它的负担吧。
3. 谨慎的选择主题或手动优化
许多主题虽然漂亮但在优化方面做得并不算好，各种JS，各种CSS，各种背景图片，各 种空行，各种冗余，这些都会影响到载入速度。不过这并不意味着不能选择绚丽的主题，而是主题应该要基本满足以下要求，或者你手动修改它使其满足以下要求：
合并CSS和JS：将多个CSS合并为1个。
合并背景图片：使用CSS Sprites将大部分的背景图片合并为1个文件，同样是减少HTTP请求，减少文件体积，加快渲染时间。
减少数据查询：能用HTML直接输出的地方就不要搞个数据查询。
合理的JS和CSS位置：合理的将一些JS和CSS放置到网页底部。
优化主题的背景图片
4. 减少外部资源的使用
外部资源就是不在自己服务器上的资源。使用太多的外部资源会遇到以下问题：
解析DNS的时间变长
每一个域名都是需要DNS解析才能够正常工作。如果网站上的内容同时需要加载a.com，b.com，c.com，d.com这些网站的资源，那就 需要更多的时间去分别解析每个域名的DNS，建立连接。而同样的，如果自己的站点是a.com，如果同时加载1.a.com，2.a.com这些类似的域名，也同样会加长DNS解析时间。外部资源是不可能 基本避免的，但能少则少。
外部资源的加载速度不可控制
这主要是针对一些国外站点的内容而言，比如fickr，twitter等，因为众所周知的原因，加载它们的资源会明显减慢载入速度。而国内的站点相对来说速度还算是比较快。
5. 减少数据库查询，或使用数据库缓存插件
许多的插件都需要数据库查询，上面关于插件和主题的部分也提到了优化代码尽量减少数据库的查询次数。如果不懂，可以考虑使用数据库缓存，它能够将数据库的查询内容缓存起来
需要注意的是，数据库缓存插件不要和静态化缓存插件一起使用。因为两者都是数据缓存内容减少查询，如果一起用就等于重复劳动。
6， 使用页面静态化缓存插件
静态化缓存插件和数据库缓存插件的原理差不多，都是将内容提前整理好并生成静态的文件，当需要的时候直接拿出来，而不需要再去查找、生成，浪费时间。缓存过的静态文件基本上可以等同于一张静态图片，不需要执行太多复杂的内容。
还有一些其他优化的方法等，使用GZIP压缩网页、优化博客文章图片、使用CDN分布式网络加速静态文件等。
安装wordpress插件检查缓慢原因
本站运行一段时间后，每次访问首页最多时候需要20秒钟以后上， 访问一个单独文章页面也要10秒，简直不可接受，基本都要崩溃了， 最后下定决心 解决它。
通过查阅大量资料， 参照前面一节的办法对系统做了优化。
1. 首先屏蔽 基本插件，发现系统问题依然存在， 打开首页速度依然在10秒钟左右
2. 通过httpwatch检查http请求情况，发现访问首页中，获取php页面时间是9秒钟， 打开图片、js、css等时间是2～3秒钟左右， 因此不是http请求过多造成的。
3. 打开mysql数据库的慢查询，检查数据库的慢查询情况，发现多数查询都比较快，对一些查询做了测试，速度非常快。因此数据库因素也可以排除了。
实在没办法了， 最后考虑找wordpress插件来研究一下在显示首页中都发生了那些内容，然后看看那里占用时间最长， 然后有针对的慢慢优化，只好这么干了。
到了wordpress网站，搜索 debug插件， 搜索了很多，试用了很多，都不太符合自己的要求。最后发现了一个插件“Debug Queries”，按照wp的 惯下载并且安装，最后路下图，点击启用按钮开启插件。
安装完成插件后，打开网站首页，查看效果发现没有任何变化
最后打开一个文章页面，在文章页面最下面发现了久久寻找的东西，路下图：
图中已经用不同颜色的区域做了一些标注
红 域： time：0.000xxxx 查询需要的时间
绿 域： Query： 查询的sql语句
Call from： require，xxx 调用顺序等等
然后下面是另外的调用。 页面显示了本次页面显示过程调用了那些函数以及调用过程，及需要的时间（数据库的查询时间，根据这个时间及总时间我们计算出php花费的时间）
最后页面路下图：
蓝色部分：是本次访问数据查询时间 汇总， 可以看到查询共花费了0.24秒， 发生了83次查询（这个也说明wp插件带来性能的问题，只是目前系统中数据量较少，还不至于影响系统的性能）
绿色部分：是本次用户访问过程中总体时间的汇总，这里统计的应该是包括了php的总体时间。
红色部分：是本次访问的总时间
紫色部分： 本次访问中花费在php程序中消耗的百分比。97.5%
黄色部分：是本次访问中花费在MySQL数据库上时间的百分比 2.5%
从上面数据中我们可以看到， 一次10秒钟的用户访问中， mysql花费时间仅仅占用了2.5%因此可以肯定这次10秒钟的访问问题出在mysql以外的环节上， 主要应该是php的问题。
重新启动php进程解决缓慢问题
从上面部门的分析中我们已经可以了解到问题很可能出在php上面，排查php问题，不是我的专长，因此决定重新启动php进程看一下效果。
1. 查找php进程
输入 su – 命令， 切换端到root帐号下
在输入： ps -ef | grep php 命令，查看php进程，如下
从图中我们可以了解到php进程id 是 26765， 进程名称php-fpm（这个是nginx需要的php程序）。
2. 查找php进程的启动路径
输入如下命令 lsof -p 8584（这里的8584是在进行问题解决时php进程的id，上面26765还是最近写文章是查找的进程的id）
3. 关闭进程
kill -9 8584 关闭老的php进程
有的时候php开辟了很多进程， 不好关闭，可以采用下面的办法进行
killall php-fpm （本站就是采用这个办法进行的）
4. 重新启动php进程
输入如下命令
/usr/ in/php-fpm 重新启动进程
1. 减少插件的使用
这是首要的一点。大部分人往往都没足够的代码知识，更不可能做到每个插件的代码化，故大部分人都在用大量插件等。大部分的插件都会进行数据查询与生成，这在页面生成过程中 将耗费时间。如果刚好你的主机限制比较严格的话（为了均衡资源使用率），这个时间甚至会变得比较长。减少插件是非常必要的优化手段之一
2. 减少HTTP请求
每一次对于JS，CSS等文件的访问都是一次HTTP请求。插件用得少，HTTP请求数自然就更少。速度自然快了
WP在每一次的页面访问时，都会判断插件的使用情况。让WP做更少的判断就等于做更少的数据查询。解放它的负担吧。
3. 谨慎的选择主题或手动优化
许多主题虽然漂亮但在优化方面做得并不算好，各种JS，各种CSS，各种背景图片，各 种空行，各种冗余，这些都会影响到载入速度。不过这并不意味着不能选择绚丽的主题，而是主题应该要基本满足以下要求，或者你手动修改它使其满足以下要求：
合并CSS和JS：将多个CSS合并为1个。
合并背景图片：使用CSS Sprites将大部分的背景图片合并为1个文件，同样是减少HTTP请求，减少文件体积，加快渲染时间。
减少数据查询：能用HTML直接输出的地方就不要搞个数据查询。
合理的JS和CSS位置：合理的将一些JS和CSS放置到网页底部。
优化主题的背景图片
4. 减少外部资源的使用
外部资源就是不在自己服务器上的资源。使用太多的外部资源会遇到以下问题：
解析DNS的时间变长
每一个域名都是需要DNS解析才能够正常工作。如果网站上的内容同时需要加载a.com，b.com，c.com，d.com这些网站的资源，那就 需要更多的时间去分别解析每个域名的DNS，建立连接。而同样的，如果自己的站点是a.com，如果同时加载1.a.com，2.a.com这些类似的域名，也同样会加长DNS解析时间。外部资源是不可能 基本避免的，但能少则少。
外部资源的加载速度不可控制
这主要是针对一些国外站点的内容而言，比如fickr，twitter等，因为众所周知的原因，加载它们的资源会明显减慢载入速度。而国内的站点相对来说速度还算是比较快。
5. 减少数据库查询，或使用数据库缓存插件
许多的插件都需要数据库查询，上面关于插件和主题的部分也提到了优化代码尽量减少数据库的查询次数。如果不懂，可以考虑使用数据库缓存，它能够将数据库的查询内容缓存起来
需要注意的是，数据库缓存插件不要和静态化缓存插件一起使用。因为两者都是数据缓存内容减少查询，如果一起用就等于重复劳动。
6， 使用页面静态化缓存插件
静态化缓存插件和数据库缓存插件的原理差不多，都是将内容提前整理好并生成静态的文件，当需要的时候直接拿出来，而不需要再去查找、生成，浪费时间。缓存过的静态文件基本上可以等同于一张静态图片，不需要执行太多复杂的内容。
还有一些其他优化的方法等，使用GZIP压缩网页、优化博客文章图片、使用CDN分布式网络加速静态文件等。
安装wordpress插件检查缓慢原因
本站运行一段时间后，每次访问首页最多时候需要20秒钟以后上， 访问一个单独文章页面也要10秒，简直不可接受，基本都要崩溃了， 最后下定决心 解决它。
通过查阅大量资料， 参照前面一节的办法对系统做了优化。
1. 首先屏蔽 基本插件，发现系统问题依然存在， 打开首页速度依然在10秒钟左右
2. 通过httpwatch检查http请求情况，发现访问首页中，获取php页面时间是9秒钟， 打开图片、js、css等时间是2～3秒钟左右， 因此不是http请求过多造成的。
3. 打开mysql数据库的慢查询，检查数据库的慢查询情况，发现多数查询都比较快，对一些查询做了测试，速度非常快。因此数据库因素也可以排除了。
实在没办法了， 最后考虑找wordpress插件来研究一下在显示首页中都发生了那些内容，然后看看那里占用时间最长， 然后有针对的慢慢优化，只好这么干了。
到了wordpress网站，搜索 debug插件， 搜索了很多，试用了很多，都不太符合自己的要求。最后发现了一个插件“Debug Queries”，按照wp的 惯下载并且安装，最后路下图，点击启用按钮开启插件。
安装完成插件后，打开网站首页，查看效果发现没有任何变化
最后打开一个文章页面，在文章页面最下面发现了久久寻找的东西，路下图：
图中已经用不同颜色的区域做了一些标注
红 域： time：0.000xxxx 查询需要的时间
绿 域： Query： 查询的sql语句
Call from： require，xxx 调用顺序等等
然后下面是另外的调用。 页面显示了本次页面显示过程调用了那些函数以及调用过程，及需要的时间（数据库的查询时间，根据这个时间及总时间我们计算出php花费的时间）
最后页面路下图：
蓝色部分：是本次访问数据查询时间 汇总， 可以看到查询共花费了0.24秒， 发生了83次查询（这个也说明wp插件带来性能的问题，只是目前系统中数据量较少，还不至于影响系统的性能）
绿色部分：是本次用户访问过程中总体时间的汇总，这里统计的应该是包括了php的总体时间。
红色部分：是本次访问的总时间
紫色部分： 本次访问中花费在php程序中消耗的百分比。97.5%
黄色部分：是本次访问中花费在MySQL数据库上时间的百分比 2.5%
从上面数据中我们可以看到， 一次10秒钟的用户访问中， mysql花费时间仅仅占用了2.5%因此可以肯定这次10秒钟的访问问题出在mysql以外的环节上， 主要应该是php的问题。
重新启动php进程解决缓慢问题
从上面部门的分析中我们已经可以了解到问题很可能出在php上面，排查php问题，不是我的专长，因此决定重新启动php进程看一下效果。
1. 查找php进程
输入 su – 命令， 切换端到root帐号下
在输入： ps -ef | grep php 命令，查看php进程，如下
从图中我们可以了解到php进程id 是 26765， 进程名称php-fpm（这个是nginx需要的php程序）。
2. 查找php进程的启动路径
输入如下命令 lsof -p 8584（这里的8584是在进行问题解决时php进程的id，上面26765还是最近写文章是查找的进程的id）
3. 关闭进程
kill -9 8584 关闭老的php进程
有的时候php开辟了很多进程， 不好关闭，可以采用下面的办法进行
killall php-fpm （本站就是采用这个办法进行的）
4. 重新启动php进程
输入如下命令
/usr/ in/php-fpm 重新启动进程
本文标签：
很赞哦！ ()
相关文章
随机图文
wordpress上传到虚拟主机需要注意的几点，wordpress怎么上传到虚拟主机
本地域名与虚拟主机的URL是不一样，需要站长在phpMyAdmin中修改，需要修改的包括Wordpress地址和首页地址，文章的Guid，正文中的链接地址等。
wordpress可以做商城网站吗，wordpress能不能做商城
WordPress是使用PHP语言开发的博客平台，用户可以在支持PHP和MySQL数据库的服务器上架设属于自己的网站。也可以把 WordPress当作一个内容管理系统（CMS）来使用。
WordPress文章底部去除和添加版权的方法
WordPress文章底部怎么去除与添加版权信息一、去除版权信息1. 进到管理后台，打开外观-编辑2. 找到“footer.php”，进行代码修改
禁用WordPress前台搜索功能的方法
WordPress自带的搜索功能很弱、效率非常低，如果有人利用这个缺陷发起很多搜索请求，你的服务器很有可能会宕机。我们可以使用百度、360等实现站内搜索
| 留言与评论 （共有 条评论） |
