第 7 章性能优化
上一页		下一页

第 7 章性能优化

摘要

下面是OTRS安装（包括配置）、编码、内存使用及其它方面的性能增强技术的清单。

OTRS

TicketIndexModule 工单索引模块
工单搜索索引
信件存储 (电子邮件、电话和内部信件)
归档工单
缓存

提升OTRS性能有如下一些方法。

TicketIndexModule 工单索引模块

工单队列视图的索引有两个后端模块：

Kernel::System::Ticket::IndexAccelerator::RuntimeDB: 这是默认选项，并将从工单表中即时生成每个队列视图。在有6万个处理工单之前，系统都不会遇到性能问题。
Kernel::System::Ticket::IndexAccelerator::StaticDB: 当您有超过80,000个处理中的工单时，应该使用最强大的模块。它使用一个额外的ticket_index表，用基于工单数据的关键字填充。在切换后端模块后使用bin/otrs.Console.pl Maint::Ticket::QueueIndexRebuild生成初始索引。

你可以通过系统配置来修改使用的IndexAccelerator模块。

工单搜索索引

OTRS使用特殊的搜索索引对来自不同通信渠道的信件中的字段进行全文搜索。

要创建一个初始索引，请使用bin/otrs.Console.pl Maint::Ticket::FulltextIndex --rebuild。

注意

实际的信件索引通过后台的OTRS守护进程任务进行。虽然刚刚添加到系统中的信件被标记为立即进行索引，但其索引可能在几分钟后才可用。

有一些选项可用于微调搜索索引：

Ticket::SearchIndex::IndexArchivedTickets

定义归档工单是否将包含在搜索索引中（默认情况下关闭）。建议在有归档工单的大型系统上保持较小的索引。如果这个选项关闭了，全文搜索将不搜索归档的工单。。

Ticket::SearchIndex::Attribute

属性 WordCountMax 定义将被处理以构建索引的最大字数。例如，信件主体的前1000个词存储在信件搜索索引中。 WordLengthMin和WordLengthMax属性用作字长边界。只有长度在这两个值之间的单词才存储在信件搜索索引中。

Ticket::SearchIndex::Filters

定义了三个默认过滤器：

第一个过滤器剥离特殊的字符，如：, & < > ? " ! * | ; [ ] ( ) + $ ^=
第二个过滤器剥离使用以下字符之一开始或结束的字词：' : .
第三个过滤器剥离不包含字符的单词：a-z, A-Z, 0-9, _

Ticket::SearchIndex::StopWords

有一些语言定义了所谓的停止词。创建搜索索引时将跳过这些停止词。

信件存储 (电子邮件、电话和内部信件)

用于电话、电子邮件和内部信件的信件存储有两个不同的后端模块（通过 Ticket::Article::Backend::MIMEBase::ArticleStorage配置）：

Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageDB

这个默认模块将附件存储在数据库中。

注意

在大型安装环境中不要使用它。

优点：可与多个前端服务器配合使用。

缺点：在数据库中需要大量的存储空间。

Kernel::System::Ticket::Article::Backend::MIMEBase::ArticleStorageFS

使用此模块将附件存储在本地文件系统上。

注意

在大型安装环境中推荐使用。

优点：它很快！

缺点：如果有多个前端服务器，则必须确保文件系统在服务器之间共享。将其放置在NFS共享或最好是SAN或类似解决方案中。

注意

你可以动态切换存储后端，切换后运行命令行工具bin/otrs.Console.pl Admin::Article::StorageSwitch来将文档从数据库放到文件系统中，或者从文件系统放到数据库中。你可以使用--target 选项来指定目标后端。请注意：整个过程可能会花费相当长的时间，取决于你拥有文档的数量以及可用的CPU能力和/或网络带宽。

shell> bin/otrs.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

脚本: 切换存储后端，从数据库切换到文件系统。

如果要在数据库中保留旧附件，可以激活系统配置选项Ticket::Article::Backend::MIMEBase::CheckAllStorageBackends以确保OTRS仍然可以找到它们。

归档工单

由于OTRS可以用作审核系统，删除关闭的工单可能不是一个好主意。因此，我们实现了一个可以让您归档工单的功能。

匹配某个条件的工单可以标记为“已归档”。这些工单在使用常规的工单搜索或运行一个自动任务时无法访问。系统本身不再需要处理大量的工单，而只考虑‘最近’的工单就可以了。这在大型系统中能带来巨大的性能提升。

要使用归档功能，只需按照以下步骤操作：

在系统配置中激活归档系统
在系统管理页面中，进入系统管理后选择Ticket（工单）组，在Core::Ticket中找到选项Ticket::ArchiveSystem，默认设置为“否”。修改这个选项为“是”并保存。
定义一个自动任务
在系统管理页面，选择‘GenericAgent自动任务’并添加一个新任务。
1. 任务设置
  为归档任务提供一个名称，并选择合适的选项来计划这个任务。
2. 工单过滤
  工单过滤器就是搜索匹配选定条件的工单。要只归档前几个月关闭的工单，使用过滤器也许是一个好主意。
3. 工单操作
  在这部分设置标签为“归档选中的工单”字段为“archive tickets归档工单”。
4. 保存任务
  在页面的结尾可以找到保存任务的按钮。
5. 影响的工单
  系统在执行这个自动任务时会显示所有要归档的工单。
工单搜索
当你搜索工单时，系统默认搜索未归档的工单。如果你要同时搜索已归档的工单，仅需在定义搜索条件时添加‘归档搜索’即可。

缓存

OTRS在目录/opt/otrs/var/tmp下缓存了大量的临时数据。请确保它使用了高性能的文件系统或存储。如果你有足够的内存，还可以尝试把这个目录放入内存盘，如下面这样：

shell> /opt/otrs/bin/otrs.Console.pl Maint::Session::DeleteAll
shell> /opt/otrs/bin/otrs.Console.pl Maint::Cache::Delete
shell> sudo mount -o size=16G -t tmpfs none /opt/otrs/var/tmp

# 可在文件/etc/fstab中添加永久挂载点

注意

请注意：这个非永久存储会在服务器重启后丢失，所有的会话（如果你将它们存储在文件系统）和缓存数据都将丢失。

还有一种基于集中内存缓存的缓存后端可从OTRS集团购买。

第 7 章 性能优化