洞察纵观鸿蒙next版本,如何凭借FinClip加强小程序的跨平台管理,确保企业在数字化转型中的高效运营和数据安全?
778
2022-09-16
Windows 服务器上的 WordPress 站点优化笔记(windows10截图快捷键)
2020年5月初,码农很忙进行了一次服务器迁移。除了 IP 地址变更之外,服务器系统也从 Windows Server 2019 降级为 Windows Server 2008 同时将 PHP 环境升级至 PHP 7.4.5 。
在完成 IIS 的安装后,将 PHP 7.4.5 nts 版本以 FastCGI 方式整合在 IIS 上,采用 php.ini-production 作为配置模板,以最小化组件依赖方式将 WordPress 运行了起来。在站点可以正常打开之后,对时区、最大运行时间和最大上传数据大小等参数进行了调整。
最小化依赖配置下站点的运行速度并不理想:网站首页的响应时间长达 600 毫秒。以当前服务器的配置,响应时间在 200 毫秒左右才算正常。
进入管理后台的 “工具” 》 “站点健康”页面后,发现站点健康状态为:有待改进,提示包括 ImageMagick 在内的若干个扩展项没有安装。将扩展项逐一安装完成后页面提示健康状态良好,但运行速度仍旧没有改善。
在管理后台添加 WP Super Cache 插件并启用,在命中缓存的情况下响应时间缩短至 40 毫秒左右,但在缓存未命中的情况下,响应时间仍需 600 毫秒以上。
启用 Autoptimize 插件,所有的前台页面被压缩且 css 文件被合并。但这也没有对响应速度有太大的提升。
启用 PHP 的 Opcache 扩展,网站速度有了很大幅度的提升:缓存未命中的情况下,响应时间被缩短至 300 毫秒左右。
这个设置持续一段时间之后,偶然在 WordPress 插件列表中找到一款名为 Redis Object Cache 的插件。于是尝试启用了该插件,并安装了 Redis 服务器和 php_redis 扩展。此时,网站性能再次提升:缓存未命中的情况下,首页的响应时间降低到接近 250 毫秒左右。
考虑到缓存插件 WP Super Cache 和 Autoptimize 可能与 Redis Object Cache 有冲突或者额外的缓存操作反而降低性能,于是尝试禁用 WP Super Cache 和 Autoptimize 插件。之后,响应时间降低到 200 毫秒左右。于是将 WP Super Cache 和 Autoptimize 插件卸载。
至此,小站的优化告一段落,200 毫秒左右的响应时间算的上一个秒开的网站了。
总结一下
在 Windows 服务器上,PHP 也能表现出不错的性能。即使在最小化依赖的配置下性能不尽人意,但在开启了 Opcache 扩展后性能会有一个很大的提升。WP Super Cache 当然可以大幅度加快访问速度,但前提是命中缓存。Redis 是一款神器,有了他可以抛弃其他大多数缓存插件了。在优化过程中要时刻牢记:并非优化插件越多速度越好。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~