如何加速TYPO3后台？

Question

给定：即使使用SSD驱动器，每次调用BE模块也需要几秒钟的时间。(对于一般的BE任务，良好配置的设置运行时间低于1秒。)

• 可能的瓶颈是什么？
• 如何检查它们？
• 有哪些加速选项？

特意没有提供特殊配置，而是要求提供一个通用的清单，以便答案适用于许多人作为第一个入口点。

- Blcknx

---

没有更多细节，我只能给出一般性的回答：以生产模式运行，增加更多内存，添加更快/更多CPU核心，优化PHP/web服务器/数据库，添加缓存服务器。 - Rudy Gnodde

我正在寻求适用于广大受众的一般性答案。 - Blcknx

Answer 1

您可以在此处找到有关TYPO3性能调优的一般提示：https://wiki.typo3.org/Performance_tuning。但是，根据我的经验，大多数一般性能问题都是由以下几个原因之一导致的：

1. 缓存不佳或没有缓存。通常，这是一个或多个扩展（部分）禁用缓存的问题。尝试禁用所有第三方扩展，并逐个启用它们，以查看哪个会导致网站变慢。使用$GLOBALS['TSFE']->set_no_cache()将禁用所有缓存，因此您可以搜索该内容。TypoScript中的USER_INT和COA_INT也会为其中配置的任何内容禁用缓存。

2. 数据量过大。检查数据库是否包含大量数据的表。什么数量算“大量”取决于很多因素，但通常除非您在包含大量数据的字段上执行类似LIKE '%...%'的查询，否则少于一百万条记录不应该太大的问题。

3. 服务器资源不足。要解决此问题，请向服务器添加更多内存和/或CPU核心。如果它是共享服务器，则减少在其上运行的站点数量。

4. 高流量。无论服务器拥有多少资源，它都会在给定时间内处理的请求数量上有限制。如果这是您的问题，则必须研究负载平衡和缓存服务器。如果您（通常）没有很多访问者，则高流量仍可能是由于机器人过快地爬行您的站点而引起的。这些通常可以在您的防火墙或Web服务器配置中通过IP地址轻松阻止。

在没有其他流量的情况下出现缓慢的后端（只有您可以访问它）排除了1（仅当用户访问前端并导致高服务器负载时才会导致缓慢的后端）和4（没有其他流量）。

- Rudy Gnodde

Answer 2

还有一个方面可以检查：在用户记录中存储了很多东西，例如您在日志模块中使用的设置。
其中一项可能会消耗大量内存（以及序列化和反序列化所需的时间），即页面树的状态（哪些页面已展开/哪些没有展开）。

清理用户设置可以使该用户的后端更快。
如果您有一个庞大的页面树，而用户必须浏览许多页面，则效果将停滞不前。 另一个缺点是您将失去所有设置，因为仍然没有选择性的清除。

- Bernd Wilke πφ

Answer 3

无法在此处发表评论，但需要说的是：TYPO3后端中的TSFE对象绝对没有任何作用。后端始终未被缓存。TYPO3后端是一个独立的模块，用于编辑和维护前端输出。有大量的谷歌搜索结果会忽略这一事实。

可能的性能瓶颈是编写不良的扩展，它们进行渲染或数据处理。钩子到核心函数通常不是什么大问题，但是为编辑表单呈现许多元素（特别是在TYPO3的Fluid模板引擎中）可能会导致性能问题。

Extbase-DBAL-Layer也可能导致严重的性能问题。原因是数据库模型不知道索引。这很简单但很愚蠢。对2000个记录以上的大表进行SQL连接将明显延迟输出，具体取决于数据模型。

TYPO3后端实际上并不依赖于Typoscript配置，但实际上要控制某些输出或由扩展加载，需要完全解析*.ts文件。而这个解析器非常缓慢。

如果您想加速事情的进展，您需要知道出了什么问题。调试这种行为的唯一方法是使用PHP分析工具（如xdebug）检查运行时，因为TYPO3框架非常复杂。它使用某种Doctrine框架，并且会在每个请求中加载大量文件。因此，良好配置的OpCache是必须的。

大多数原因使整个过程变慢是因为编写不良。您可以通过检查运行时来确认这一事实。

- Coderoy

---

我喜欢打破一个谣言，即 TypoScript 解析器很慢。由于这个谣言，我写了一个新的 https://github.com/elmar-hinz/TX.tsp。当我实际测量当前解析器的速度时，我的结果告诉我它本身相当快。所以我没有进一步跟进这个问题。在我看来，慢的是在 TypoScript 解析之后执行的 PHP 代码，例如 Extbase。很遗憾 TypoScript 解析器被指责为缓慢，而这并不是由它引起的。 - Blcknx

感谢您注册回答我的问题。很好的开始。 - Blcknx

@Blcknx 我提到了解析器作为整个解析过程。它可能对独立部分快速，但如果已经处理的资源不会被存储以供后续快速访问，则这并不重要。默认情况下甚至没有 TypoScript 的框架缓存，每个请求都会进行解析。是的，有一些序列化，但几乎没有用，因为它只是再次序列化 TypoScript，而不是解析和处理它们的片段。 - Coderoy

要理解为什么许多显而易见的发展如此缓慢，您必须了解核心团队的心态。它只是无法扩展。它不能真正整合社区中存在的所有知识和力量。这不是技术问题。这只是社会动态的问题。在这种社会动态中，也可以找到答案，为什么社区几乎局限于德国。 - Blcknx

只要它能正常工作，我就不会反对有用的正则表达式，但它比 PHP 中愚蠢的字符串函数慢。它还取决于您想要实现什么。个人而言，我不会将其用于复杂的脚本解析器，因为正则表达式可能无法捕获有效的输入。当然，如果您已经使用自己的逻辑进行了标记化，然后使用它来验证字符串，这将产生巨大的差异。我完全同意 TYPO3 核心团队的社交动态。每个发现错误或想要实现更好解决方案的开发人员都必须处理它：\ - Coderoy

Answer 4

除了已经提到的内容，将运行环境添加到您的检查清单中： 内存： 如果同时打开了重量级IDE和其他工具，则可用内存可能成为问题。要检查内存配置文件，可以启动一个监视机器内存使用情况的工具。

如果使用虚拟化，请检查分配给盒子的内存。尝试分配更多内存是否改善了行为。

如果需要并且可能，将更多内存分配给您的计算机。这不应该是修复糟糕代码的补丁。糟糕的代码可以使任何大小的内存崩溃。 文件访问： TYPO3读写数千个文件。如果您使用现代SSD，这是惊人地快速。我测量过这个。加载TYPO3的所有类文件只需要一小部分秒钟。

但是，如果您不使用标准设置，则可能会看起来不同。许多因素可能会使您变慢：

- USB作为存储。 - 存储卡作为存储。 - 由于缓慢的驱动程序，所有类型的外部存储可能会受到限制。 - 虚拟化可能会成为一个问题。再次，这是一个驱动程序的问题。

如有疑问，请测试并将文件和数据库存储在不同的驱动器上以比较行为。

路由

数据库本身可能很快。但是对请求进行错误的路由仍然会使您变慢。即使在本地机器上，也要考虑防火墙、代理等因素，特别是如果使用了虚拟化。

数据库连接：

快速的数据库连接至关重要。如果数据库访问速度慢，TYPO3 就无法快速运行。

特别是由于 Extbase 的缘故，TYPO3 经常查询比实际所需更多的数据，并且更频繁地进行查询，因为许多关系都是在 PHP 层而不是 DB 层本身中解决的。加载诸如根行之类的数据结构可能会在 PHP 和 DB 层之间产生大量的乒乓。

我无法建议如何测量您的 DB 连接。您必须向管理员询问。您总是可以测试并与完全不同的环境中的另一个 DB 进行比较。

数据库的速度可能取决于数据库本身的类型。通常使用 MySQL/Maria-DB 应该很快。它还取决于上述因素，内存、文件访问和路由。

策略：

即使不是管理员，也没有使用所有性能工具，您仍然可以更换系统的部分并检查是否有所改善。通过这种方法，您可以定位问题而不必成为专家。一旦发现问题，谷歌可以帮助您获取更多信息。

当涉及到路由或虚拟化的清洁和高效设置时，向经验丰富的管理员询问仍然是最好的想法。

总结：

这些都是其他人已经指出的补充内容。

真正有用的是一个能够分析和测量环境的BE-插件。也许有一些我不知道的。

- Blcknx