Table of Contents
Abstract
Inayoonyeshwa chini ni orodha ya mbinu za kuboresha utendaji wa usakinishaji wako wa OTRS, ikijumuisha usanidi, uandikaji kanuni, matumizi ya kumbukumbu, na mengine.
Kuna njia tofauti za kuboresha utendaji wa OTRS.
There are two backend modules for the index for the ticket queue view:
Kernel::System::Ticket::IndexAccelerator::RuntimeDB
This is the default option, and will generate each queue view on the fly from the ticket table. You will not have performance trouble until you have about 60,000 open tickets in your system.
Kernel::System::Ticket::IndexAccelerator::StaticDB
The most powerful module, should be used when you have above 80,000 open
tickets. It uses an extra ticket_index
table, which will
be populated with keywords based on ticket data. Use
bin/otrs.RebuildTicketIndex.pl
for generating an
initial index after switching backends.
You can change the used IndexAccelerator module via SysConfig.
This module helps to extend your articles full-text search (From, To, Cc, Subject and Body search). There are two backend modules for the search index:
Kernel::System::Ticket::ArticleSearchIndex::RuntimeDB
This is the default option, and will will do full-text searches on live data (it works fine for up to 50,000 tickets).
Kernel::System::Ticket::ArticleSearchIndex::StaticDB
This module will strip all articles and build an index after article creation, increasing performance of full-text searches up to 50%.
You can change the used SearchIndexModule via SysConfig.
To create an initial index, use
bin/otrs.RebuildFulltextIndex.pl
.
For StaticDB module, there are some options available for fine tuning:
Ticket::SearchIndex::Attribute
The attribute "WordCountMax" defines the maximum of words which will be processed to build up the index. For example only the first 1000 words of an article body are stored in the article search index. The attributes "WordLengthMin" and "WordLengthMax" are used as word length boundaries. Only words with a length between these two values are stored in the article search index.
Ticket::SearchIndex::Filters
There are three default filters defined:
The first filter strips out special chars like: , & < > ?
" ! * | ; [ ] ( ) + $ ^=
The second filter strips out words which begin or ends with one of following
chars: ' : .
The third filter strips out words which do not contain a word-character:
a-z, A-Z, 0-9, _
Ticket::SearchIndex::StopWords
There are so-called stop-words defined for some languages. These stop-words will be skipped while creating the search index.
Kuna moduli mbili tofauti za mazingira ya nyuma ya uhifadhi wa tiketi/makala:
Kernel::System::Ticket::ArticleStorageDB
This default module will store attachments in the database.
Don't use it with large setups.
Pro: If your web server isn't running under 'otrs' user, use this module to avoid file permission problems.
Con: It is not advisable to store attachments in your database. Take care
that your database is able to store large objects. I.e.: configure MySQL
with set-variable = max_allowed_packet=8M
to store 8 MB
objects (the default is 2M).
Kernel::System::Ticket::ArticleStorageFS
Use this module to store attachments on the local file system.
Recommended for large setups.
Faida: Ni ya kasi!
Con: Your web server should run under the 'otrs' user. Also, if you have multiple front-end servers, you must make sure the filesystem is shared between the servers. Place it on an NFS share or preferably a SAN or similar solution.
You can switch from one back-end to the other on the fly. You can switch the
backend in the SysConfig, and then run the command line utility
otrs.ArticleStorageSwitch.pl
to put the articles from
the database onto the filesystem or the other way around. You can use the
-s and -d options to specify the
source and destination back-ends. Please note that the entire process can
take considerable time to run, depending on the number of articles you have
and the available CPU power and/or network capacity.
shell> bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS
Hati: Kubadilisha mazingira ya nyuma ya hifadhi kutoka hifadhidata kuwa mfumo wa mafaili
Kwa kuwa OTRS inaweza kutumika kama mfumo wa kuzuia ukaguzi, kufuta tiketi zilizofungwa inaweza kuwa sio wazo zuri. Kwa hiyo tumetengeneza kipengele kinachokuruhusu kuhifadhi tiketi kwenye nyaraka.
Tickets that match certain criteria can be marked as "archived". These tickets are not accessed if you do a regular ticket search or run a Generic Agent job. The system itself does not have to deal with a huge amount of tickets any longer as only the "latest" tickets are taken into consideration when using OTRS. This can result in a huge performance gain on large systems.
Kutumia kipengele cha nyaraka fuata hatua zifuatazo kirahisi:
Amilisha mfumo wa nyaraka katika SysConfig
Katika kurasa ya msimamizi, nenda kwenye AysConfig na chagua
Tiketi
ya kundi hilo. Katika
Kiini::Tiketi
unakuta chaguo
Tiketi::MfumoNyaraka
ambao umesetiwa kuwa "hapana" kwa
chaguo-msingi. Badilisha mpangilio huu kuwa "ndiyo" na hifadhi mabadiliko.
Fafanua kazi ya WakalaWaJumla
Kwenye kurasa ya Msimamizi, chagua WakalaUjumla na ongeza kazi mpya hapo.
Mpangilio wa kazi
Toa jina kwa
Chujio la Tiketi
Vichujio vya tiketi vinatafuta tiketi ambazo zinafanana na kigezo kilichochaguliwa. Inaweza kuwa wazo zuri kuweka kwenye nyaraka zile tiketi zilizo kwenye hali iliyofungwa na zimefungwa miezi michache nyuma.
Kitendo cha Tiketi
Katika kifungu hiki, seti sehemu yenye lebo"Hifadhi kwenye Nyaraka tiketi zilizochaguliwa" kuwa "hifadhi tiketi kwenye nyaraka".
Hifadhi kazi
Mwisho wa kurasa utapata chaguo la kuhifadhi kazi.
Tiketi zilizoathirika.
Mfumo utaonyesha tiketi zote zitakazohifadhiwa kwenye nyaraka wakati wa kutekeleza kazi ya Wakala wa Ujumla.
Tafuta Tiketi
Ukitafuta tiketi, mfumo kwa kawaida unatafuta tiketi zisizo kwenye nyaraka. Kama ukitaka kutafuta tiketi za kwenye nyaraka pia, ongeza kirahisi "tafuta nyaraka" wakati wa kufafanua vigezo vya kutafuta.
OTRS caches a lot of temporary data in
/opt/otrs/var/tmp
. Please make sure that this uses a
high performance file system/storage. If you have enough RAM, you can also
try to put this directory on a ramdisk like this:
shell> /opt/otrs/bin/otrs.CleanUp.pl shell> /opt/otrs/bin/otrs.DeleteCache.pl shell> sudo mount -o size=16G -t tmpfs none /opt/otrs/var/tmp # add persistent mount point in /etc/fstab
Please note that this will be a non-permanent storage that will be lost on server reboot. All your sessions (if you store them in the filesystem) and your cache data will be lost.
There is also a centralized memcached based cache backend available for purchase from OTRS Group.