性能优化¶
下面是用于 OTRS 安装的性能增强技术清单，包括配置、编码、内存使用等。
工单索引模块¶
可以在系统配置设置 Ticket::IndexModule 中设置工单索引模块。 工单队列视图的索引有两个后端模块：
Kernel::System::Ticket::IndexAccelerator::RuntimeDB- 这是默认选项，并将从工单表中即时生成每个队列视图。 在有6万个处理工单之前，系统都不会遇到性能问题。
Kernel::System::Ticket::IndexAccelerator::StaticDB当您有超过80,000个处理中的工单时，应该使用这个最强大的模块。 它使用一个额外的
ticket_index表，用基于工单数据的关键字填充。 在切换后端模块后使用下列命令生成初始索引：otrs> /opt/otrs/bin/otrs.Console.pl Maint::Ticket::QueueIndexRebuild
工单搜索索引¶
OTRS 使用特殊的搜索索引对来自不同通信渠道的信件中的字段进行全文搜索。
使用这个命令生成初始索引：
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Ticket::FulltextIndex --rebuild
注解
实际的信件索引通过后台的 OTRS 守护进程任务进行。 虽然刚刚添加到系统中的信件被标记为立即进行索引，但其索引可能在几分钟后才可用。
有一些选项可用于微调搜索索引：
Ticket::SearchIndex::Attribute全文索引的基本设置。
Ticket::SearchIndex::Attribute设置注解
运行以下命令以生成新索引：
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Ticket::FulltextIndexRebuild
WordCountMax- 定义用以构建索引的最大字数。 例如，只有信件正文的前1000个单词存储在信件搜索索引中。
WordLengthMin和WordLengthMax- 用作字长边界。 只有具有这两个值之间长度的单词才会存储在信件搜索索引中。
Ticket::SearchIndex::Filters全文索引正则表达式过滤器，用于删除部分文本。
Ticket::SearchIndex::Filters设置定义了三个默认过滤器：
- 第一个过滤器剥离特殊的字符，如： , & < > ? ” ! * | ; [ ] ( ) + $ ^ =
- 第二个过滤器剥离使用以下字符之一开始或结束的字词： ‘ : 。
- 第三个过滤器剥离不包含字符的单词：a-z, A-Z, 0-9, _
Ticket::SearchIndex::StopWords全文索引的英语停止词，这些词将从搜索索引中移除。
Ticket::SearchIndex::StopWords###en设置有一些语言定义了所谓的停止词。 创建搜索索引时将跳过这些停止词。
参见
如果您的语言不在系统配置设置中，或者您想要添加更多单词，则可以将它们添加到此设置：
Ticket::SearchIndex::StopWords###Custom
文件搜索¶
OTRS uses Elasticsearch for its document search functionality. For a good introduction into the concepts, installation and usage of Elasticsearch, please follow the Quick start chapter in the official documentation.
堆大小¶
Elasticsearch 是用 Java 编写的，因此可以在任何集群节点上的 Java 虚拟机（JVM）中运行。 JVM使用称为 heap（堆） 的一部分内存，其大小可以在配置文件 jvm.options 中配置。
堆最小和最大配置默认设置为 1 GB，可以使用以下选项进行修改：
Xms1g：堆最小值为1GB。Xmx1g：堆最大值为1GB。
如果 Xms 的值低于 Xmx，则 JVM 将在超过当前限制时调整使用的堆的大小，直到达到 Xmx 的值。 这样的大小调整导致服务暂停直到它完成，这可能降低搜索或索引动作的速度和反应性。 因此，强烈建议将它们设置为相等的值。
警告
如果超出了最大堆大小，则相关的群集节点将停止工作，甚至可能会关闭该服务。
设置的堆最大值越高，Elasticsearch 可以使用的内存越多，这也会增加 JVM 完成垃圾收集可能的暂停。 因此，建议为 Xmx 设置一个不高于物理内存 50％ 的值。
For more information and good rules of thumb about the heap size, please follow the Setting the heap size chapter in the official documentation.
磁盘分配¶
在服务运行期间，Elasticsearch 会检查可用磁盘空间，因此决定是否将新分片分配给相关群集节点，甚至是将分片重新定位到特定节点之外。 这种行为将由当前磁盘容量控制，可以在配置文件 elasticsearch.yml 中配置。 随附一些重要的配置，它们具有良好但可能很重要的默认值：
cluster.routing.allocation.disk.watermark.low- 默认值为85％。 如果超出此限制，Elasticsearch 将不会将更多分片分配给相关的群集节点。 该节点的操作不受影响，仍然可以索引和搜索数据。
cluster.routing.allocation.disk.watermark.high- 默认值为90％。 如果超出此限制，Elasticsearch 将尝试将现有分片重定位到具有足够可用空间的其它节点（如果有）。
cluster.routing.allocation.disk.watermark.flood_stage- 默认值为95％。 如果超出此限制，Elasticsearch 会将所有索引的配置更新为只读索引块
index.blocks.read_only_allow_delete，其中至少有一个分片分配给相关的群集节点。 从那时起，无法将新数据索引到此类索引并限制为仅搜索和删除操作。
注解
如果超出泛洪阶段并且某些索引配置为只读模式，则 Elasticsearch 不会 自动更改此配置。 如果相关磁盘由于手动操作而再次包含足够的可用空间，则需要手动将配置更改回正常模式。
For more information about disk watermarks and disk-based shard allocation, please follow the Disk-based Shard Allocation chapter in the official documentation.
信件存储¶
有两种不同的后端模块可用于存储电话、电子邮件和内部信件。 使用的信件存储可以在设置 Ticket::Article::Backend::MIMEBase::ArticleStorage 中配置。
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB此默认模块将附件存储在数据库中。 它也适用于多个前端服务器，但在数据库中需要很多存储空间。
注解
在大型安装环境中不要使用它。
Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageFS使用此模块可在本地文件系统上存储附件。 它很快，但如果您有多个前端服务器，则必须确保文件系统在服务器之间共享。 将其放在 NFS 共享上或者最好是 SAN 或类似的解决方案中。
注解
在大型安装环境中推荐使用。
您可以在运行中从一个后端切换到另一个后端。 您可以在系统配置中切换后端，然后运行此命令行实用程序将数据库中的信件放到文件系统上，反之亦然：
otrs> /opt/otrs/bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS
您可以使用 --target 选项指定目标后端。
注解
整个过程可能需要相当长的时间，具体取决于您拥有的信件数量以及可用的 CPU 资源和/或网络容量。
如果要在数据库中保留原有附件，可以激活系统配置选项 Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends 以确保 OTRS 仍然可以找到它们。
归档工单¶
由于 OTRS 可以用作审核系统，删除关闭的工单可能不是一个好主意。 因此，我们实现了一个可以让您归档工单的功能。
匹配某个条件的工单可以标记为“已归档”。这些工单在使用常规的工单搜索或运行一个自动任务时无法访问。系统本身不再需要处理大量的工单，而只考虑 最近的 工单就可以了。这在大型系统中能带来巨大的性能提升。
要使用归档功能：
激活系统配置中的
Ticket::ArchiveSystem设置。定义一个自动任务：
- 在 自动任务 屏幕中点击 添加任务 按钮。
- 任务设置：提供归档任务的名称。
- 自动执行：为计划该任务选择合适的选项。
- 选择工单：最好只将几个月前就关闭了的处于关闭状态的工单归档。
- 更新/添加工单属性：设置 归档选中的工单 字段为 归档工单。
- 在页面底部保存该任务。
- 点击概览表格中的 运行该任务 链接以查看受影响的工单。
- 点击 运行任务 按钮。
注解
手动运行此任务最多可以修改5000个工单。
当你搜索工单时，系统默认搜索未归档的工单。
为了搜索归档的工单：
- 打开工单搜索屏幕。
- 设置 归档搜索 为 未归档工单 或 所有工单。
- 执行搜索。
优化 Web 服务器¶
OTRS 的内置 Web 服务器可以开箱即用地处理中小型安装。 当 OTRS 同时为许多用户提供服务时，可能需要调整 Web 服务器配置，比如增加工作进程的数量。
Web 服务器配置文件位于 Kernel/WebApp.conf，并且所有设置均有文档说明。 可以增加 worker 设置，以在有能力的服务器上部署更多进程，用于处理 HTTP 请求。
缓存¶
OTRS 在 /opt/otrs/var/tmp 中缓存了大量临时数据。 请确保它使用高性能文件系统和存储。 如果你有足够的 RAM，你也可以尝试将这个目录放在 ramdisk 上，如下所示：
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
otrs> /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
root> mount -o size=16G -t tmpfs none /opt/otrs/var/tmp
注解
在 /etc/fstab 中添加永久性挂载点。
警告
这将是一个非永久性存储，在服务器重启时会丢失，所有的会话（如果将它们存储在文件系统中）和缓存数据都将丢失。
集群¶
For very high loads, it can be required to operate OTRS on a cluster of multiple front end servers. This is a complex task with many pitfalls. Therefore, OTRS Group provides support for clusters in its managed OTRS environment exclusively.
Limits of Objects¶
There is no technical limitation of how many objects can be used in the system but using high number of objects may affect the system performance. The proposed limits apply only to objects that are set as valid. The objects set as invalid or invalid-temporarily are not used by the system.
To keep the system fast and responsive the following limits for valid objects should not be exceeded:
- Mail accounts: 10
- Postmaster filters: 50
- ACLs: 80
- Dynamic fields: 300
- Dynamic field dropdown or multiselect values per field: 100
- Services: 500
- SLAs: 50
- Queues: 200
- Configuration item classes: 20
- Configuration item objects: 20,000
- Processes: 50
- Generic agents: 30 (frequency max once per hour per generic agent)
- Ticket states: 20
- Ticket types: 10
- Appointment calendars: 50