Mayx的运维笔记 - 应用优化 | Mayx的博客

21 January 2020 - 字数统计：1924 - 阅读大约需要6分钟 - Hits: Loading...

# Mayx的运维笔记 - 应用优化

by mayx

这是一篇创建于 天前的文章，其中的信息可能已经有所发展或是发生改变。

AI摘要

这篇文章记录了作者对Mayx论坛应用进行优化的过程。首先尝试更换了图片处理库，从GD库改为ImageMagick库，但遇到了图片缩略图显示问题，怀疑是数据库问题，最终恢复默认设置。然后，尽管对Redis缓存有所期待，但配置过程遇到困难，特别是与/tmp/文件夹权限相关的问题。作者将Redis配置到/run/文件夹后，问题得以解决，但并未显著提升性能，反而因请求量激增而发现优化的必要性。此外，还调整了Discuz的权限设置和发帖限制，以应对可能存在的恶意操作。作者最后感慨优化过程中的挫折和提升自身技能的需求。

- 继续优化！
- 关于图片处理库的优化
- 关于缓存的优化
  - 历经艰辛的Redis之旅
- 其他的杂事

优化？能不负优化就够好了！

#
继续优化！

接着上一篇的重建，我在上一次做了一些系统环境上的优化，不过论坛中用的Discuz系统也算是一个成熟的应用了 （可惜再成熟也不会自己写代码😂） ，所以这次我打算在Discuz这个应用上做优化。

不过毕竟以我的PHP水平还做不到直接在源代码上进行修改，所以我打算使用Discuz本身有的优化功能上进行优化。

#
关于图片处理库的优化

在Discuz的后台面板中，我首先看到的关于性能优化方面的地方就是图片处理库 （尽管它不是最先出现的）。看旁边的介绍中说默认的GD库似乎更加消耗系统资源，而相比之下ImageMagick库会好一些，既然它都这么说了，那我肯定是毫不犹豫的选择了ImageMagick库嘛。

当然，事实上我也确实是这么做的，然而这个操作貌似发生了一些不可预料的问题。修改了这个选项后我开始逛论坛，但是我发现论坛中不少帖子的图片缩略图显示出现了问题，这时候我感觉不大对劲，首先我确定了一下，Vultr中的LEMP肯定是有装ImageMagick库的，那问题肯定不是我PHP环境的问题，这时候我怀疑是数据库保存的东西可能有问题。不过这个问题就超出了我的解决范围，没办法，我只好又把选项还原回去了😓，反正它这么多年也都过来了，应该影响没多大吧。

#
关于缓存的优化

在之前的花火学园中，我也用了Discuz的缓存，引擎是MemCache。事实上在LEMP默认是不提供MemCache的扩展，反倒是有Redis的扩展。不过我看着Redis那红色的图标，不知道为什么心里总有一种抵触感，后来经过了解，Redis似乎要比MemCache的性能好的多，我也就半信半疑的打算装一下试试。

不过事实上我并不怎么相信这种缓存能提升多少性能，只是看着网上说着各种加速到0.005s让人非常的心动。毕竟我的服务器内存并不大，总共也就1个G，另外还加了Swap。如果缓存占用的内存很多，分配来分配去又回到Swap所在的硬盘，那我优化岂不是失去了意义？不过心里总是被别人的博客搞的很羡慕，所以我开始研究怎么样搞Redis缓存。

##
历经艰辛的Redis之旅

Redis并不是很难安装，一句`yum install redis`就搞定了，主要难的地方还是在于配置。

我知道，这时候只要在Discuz的配置文件里加一句`$_config['memory']['redis']['server'] = '127.0.0.1';`然后再以默认的方式启动Redis服务就OK了。但是既然之前我说过，在内部的服务中不应该使用TCP/IP sockets，那我肯定是不能允许它就用默认的配置工作。

在Redis中倒是有支持UNIX domain sockets的选项，也支持关闭监听TCP/IP Port。我按照它上面的说明配置了，然后信心满满的在配置文件中设定好了。然而现实告诉我没那么简单，我写了一个测试脚本，它返回了一个`No such file or directory`？我反复确认路径，保证自己没有手残到把路径写错，然后上网搜这个错误，查了半天也没有什么有建设性的结果……我甚至把权限都设置为777，把php-fpm加到了redis的组里，都没有任何用处，另外我也用redis-cli确定了那个文件确实是一个socket文件。这时候我实在是无计可施了，我打算放弃，就这样屈服于TCP/IP sockets，然而我的强迫症和其他博客里中说的10ms不允许我放弃！没办法，我只好仔细思考了。

我觉得这个问题应该还是在于权限，只是这个问题过于奇妙，让我无法理解。按照默认的配置，那个socket文件在/tmp/文件夹下，因为PHP在上传文件的时候也用到了这个文件夹，所以我也没怎么怀疑它。但是我的mysql同样也用了UNIX domain sockets，只是文件在/run/下，它也没出问题啊，我想了想，也许把这个socket文件放到/run/文件夹下就可以正常工作了。没想到还真是这个问题，随着我把配置文件中的路径修改了，它也能正常工作了……我真的是无言以对……

在这之后，我把redis服务设置成了开机自启动，然后这段优化就到此为止了。

#
其他的杂事

其他也没什么特别多可以优化的地方，后来我查了一下，发现花火学园的请求在那天出现问题的时候请求量突然涨了一倍，也许是这个原因把之前的花火学园逼停了，所以优化还是挺重要的嘛。

其他方面就是对于Discuz权限的一些调整，不知道为什么，总有些人要在试贴区水贴，真的是无法理解它们的操作，另外就是连发贴的问题，我感觉估计有人用发帖机搞我们的论坛，所以又提高一点发帖的门槛。

其实这次也没什么大的改动，就是这个Redis搞的我真是当场爆炸，看来我还是要提高一下我的姿势水平啊23333。

tags: 运维 - 笔记 - 优化 查看原始文件

#### 推荐文章

Loading...

上一篇：Mayx的运维笔记
下一篇：过去与未来的科技变化
想问这篇文章
召唤伊斯特瓦尔