Yii 2 标签归档 - 永夜

基于 Yii 2 的 HTTP 客户端扩展，上传文件，PHP Fatal Error ‘yii\base\ErrorException’ with message ‘Allowed memory size of 2147483648 bytes exhausted (tried to allocate 1084897244 bytes)’ 的分析解决

永夜 — Mon, 07 Dec 2020 06:06:06 +0000

在使用 Yii 2 框架的 HTTP 客户端扩展上传文件时，遇到内存耗尽报错的问题。通过本地测试发现，内存占用约为文件大小的 3 倍。由于暂无代码层面的内存优化方案，最终采取修改 php.ini 配置文件，增加 memory_limit 值的方法来解决。当该值设置为 4096M 时，可成功上传 1.01GB 的文件；设置为 6144M 时，则能够解决 1.44GB 文件的上传报错问题。

基于 Yii 2 的 HTTP 客户端扩展，上传文件，PHP Fatal Error ‘yii\base\ErrorException’ with message ‘Allowed memory size of 2147483648 bytes exhausted (tried to allocate 1084897244 bytes)’ 的分析解决最先出现在永夜。

基于 Yii 2 的 HTTP 客户端扩展，下载文件且另存为具体的文件名(下载远程文件至服务器)，内存占用从 400 MB 下降至 7 MB 的实现

永夜 — Thu, 26 Nov 2020 08:49:39 +0000

文章基于 Yii 2 框架实现了将远程资源文件下载至服务器并另存为指定文件名的功能。初始方案因直接读取内容导致下载大视频时内存占用高达 400MB，甚至超出内存限制而报错。经重构代码，利用 cURL 传输机制通过设置输出文件流，实现了下载同步写入，最终将内存占用降至约 7MB，解决了大文件下载受限于内存配置的问题。

基于 Yii 2 的 HTTP 客户端扩展，下载文件且另存为具体的文件名(下载远程文件至服务器)，内存占用从 400 MB 下降至 7 MB 的实现最先出现在永夜。

基于 Composer 更新 Yii 2 至最新版本后，软件包：guzzlehttp guzzle 的丢失的分析

永夜 — Tue, 21 Jan 2020 03:18:22 +0000

在使用 Composer 将 Yii Framework 从 2.0.15.1 升级至 2.0.31 版本后，项目报错显示 guzzlehttp 相关包丢失，经分析发现这是因为 codeception/base 组件版本随框架升级而更新，且新版本不再依赖 guzzlehttp/guzzle。通过依赖检测工具确认了组件间的依赖关系，最终通过使用 Yii 帮助类 Json 替换原有的相关函数调用解决了该问题。

基于 Composer 更新 Yii 2 至最新版本后，软件包：guzzlehttp guzzle 的丢失的分析最先出现在永夜。

基于 Composer 更新 Yii 2 至最新版本，将 Yii Framework 从 2.0.15.1 版本升级到 2.0.31

永夜 — Sun, 19 Jan 2020 02:26:51 +0000

本文介绍了基于 Composer 将 Yii Framework 从 2.0.15.1 版本升级到 2.0.31 的过程。首先通过命令将 Composer 更新至最新版本，随后运行更新命令完成 Yii 框架的升级。文章还说明了如何在线查看升级说明文档，以了解可能的不兼容更改及类属性与方法的调整情况。

基于 Composer 更新 Yii 2 至最新版本，将 Yii Framework 从 2.0.15.1 版本升级到 2.0.31最先出现在永夜。

基于 Yii 2 的 HTTP 客户端扩展的响应处理的现阶段时间内的最佳实践(在之前的实现上有所优化，在后续一段时间内皆如此实践，HTTP 客户端组件的本地化，返回的处理逻辑的简化等)

永夜 — Fri, 20 Dec 2019 09:39:01 +0000

本文探讨了基于 Yii 2 框架的 HTTP 客户端扩展在响应处理方面的优化实践。针对原有实现中应用组件过多、配置冗余、异常信息不完善及返回逻辑复杂等问题，文章提出将客户端实例封装为本地组件以减少全局依赖。通过优化错误处理机制，完善异常信息，并将业务错误存储至模型属性而非直接抛出异常，从而简化调用方的判断逻辑，最终通过封装公共响应处理方法实现了代码复用与逻辑简化。

基于 Yii 2 的 HTTP 客户端扩展的响应处理的现阶段时间内的最佳实践(在之前的实现上有所优化，在后续一段时间内皆如此实践，HTTP 客户端组件的本地化，返回的处理逻辑的简化等)最先出现在永夜。

Docker 部署，基于 Supervisor 的 crontab (bash sleep) 的实现，以降低内存占用

永夜 — Sat, 12 Oct 2019 07:36:38 +0000

文章介绍了基于 Supervisor 和 bash sleep 实现 Docker 部署中类 crontab 任务以降低内存占用的过程。通过编辑配置文件调整脚本执行间隔，并在测试环境检测运行状态与异常处理情况。实验发现将 sleep 时间控制在合理范围并调整 startsecs 参数可有效降低内存，最终在两个产品环境中验证了该方法能显著减少 Docker 容器的内存占用并符合预期。

Docker 部署，基于 Supervisor 的 crontab (bash sleep) 的实现，以降低内存占用最先出现在永夜。

基于 yiisoft/yii2-app-advanced，在 GitHub 上新建仓库 yii2-app-advanced，日志消息的自动定时删除

永夜 — Wed, 09 Oct 2019 05:59:56 +0000

针对 yiisoft/yii2-app-advanced 项目，本文介绍了在 MySQL 日志表累积数百 GB 数据的背景下，基于控制台命令行实现日志消息自动定时删除的方法。操作包括编写 LogController，在凌晨时段按每日批次删除过期数据，通过延缓执行机制避免性能影响。最终配置保留时间参数后，成功将开发环境日志表数据量缩减至 2.36 GB，达到了清理与性能的平衡。

基于 yiisoft/yii2-app-advanced，在 GitHub 上新建仓库 yii2-app-advanced，日志消息的自动定时删除最先出现在永夜。

在 Yii 2.0 中，需要同时基于 MySQL ActiveRecord 与 Redis ActiveRecord 查询资源的实现

永夜 — Mon, 29 Jul 2019 09:00:26 +0000

本文针对 Yii 2.0 框架下需要基于 MySQL ActiveRecord 与 Redis ActiveRecord 同时查询资源的问题，实现了对 Redis 中存储的用户昵称进行模糊搜索的功能。鉴于 Redis ActiveRecord 不支持 like 操作符，文章采用先通过 MySQL 获取用户 ID 列表，再利用 in 操作符从 Redis 读取对应昵称数组，最后使用 PHP 函数模拟 SQL LIKE 语句进行过滤。测试结果表明，该方案能够正确生成符合预期的 SQL 语句并获取准确的查询结果。

在 Yii 2.0 中，需要同时基于 MySQL ActiveRecord 与 Redis ActiveRecord 查询资源的实现最先出现在永夜。

基于 Yii 2.0 实现的命令行脚本，持续运行期间，占用内存过高的分析与解决

永夜 — Wed, 24 Jul 2019 08:16:11 +0000

本文针对基于 Yii 2.0 的 Supervisor 命令行脚本在持续运行期间占用内存过高的问题进行了分析与解决。通过监控 Docker 容器资源，定位了 Redis AR 模型查询和高频执行导致的内存增长。优化措施包括使用 unset() 释放变量、利用 asArray() 获取数组形式结果、修复 HTTP 客户端 400 错误以及引入同步标识控制执行频率。最终测试表明，调整查询方式和执行策略有效降低了内存占用，证明了优化方案的可行性。

基于 Yii 2.0 实现的命令行脚本，持续运行期间，占用内存过高的分析与解决最先出现在永夜。

Yii 2 高级项目模板，国际化的消息翻译服务的 Bug (当目标语言为美国英语，文件映射的类别名为：app 时，未被映射到 PHP 文件 @app/messages/en-US/app.php) 的分析解决

永夜 — Fri, 19 Jul 2019 07:06:10 +0000

本文分析了 Yii 2 高级项目模板中，当目标语言为美国英语且文件映射类别名为 app 时，消息翻译未被映射到 PHP 文件的 Bug。通过调试发现，I18N 组件仅对第一层类别进行判断，导致自定义 app 类别被核心定义覆盖且 forceTranslation 值为 false。解决方案是将类别名及对应翻译文件从 app 重命名为 application，并更新配置代码与调用方法，从而确保消息被正确映射和翻译。

Yii 2 高级项目模板，国际化的消息翻译服务的 Bug (当目标语言为美国英语，文件映射的类别名为：app 时，未被映射到 PHP 文件 @app/messages/en-US/app.php) 的分析解决最先出现在永夜。