RT5.0.0 Performance issues with custom field

I looked around in the source code a little. Found nothing that really solves the problem, but I’ve noticed an error in the log after restarting apache:

[20305] [Fri Sep 25 16:00:20 2020] [warning]: DBD::Pg::st execute failed: ERROR: relation “configurations” does not exist
LINE 1: SELECT main.* FROM Configurations main WHERE (main.Disabled…
^ at /usr/local/share/perl5/DBIx/SearchBuilder/Handle.pm line 603. (/usr/local/share/perl5/DBIx/SearchBuilder/Handle.pm:603)
[20305] [Fri Sep 25 16:00:20 2020] [warning]: RT::Handle=HASH(0x36825b8) couldn’t execute the query 'SELECT main.* FROM Configurations main WHERE (main.Disabled = ‘0’) ORDER BY main.id ASC ’ at /usr/local/share/perl5/DBIx/SearchBuilder/Handle.pm line 616.
DBIx::SearchBuilder::Handle::SimpleQuery(‘RT::Handle=HASH(0x36825b8)’, ‘SELECT main.* FROM Configurations main WHERE (main.Disabled …’) called at /usr/local/share/perl5/DBIx/SearchBuilder.pm line 241
DBIx::SearchBuilder::_DoSearch(‘RT::Configurations=HASH(0x7ae5da8)’) called at /opt/rt5/sbin/…/lib/RT/SearchBuilder.pm line 1009
RT::SearchBuilder::_DoSearch(‘RT::Configurations=HASH(0x7ae5da8)’) called at /usr/local/share/perl5/DBIx/SearchBuilder.pm line 513
DBIx::SearchBuilder::Next(‘RT::Configurations=HASH(0x7ae5da8)’) called at /opt/rt5/sbin/…/lib/RT/Config.pm line 2650
RT::Config::LoadConfigFromDatabase(‘RT::Config=HASH(0x24dca68)’) called at /opt/rt5/sbin/…/lib/RT.pm line 202
RT::Init(‘RT’, ‘Heavy’, 1) called at /opt/rt5/sbin/rt-server.fcgi line 126 (/usr/share/perl5/vendor_perl/Carp.pm:103)

any chance this is related to the performance problem?

That points to some upgrade steps not being run, did you run the database upgrade commands without error? Seems like you’re missing the Configurations table which is new in RT5

I’ve just did the process for the database again. I don’t know what was going wrong tast time, but the “Configurations” table is present and the error messages in the log gone.
Sadly, the error seems to be unrelated to the problem… -.-

Hey,

I did some more tests and found something interesting: If I drop all entries for the customfield, it works like a charm.
So it seems like while loading the tickets, the RT does some kind of comparison between the customer information saved in the ticket (the values for existing tickets was still there, I just wasn’t able to change it anymore) and the database entries for the customfield.

If it helps to track down the error, the current value for the custom field is “###### - [customer name]” e.g. “123456 - ACME”.
The names are german, so there can be umlauts(ä, ö, ü) within them.

/edit: did some measurements today, all for the same ticket overview displaying 50 tickets.
1 entry: 1,5 sec
100 entries: 1,8 sec
500 entries: 3.1 sec
1000 entries: 5.6 sec
all 3200 entries: 13.8 sec

For me this looks like the rt is checking every entry in the ticket against all entries in the customfield, but without going really deep in the code, this is just a assumption.
A possible work around would be checking if we can reduce the amount of customer entries that gets listed in the RT, but I don’t think my boss will be happy with this idea.

Hey,

I wrote a Mail to the support. It seems like the RT was fetching all values for the custom fields for the selection field even if the inline editing option was disabled.

I’ve got a small patch, now the performance is fine.
https://github.com/bestpractical/rt/commit/4d20cec54b6349b202816d6c4c41d84415d37142.patch

Thanks for the help knation.

1 Like