有效提高ThinkPHP的应用性能的几点建议

Posted 2023-04-30

参考技术A 架构优化涉及到技术、存储、网络、服务的选型和构架，尽量使用成熟和现代的开发架构和设计模式。前后端完全分离设计，便于前后端的独立优化，也更加便于测试工作。

如果你的应用遇到了性能瓶颈，这个时候要考虑的就是优化架构而不是优化代码本身，因为架构层面的优化效果往往是最显著的。

架构的优化需要根据自身运营情况来调整，切忌不可按图索骥提前优化，反而容易得不偿失，导致技术成本提高甚至“负优化”

部署环境千万不要忘记关闭调试模式，这不仅仅是出于性能考虑，更多是基于安全因素。事实上，建议通过环境变量来配置关闭调试模式，这样部署后不需要更改任何配置文件。

因为调试模式影响日志记录信息、额外的调试信息和缓存失效，关闭调试模式能够带来一定的性能提升

使用多模块功能会增加文件的 I/O 开销和额外的配置及检查，如非必要在规划你的应用架构的时候尽量考虑使用单一模块，然后使用控制器分级来解决控制器过多的问题。

使用单一模块的性能优势，在部署到 swoole 的时候可以得到更加充分的体现，因为应用文件一旦启动服务，就会载入内存，而模块的相关文件则会每次请求重新加载。

在定义路由规则的时候，不要使用数组方式，尽量使用方法注册路由，并且多使用路由分组（或者资源路由）。分组路由可以减少路由的匹配次数，从而提升路由性能。如果你有多个域名的不同路由，也要按域名规划使用路由。

尽可能设计在路由中进行当前路由的数据验证和权限检查等操作，一方面比较清晰，另外一方面可以尽量把验证操作提前，而不必等到控制器执行。

在分组比较多的情况下，开启路由的延迟解析。

如果同一个分组下面有比较多的路由规则，建议合并路由规则

对于 GET 请求的路由，可以设置路由的请求缓存。

部署阶段，可以开启路由缓存。

首先保持良好的开发习惯，了解 Db类和模型的正确使用姿势 ，数据库本身的性能优化可以参考 mysql性能优化的最佳21条经验 ，下面主要是对框架中数据查询相关的优化策略。

尽量减少每次请求的查询次数，并对实时性要求不高的数据查询合理规划数据查询缓存（优先考虑使用 Redis 缓存）

如果使用了关联查询， cache 方法只能用于主模型的数据缓存，但你可以使用 Cache 类的 remember 方法进行方便的数据缓存。

尽量减少查询次数是出于性能考虑，但不是必须，使用最少的查询不代表性能就一定是最高。一个复杂的 JOIN 查询性能不见得有两次简单的查询高，而使用简单的查询反而更清晰易懂，并且更方便进行数据查询缓存。

不要总是以为模型的性能一定比 Db 类低，框架的ORM查询设计经过了较为合理的优化，正确使用模型一样可以有出色的性能，而且比 Db 查询要方便很多。

尤其是对于一些复杂的设计来说使用模型关联显得比直接用Db更加简单，例如使用关联预载入查询就可以避免 N+1 查询问题。

如果用 Db 类自己实现的话，费时费力，性能还不一定优。

对于内存开销比较大的应用，在做大量数据查询和处理的时候，使用 cursor 方法，可以利用php的生成器特性，减少内存占用。

你会发现用户数据不论是1万还是10万级别，内存开销并没有大的变化。

涉及到对大量数据的处理，包括数据迁移、批量更新，尽量使用命令行指令运行，否则会因为超时而中断

可以通过数据集的方法完成的子集或者排序操作不要再次查询，例如：

利用下面指令在部署后生成字段缓存，可以减少每次数据表的字段查询开销。

注意：一旦数据库的表结构发生变化，必须重新生成。

每次在应用初始化或者模块初始化的时候会有一定的 I/O 开销，如果已经开启 OpCache 的话对性能影响甚微，如果比较在意的也可以通过命令行指令生成配置缓存（包括相关的公共文件和各种定义文件）。

生成应用配置缓存：

生成模块配置缓存：

注意：一旦配置或者公共文件发生变化，必须重新生成。

类库映射可以提升类库的自动加载性能，使用下面的指令可以生成系统类库和应用类库的类库映射（包括 extend 目录下的类库）。

vendor 目录下的类库可以使用 composer 的 dump-autoload 指令优化加载性能。

该命令把 PSR-0 和 PSR-4 转换为一个类映射表，来提高类的加载速度。

优化Webpack构建性能的几点建议

Webpack 作为目前最流行的前端构建工具之一，在 vue/react 等 Framework 的生态圈中都占据重要地位。在开发现代 Web 应用的过程中，Webpack 和我们的开发过程和发布过程都息息相关，如何改善 Webpack 构建打包的性能也关系到我们开发和发布部署的效率。

以下是一些关于优化 Webpack 构建性能的几点建议：

一、选择合适的 Devtool 版本

webpack 的 devtool 配置，决定了在构建过程中怎样生成 sourceMap 文件。通常来说eval的性能最高，但是不能生成的 sourceMap 文件解析出来的代码，和源代码差异较大。 source-map 的性能较差，但是可以生成原始版本的代码。 在大多数 Development 场景下 cheap-module-eval-source-map 是最佳的选择。

下图是各个 Devtool 配置的对比（+号越多，代表速度越快，-号越多，代表速度越慢, o代表中等速度）

 

注意* ： 在 production 配置中，如果需要生成 sourceMap 文件来进行异常分析， 应该使用 hidden-source-map 或者 nosources-source-map, source-map 等配置。并且不要把 sourceMap 文件也放在部署目录下。

 

二、Build Cache

Webpack 和一些 Plugin/Loader 都有 Cache 选项。开启 Cache 选项，有利用提高构建性能。

比如：使用 babel-loader 的时候开启 cacheDirectory 选项，会较为明显的提升构建速度

 module: {
    rules: [{
        test: /\.js$/,
        use: ['babel-loader?cacheDirectory'],
        include: path.join(__dirname, 'app')
    }]
 }

 

三、减少代码体积

• 使用 CommonsChunksPlugin 提取多个 chunk 之间的通用模块，减少总体的代码体积

• 把部分依赖转移到 CDN 上，避免在每次编译过程中都由 Webpack 处理

• 对于支持局部引入的类库，在开发的过程中使用局部引入的方式，避免引入无用的文件

比如 lodash 就支持部分引入：

import isArray from 'lodash/isArray';

参考： [Don't import whole lodash] (https://github.com/lodash/lodash/issues/3450)

 

在进行这一优化手段的时候，可以借助可视化工具进行 chunk 体积和内容的分析。方便进一步调整 webpack 的配置。主要有以下两种方法：

1. 使用 webpack 的 profile 命令生成 JSON 文件，并且把 JSON 上传到相应的在线网站进行可视化分析。

```bash
webpack --profile --json > stat.json
```

使用 webpack-visualizer 进行分析：

2. 使用第三方 plugin，在编译过程中进行体积分析，并且以图表方式输出：

推荐使用 webpack-bundle-analyzer:

 

四、减少目录检索范围

在使用 loader 的时候，通过指定 exclude 和 incude 选项，减少 loader 遍历的目录范围，从而加快 Webpack 编译速度。

比如指定 babel-loader 只处理业务代码：

{
   test: /\.js$/,
   use: ['babel-loader'],
   include: path.join(__dirname, 'app')
}

 

五、减少检索路径

resolve.alias 可以配置 webpack 模块解析的别名，对于比较深的解析路径，可以对其配置 alias. 可以提升 webpack 的构建速度。

alias: {
  Utilities: path.resolve(__dirname, 'src/utilities/'),
  Templates: path.resolve(__dirname, 'src/templates/')
}

 

六、使用 DllPlugin/DllReferencePlugin 进行预先构建

Webpack 的 DllPlugin 和 DllReferencePlugin 是在新版本中推出的 Plugin，其思路就是把改变频率比较小的第三方库等依赖单独打包构建，在打包整个项目的时候，如果解析到了通过 Dll 形式进行打包的依赖，会在正常的打包过程中跳过，同时把对这些依赖的引入导入到 Dll 模块上去。 这样会大大提升在对业务代码进行打包时候的速度。

1. 新建一个单独的 webpack 配置文件，比如 webpack.dll.config.js

2. 在这个配置文件中，使用 webpack DllPlugin 生成 manifest.json 文件和 Dll 模块文件。也可以引入诸如 uglifyPlugin 对第三方依赖进行压缩等处理。

import path from 'path';
import pkg from './package.json';
import webpack from 'webpack';var vendorPackages = Object.keys(pkg.dependencies);const config = {
entry: {
     vendor: vendorPackages
     },
output: {
     filename: 'dll.[name].js',
     path: path.resolve(__dirname, 'build', 'dll'),
     library: '[name]'
      },
plugins: [     new webpack.DllPlugin({
           context: __dirname,
           name: "[name]_[hash]",
           path: path.join(__dirname, "manifest.json"),
     }),     new webpack.optimize.UglifyJsPlugin({
           sourceMap: true,
           minimize: true,
           cache: true,
           parallel: true
       }),
     ]
}
   export default config;

3. 在正常的 webpack 配置文件中，使用 webpack DllReferencePlugin 解析上一步生成的 manifest.json

new webpack.DllReferencePlugin({
        context: path.join(__dirname),
        manifest: require('./manifest.json')
})

在具体的使用过成中， 在 Dll 中包含的依赖没有变化的场景下，可以先执行单次 webpack --config webpack.dll.config.js。然后可以多次执行业务代码的构建过程。由于把第三方依赖进行了剥离，业务代码的构建会快很多。

以下是一些关于 Webpack 构建性能的文章：

1)：使用 DllPlugin 提升性能

2）: PrefetchPlugin 的使用

3）: webpack 打包分析与性能优化

4）: webpack 使用优化

转载请注明出自：葡萄城控件

关于葡萄城

葡萄城成立于1980年，是全球最大的控件提供商，世界领先的企业应用定制工具、企业报表和商业智能解决方案提供商，为超过75%的全球财富500强企业提供服务。葡萄城于1988年在中国设立研发中心，在全球化产品的研发过程中，不断适应中国市场的本地需求，并为软件企业和各行业的信息化提供优秀的软件工具和咨询服务。