RT 6.0.3 Performance Tuning

RT Developers
1

Hi everyone!

I’m currently running some performance testing on a new RT 6.0.3 and noticing some uneven resource utilization. Specifically, the application server CPU spikes to 90%, while the database server barely registers the load.

Here is my current environment:

  • RT Version: 6.0.3

  • App Server: 4 CPUs, 20 GB RAM (Ubuntu 24.04)

  • DB Server: 16 CPUs, 32 GB RAM (PostgreSQL 17.10)

During load testing, the app server quickly maxes out its 4 CPUs, but DB utilization remains low.

I have two questions:

  1. Are there any known performance issues to RT 6.0.3?

  2. Does anyone have tips, tricks, or recommended configurations to better balance this load or optimize the application server for high traffic?

Any insights or guidance on tuning RT would be greatly appreciated! :smiling_face:

2

We’re testing RT6 right now and users have noticed that pages are slower to render than they were in RT5. I haven’t started looking into that and am hopeful your thread gets some attention. I will report back on anything I find.

4

I was having some issues until I ran the update database on my copy of the rt db which I’d made for the test instance, something like:

cd /opt/rtX
 ./sbin/rt-setup-database --action upgrade --upgrade-from <old_version> --upgrade-to <new_version> --prompt-for-dba-password

I had to also do this as the database is postgres:

root@support:~# cd /opt/rt6
root@support:/opt/rt6# ./etc/upgrade/reset-sequences
In order to create or update your RT database, this script needs to connect to your  Pg instance on x.x.x.x (port '5432') as support_dev
Please specify that user's database password below. If the user has no database
password, just press return.

Password:

[...]

Sequence updates complete.

I have a few External CustomFieldValues set up which load things from external JSON sources. RT seems quite inefficient though because it seems to load them all every time, whether or not the user actually updates the custom field. This can make pages load slowly because it’s doing a lot of useless work loading custom fields from JSON sources which are never used. It should really only load them if the user actually clicks to edit them.

5

How big is the database and how many concurrent users are you testing with?

We have c. 120k tickets and 18GiB of attachments in PostgreSQL and whilst our upgrade to 6.0.3 was a bit slow, it did seem to sort itself out after a while and is now reasonably snappy with the occasional slow down. We have 5-10 agents using it constantly during the day.