如何加速 TYPO3 后端？答案

【问题标题】：How to speed up the TYPO3 Backend?如何加速 TYPO3 后端？
【发布时间】：2019-05-16 17:52:39
【问题描述】：

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

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

我特意不给特别的配置，而是求一个通用的checklist，这样回答适合很多人作为第一切入点。

【问题讨论】：

没有更多细节我只能给出一般的答案：在生产模式下运行，添加更多内存，添加更快/更多 CPU 内核，优化 PHP/webserver/database，添加缓存服务器
我要求提供适用于大量受众的一般性答案。

标签： performance typo3 backend

【解决方案1】：

关于 TYPO3 性能调整的一般提示可以在这里找到：https://wiki.typo3.org/Performance_tuning

但是，根据我的经验，最常见的性能问题是由以下几个原因之一引起的：

坏/没有缓存。通常这是一个或多个扩展（部分）禁用缓存的问题。尝试禁用所有第三方扩展并一一启用它们，以查看导致网站速度最慢的原因。 $GLOBALS['TSFE']->set_no_cache() 将禁用所有缓存，因此您可以搜索它。 TypoScript 中的 USER_INT 和 COA_INT 也会对其中配置的任何内容禁用缓存。
大量数据。检查数据库中是否有包含大量数据的表。多少构成“很多”，取决于很多因素，但通常低于一百万条记录的任何内容都不会有太大问题，除非例如您使用 LIKE '%...%' 对包含大量数据的字段进行查询.
服务器上没有足够的资源。要解决此问题，请向服务器添加更多内存和/或 CPU 内核。或者，如果它是共享服务器，请减少在其上运行的网站数量。
交通繁忙。无论服务器拥有多少资源，它在给定时间内可以处理的请求数量总是有限制的。如果这是您的问题，您将不得不研究负载平衡和缓存服务器。如果您（通常）没有很多访问者，那么高流量仍然可能是由于机器人抓取您的网站过快造成的。这些通常很容易在您的防火墙或网络服务器配置中阻止 IP 地址。

服务器上没有任何其他流量的慢后端（您是唯一可以访问它的人）排除 1（如果用户正在访问前端并导致服务器负载高，则只会导致后端慢）和 4 （没有其他流量）。

【讨论】：

【解决方案2】：

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

清理用户设置可以使该用户的后端速度更快。
如果你有一个大的页面树并且用户必须浏览许多页面，效果就会停止。另一个缺点：您会失去所有设置，因为仍然没有选择性清洁。

【讨论】：

【解决方案3】：

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

可能的性能瓶颈是执行渲染或数据处理的编写不佳的扩展。与核心功能挂钩通常没什么大不了的，但为编辑表单渲染许多元素（尤其是在 TYPO3s Fluid Template Engine 中）可能会导致性能问题。

Extbase-DBAL-Layer 也可能导致大量性能问题。原因是数据库模型不知道索引。这很简单但很愚蠢。在 2000 条记录的大表上执行 SQL-Join 会明显延迟输出，具体取决于数据模型。

此外，TYPO3 后端并不真正依赖于 Typoscript-Configuration，但实际上为了控制某些输出或通过扩展加载，需要对 *.ts 文件进行完整解析。而且这个解析器很慢。

如果你想加快速度，你需要知道哪里出了问题。调试此行为的唯一方法是使用诸如 xdebug 之类的 PHP 分析工具检查运行时，因为 TYPO3 框架非常复杂。它使用某种 Doctrine Framework 并会根据每个请求加载大量文件。因此配置好的 OpCache 是必须的。

整个过程缓慢的主要原因是它写得不好。您可以通过检查运行时来确认这一事实。

【讨论】：

我喜欢打破这个神话，即 TypoScript 解析器很慢。由于这个神话，我写了一个新的github.com/elmar-hinz/TX.tsp。当我实际测量当前解析器的速度时，我的结果告诉我它本身相当快。所以我没有进一步遵循这个。恕我直言，缓慢的是在解析 TypoScript 后执行的 PHP 代码，例如外部基地。很遗憾，TypoScript 解析器被指责为不是由它引起的缓慢。
感谢您注册回答我的问题。好的开始。
@Blcknx 我确实提到了解析器作为整个解析过程。独立部件可能很快，但如果已经处理的资源不会被存储以供以后快速访问，则不计算在内。默认情况下，TypoScript 甚至没有框架缓存，而是由每个请求解析。是的，有一点序列化，但几乎没用，因为它只存储再次序列化的 TypoScript，而不是对其进行解析和处理的片段。
序列化也胜过 PHP 脚本的解析，但 Fluid 仍然使用 PHP 文件作为缓存。那是我不明白的事情。 TYPO3 可能非常快，但开发人员无法正确分析那里的类和工作流程。优化是这里成功的关键。我对您的代码进行了快速概述，并看到了一些正则表达式部分。对于这样的解析器，正则表达式一点也不快。如果您正确使用它们，使用标记器会快得多。在循环中调用 count() 之类的事情也是需要优化的典型领域。在单线程应用程序中，每一毫秒都很重要。
要理解为什么这么多明显的发展如此缓慢，你必须了解核心团队的心态。它只是无法扩展。它无法真正整合社区中所有的知识和力量。这不是技术问题。这只是社会动态的问题。在这种社会动态中也是答案，为什么社区几乎仅限于德国。

【解决方案4】：

除了已经说过的，将运行时环境放到你的清单上：

内存：

如果同时打开重型 IDE 和其他工具，可用内存可能会成为问题。要检查内存配置文件，您可以启动一个工具来监控机器的内存使用情况。

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

如果需要并且可能的话，可以为您的机器增加更多内存。这不应该是对写得不好的代码的错误修复。糟糕的代码会炸毁任何大小的内存。

文件访问权限：

TYPO3 读取和写入数千个文件。如果您使用现代 SSD，这速度非常快。我确实测量了这个。加载 TYPO3 的所有类文件只需要几分之一秒。

但是，如果您不使用标准设置，这可能看起来会有所不同。许多因素可能会减慢您的速度：

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

有疑问测试并将您的文件和数据库存储在不同的驱动器上以评估行为。

路由

数据库本身可能很快。您的请求的错误路由可能仍会减慢您的速度。想想防火墙、代理等，即使在您的本地机器上，特别是在使用虚拟化的情况下。

数据库连接：

我快速的数据库连接是至关重要的。如果数据库访问很慢，TYPO3 不能很快。

特别是由于 Extbase TYPO3 经常查询比实际需要的更多的数据，而且比实际需要的更频繁，因为很多关系是在 PHP 层而不是 DB 层本身解决的。加载像根行这样的数据结构可能会导致 PHP 和 DB 层之间产生大量的乒乓。

我无法给出建议，如何衡量您的数据库连接。你必须作为你的管理员。您始终可以做的就是测试并与来自完全不同环境的另一个数据库进行比较。

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

策略：

即使没有管理员身份和了解所有性能工具，您也可以随时更换系统的某些部分并检查情况是否有所改善。通过这种方法，您无需成为专家即可定位罪魁祸首。一旦发现了罪魁祸首，Google 可能会帮助您获取更多信息。

当涉及到干净且高性能的路由或虚拟化设置时，最好咨询经验丰富的管理员。

总结

这都是其他人已经指出的。

真正有用的是 BE-Plugin，它可以分析和测量环境。可能有一些我不知道。

【讨论】：