We’ve been using RT (3.4.1 with selected bugfixes/features up through
3.4.5, as well as bugfixes/features of our own) for about a year at the
company where I am employed. For the most part, people love the ability
to have an easy-to-view place to see tickets, to be able to track and
report on ticket creation, etc. The only problem that we keep running
into is speed. Part of the problem is that the company insisted on
Oracle for the backend. In my tests, MySQL is always faster. But as my
boss mentioned, sure, it could be up to twice as fast on MySQL, but
that’s still 5x slower than he really wants.
The problem is that everything is using POSTs, and every single page
load does an enormous amount of queries. I understand that the latest
version, 3.5.6, has some improvements, but it is still using the same
underlying ideas. The improvements seem to only be incremental. What
would it take to get more of the heavy-lifting done on the client side,
a la AJAX or php objects? What would it take to have the application do
things in a more modern, responsive way, rather than the very old
CGI-style POSTs?
We’ve been using RT (3.4.1 with selected bugfixes/features up through
3.4.5, as well as bugfixes/features of our own) for about a year at the
company where I am employed. For the most part, people love the ability
to have an easy-to-view place to see tickets, to be able to track and
report on ticket creation, etc. The only problem that we keep running
into is speed. Part of the problem is that the company insisted on
Oracle for the backend. In my tests, MySQL is always faster. But as my
boss mentioned, sure, it could be up to twice as fast on MySQL, but
that’s still 5x slower than he really wants.
Eric,
It would be interesting to hear a bit more about how slow you’re finding
RT, what benchmarking you’ve done, what performance tuning you’ve done
and what your hardware configuration and ticket load look like. RT
3.4.5 can be blazing fast, but if you misconfigure it, it’s certainly
going to feel slow.
We’ve been using RT (3.4.1 with selected bugfixes/features up through
3.4.5, as well as bugfixes/features of our own) for about a year at the
company where I am employed. For the most part, people love the ability
to have an easy-to-view place to see tickets, to be able to track and
report on ticket creation, etc. The only problem that we keep running
into is speed. Part of the problem is that the company insisted on
Oracle for the backend. In my tests, MySQL is always faster. But as my
boss mentioned, sure, it could be up to twice as fast on MySQL, but
that’s still 5x slower than he really wants.
Care to explain some of your problems with Oracle?
I’m running RT-3.4.3 on Oracle9i, albeit with some customizations in RT
and SearchBuilder and the Oracle schema.
Maybe I’m, or some one else, might be able to help you get some more
speed out of it, although it also depends on your hardware, would help
to know what it is, what else your Oracle server is doing etc.
I have logs for dbiprof and most queries run subsub-second. Here is the
first part of a recent log:
Program : /dev/null
Path : [ DBIprofile_Statement ]
Total Records : 25695 (showing 9999, sorted by longest)
Total Count : 1868495
Total Runtime : 4816.483249 seconds
#####[ 1 ]###########################################################
Count : 15
Total Time : 896.040070 seconds
Longest Time : 896.019474 seconds
Shortest Time : 0.000007 seconds
Average Time : 59.736005 seconds
Key 1 :
// query on attachment.content
#####[ 2 ]###########################################################
Count : 5
Total Time : 81.566872 seconds
Longest Time : 81.559566 seconds
Shortest Time : 0.000007 seconds
Average Time : 16.313374 seconds
Key 1 :
// another query on attachment.content
#####[ 10 ]###########################################################
Count : 770
Total Time : 30.053591 seconds
Longest Time : 3.677449 seconds
Shortest Time : 0.000005 seconds
Average Time : 0.039031 seconds
Key 1 :
// times get really short after this.