下面thinkphp框架教程专栏将为您介绍如何有效提升ThinkPHP的应用性能。 希望对有需要的同事有所帮助！说到应用程序性能，涉及到的方面太多了。 有关于服务器优化和后端优化的文章。
下面thinkphp框架教程专栏将为您介绍如何有效提升ThinkPHP的应用性能。 希望对有需要的同事有所帮助！
当谈到应用程序性能时，涉及到的方面太多了。 关于服务器优化和后端优化，网上有很多文章，这里不再赘述。 本文仅简单介绍ThinkPHP 5.1应用开发（尤其是部署环境）中可能涉及到的一些性能优化方法和注意事项。
推荐：《ThinkPHP 5.1 全球首发视频教程》
首先指出一件事：应用性能的困境不是框架，而是架构设计、数据库和人才。 框架在设计之初，为了通用性，不会专门针对某个应用进行深度优化，而是提供了一些可能的手段和配置参数，供您进行针对性的调优。 下面列出了一些可能的优化。 开发过程中可以根据情况调整手段。
正确的性能优化步骤应该是：架构优化、数据库优化、代码优化。
1、架构优化
架构优化涉及技术、存储、网络、服务的选型和架构。 尝试使用成熟、现代的开发架构和设计模式。 前端与前端完全分离设计，方便前端与前端独立优化，也让测试变得更加容易。
如果你的应用遇到性能困难，此时你需要考虑的是优化架构而不是优化代码本身，因为架构层面的优化效果往往是最明显的。
2.关闭调试模式
不要忘记在部署环境中关闭调试模式。 这不仅是出于性能原因，也是出于安全原因。 实际上，建议通过环境变量来配置调试模式，这样部署后就不需要修改配置文件了。
由于调试模式会影响日志信息、附加调试信息以及缓存失效，因此关闭调试模式可以带来一定的性能提升。
3. 使用单一模块
使用多模块功能将减少文件I/O开销以及额外的配置和检测。 如果没有必要，在规划应用架构时尽量考虑使用单个模块，然后使用控制器层次结构来解决控制器过多的问题。 。
使用单个模块的性能优势在部署到swoole时可以更充分的展现出来，因为应用程序文件一旦启动服务就会被加载到显存中，每次启动都会重新加载该模块的相关文件要求。
4. 路由设计与优化
定义路由规则时php 提高，不要使用链表方法，尽量使用注册路由的方法，多使用路由组（或资源路由）。 组路由可以减少路由匹配的次数，从而提高路由性能。 如果您对多个域名有不同的路由，您还应该计划使用基于域名的路由。
尝试在路由中设计当前路由的数据验证、权限检测等操作。 一方面，比较明确。 另一方面php 提高，可以尽早进行验证操作，而无需等待控制器执行。
当报文较多时，启用路由延迟解析。
// 开启路由延迟解析 'url_lazy_route' => true,
如果同一个组下有多个路由规则，建议合并路由规则。
// 合并分组路由规则 'route_rule_merge' => true,
对于带有 GET 请求的路由，您可以设置路由的请求缓存。
// 定义GET请求路由规则 并设置3600秒的缓存
Route::get('new/:id','News/read')->cache(3600);
在部署阶段，可以开启路由缓存。
// 开启路由缓存（仅部署模式有效） 'route_check_cache' => true,
5. 查询优化
首先，保持良好的开发习惯，了解Db类和模型的正确用法。 对于数据库本身的性能优化，可以参考MySQL性能优化的21条最佳经验。 下面主要是框架中数据查询相关的优化策略。
正确使用查询缓存
尽量减少每次请求的查询次数，对于实时性要求不高的数据查询，合理规划数据查询缓存（优先使用redis缓存）。
Blog::where('id', 10)
->cache(30)
->find();
如果使用关联查询，则cache方法只能用于主模型的数据缓存，但可以使用Cache类的remember方法来方便地进行数据缓存。
$users = Cache::remember('users', function(){
return User::with('profile')
->where('status', 1)
->select();},30);
不用太担心查询数量
最小化查询数量是出于性能原因，但不是必需的。 使用最少的查询并不一定意味着最高的性能。 一个复杂的JOIN查询的性能可能没有两个简单查询那么高，但是使用简单查询更清晰易懂，而且更方便缓存数据查询。
正确使用模型关联
不要总认为模型的性能一定低于Db类。 框架的ORM查询设计得到了合理的优化。 如果正确使用模型，仍然可以有出色的性能，而且比 Db 查询方便得多。
特别是对于一些复杂的设计，使用模型关联变得比直接使用 Db 更容易。 例如，使用关联预加载查询可以防止N+1查询问题。
User::with(['profile','book'])->select();
如果自己使用Db类来实现的话，会费时费力，而且性能也可能不会优秀。
海量数据处理优化
对于处理大量数据，请使用块批处理。
User::chunk(100, function($users) {
foreach ($users as $user) {
// 处理数据
}});
对于需要大量显存的应用程序，在进行大量数据查询和处理时，使用游标方法可以利用PHP的生成器特性来减少显存的使用。
$cursor = User::cursor();foreach($cursor as $user){
// 处理数据
}
你会发现，无论用户数据是10000条还是100000条，内存消耗都没有明显变化。
当涉及到大量数据的处理，包括数据迁移、批量更新时，尽量使用命令行指令来运行，否则会因超时而中断。
充分利用数据集，避免多次查询
对于可以通过数据集完成的取子集或排序操作，不要再次查询，例如：
// 模型查询返回数据集对象
$users = User::select();
// 按照用户的成绩由高到低排序
$list1 = $users->order('score', 'desc');
// 筛选成绩在90分以上的用户
$list2 = $users->where('score', '>=', 90);
字段缓存
部署后使用以下命令生成主键缓存，可以减少每个数据表的主键查询成本。
php think optimize:schema
更多使用方法请参考数据数组缓存官方指南。
6.0 配置和公共文件缓存
每次初始化应用程序或初始化模块时，都会有一定的I/O消耗。 如果OpCache已经开启，对性能影响不大。 如果你关心的话，还可以通过命令行指令生成配置缓存（包括相关的公共的）。 文件和各种定义文件）。
生成应用程序配置缓存：
php think optimize:config
生成模块配置缓存：
php think optimize:config index
注意：配置或公共文件一旦更改，必须重新生成。
7.0 生成通用映射
类库映射可以提高手动加载泛型的性能。 使用以下说明生成系统泛型和应用程序泛型（包括扩展目录中的泛型）的泛型映射。
php think optimize:autoload
vendor目录中的泛型可以使用composer的dump-autoload指令来优化加载性能。
composer dump-autoload -o
该命令将PSR-0和PSR-4转换为类映射表，以提高类加载速度。
