给定:即使使用SSD驱动器,每次调用BE模块也需要几秒钟的时间。(对于一般的BE任务,良好配置的设置运行时间低于1秒。)
- 可能的瓶颈是什么?
- 如何检查它们?
- 有哪些加速选项?
特意没有提供特殊配置,而是要求提供一个通用的清单,以便答案适用于许多人作为第一个入口点。
给定:即使使用SSD驱动器,每次调用BE模块也需要几秒钟的时间。(对于一般的BE任务,良好配置的设置运行时间低于1秒。)
特意没有提供特殊配置,而是要求提供一个通用的清单,以便答案适用于许多人作为第一个入口点。
$GLOBALS['TSFE']->set_no_cache()
将禁用所有缓存,因此您可以搜索该内容。TypoScript中的USER_INT
和COA_INT
也会为其中配置的任何内容禁用缓存。LIKE '%...%'
的查询,否则少于一百万条记录不应该太大的问题。还有一个方面可以检查:在用户记录中存储了很多东西,例如您在日志模块中使用的设置。
其中一项可能会消耗大量内存(以及序列化和反序列化所需的时间),即页面树的状态(哪些页面已展开/哪些没有展开)。
清理用户设置可以使该用户的后端更快。
如果您有一个庞大的页面树,而用户必须浏览许多页面,则效果将停滞不前。 另一个缺点是您将失去所有设置,因为仍然没有选择性的清除。
无法在此处发表评论,但需要说的是:TYPO3后端中的TSFE对象绝对没有任何作用。后端始终未被缓存。TYPO3后端是一个独立的模块,用于编辑和维护前端输出。有大量的谷歌搜索结果会忽略这一事实。
可能的性能瓶颈是编写不良的扩展,它们进行渲染或数据处理。钩子到核心函数通常不是什么大问题,但是为编辑表单呈现许多元素(特别是在TYPO3的Fluid模板引擎中)可能会导致性能问题。
Extbase-DBAL-Layer也可能导致严重的性能问题。原因是数据库模型不知道索引。这很简单但很愚蠢。对2000个记录以上的大表进行SQL连接将明显延迟输出,具体取决于数据模型。
TYPO3后端实际上并不依赖于Typoscript配置,但实际上要控制某些输出或由扩展加载,需要完全解析*.ts文件。而这个解析器非常缓慢。
如果您想加速事情的进展,您需要知道出了什么问题。调试这种行为的唯一方法是使用PHP分析工具(如xdebug)检查运行时,因为TYPO3框架非常复杂。它使用某种Doctrine框架,并且会在每个请求中加载大量文件。因此,良好配置的OpCache是必须的。
大多数原因使整个过程变慢是因为编写不良。您可以通过检查运行时来确认这一事实。
路由
数据库本身可能很快。但是对请求进行错误的路由仍然会使您变慢。即使在本地机器上,也要考虑防火墙、代理等因素,特别是如果使用了虚拟化。
数据库连接:
快速的数据库连接至关重要。如果数据库访问速度慢,TYPO3 就无法快速运行。
特别是由于 Extbase 的缘故,TYPO3 经常查询比实际所需更多的数据,并且更频繁地进行查询,因为许多关系都是在 PHP 层而不是 DB 层本身中解决的。加载诸如根行之类的数据结构可能会在 PHP 和 DB 层之间产生大量的乒乓。
我无法建议如何测量您的 DB 连接。您必须向管理员询问。您总是可以测试并与完全不同的环境中的另一个 DB 进行比较。
数据库的速度可能取决于数据库本身的类型。通常使用 MySQL/Maria-DB 应该很快。它还取决于上述因素,内存、文件访问和路由。
策略:
即使不是管理员,也没有使用所有性能工具,您仍然可以更换系统的部分并检查是否有所改善。通过这种方法,您可以定位问题而不必成为专家。一旦发现问题,谷歌可以帮助您获取更多信息。