Request for feedback on a patch for RT 3.6.4

Hi, brave users of RT 3.6.4.

In the mentioned version of RT I changed SQL queries we generate to
searches tickets by watchers(requestors, cc or admicc). Logic of those
queries is better now. However, I’ve broken performance of queries
like “Requestor = ‘X’ OR Owner = ‘Y’”, "Requestor = X OR Status = ‘Y’"
and most probably other where condition on watcher is joined with
another condition using OR aggregator.

We have two ways to fix the problem. I sent one patch already to the
list, but we really need more feedback (positive or negative) to make
right choice, so I post it again.

Please do the following steps to collect feedback I need.

  1. build a query (see above) in the query builder using sane values
    for your setup
  2. execute search and wait for results, we expect it to be very slow,
    so you shouldn’t wait to much
  3. apply the patch
    cd /opt/rt3;
    cat /path/to/the/patch | patch -p0
  4. stop and start web server
  5. try search again

Send feedback. People who know how to deal with slow-logs, explain are
more than welcome to send additional info, but even if you don’t know
how to deal with those it’s ok, just send description of the system
behavior and wallclock timings.

  1. revert patch
    cat /path/to/the/patch | patch -p0 -R
  2. stop and start web server

Best regards, Ruslan.

3.6-searches_by_watchers_performance_fix.patch (2.11 KB)

For me, this patch has worked perfectly. Right after my upgrade to 3.6.4,
I had posted to this list regarding search timeouts when using AdminCC or
CC searches, but got no response. Eventually, other folks started to have
the same problem and as it turns out, it’s only when using the ‘OR’
aggregator. It would have helped to have posted the actual search, I
agree. Anyway, here’s an example search that after four minutes timed out
before the patch was applied:

( Status = ‘new’ OR Status = ‘open’ ) AND ( Cc.Name = ‘user’ OR
AdminCc.Name = ‘user’ )

After applying the patch, the same search takes 1 second. This with a
database of around 14,000 tickets.

James Moseley

         "Ruslan Zakirov"                                              
         <ruz@bestpractica                                             
         l.com>                                                     To 
         Sent by:                  "RT users"                          
         rt-users-bounces@         <rt-users@lists.bestpractical.com>  
         lists.bestpractic                                          cc 
         al.com                                                        
                                                               Subject 
                                   [rt-users] request for feedback on  
         08/03/2007 11:25          a patch for RT 3.6.4                
         AM                                                            

Hi, brave users of RT 3.6.4.

In the mentioned version of RT I changed SQL queries we generate to
searches tickets by watchers(requestors, cc or admicc). Logic of those
queries is better now. However, I’ve broken performance of queries
like “Requestor = ‘X’ OR Owner = ‘Y’”, “Requestor = X OR Status = ‘Y’”
and most probably other where condition on watcher is joined with
another condition using OR aggregator.

We have two ways to fix the problem. I sent one patch already to the
list, but we really need more feedback (positive or negative) to make
right choice, so I post it again.

Please do the following steps to collect feedback I need.

  1. build a query (see above) in the query builder using sane values
    for your setup
  2. execute search and wait for results, we expect it to be very slow,
    so you shouldn’t wait to much
  3. apply the patch
    cd /opt/rt3;
    cat /path/to/the/patch | patch -p0
  4. stop and start web server
  5. try search again

Send feedback. People who know how to deal with slow-logs, explain are
more than welcome to send additional info, but even if you don’t know
how to deal with those it’s ok, just send description of the system
behavior and wallclock timings.

  1. revert patch
    cat /path/to/the/patch | patch -p0 -R
  2. stop and start web server

Best regards, Ruslan.
(See attached file: 3.6-searches_by_watchers_performance_fix.patch)
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

3.6-searches_by_watchers_performance_fix.patch (2.11 KB)

Ruslan,

We just installed 3.6.4 in our test environment and have found a few 

problems with the Query:

1) Although "OwnerName" appears as a field to display, it is not 

included into the choices for a sort. “Custom.Owner” doesn’t work worth
a !@$*&^%.
2) The “highly-touted” sort by custom field feature doesn’t work, At ALL.
3) When deleting fields from the default display of choices, we must do
so one field at a time. Very time-consuming and ANNOYING! Why can’t we
just highlight the ones we want to delete (like the ones we choose to
add from the left side) and do it in one swell foop (he he).On Reminders; we think it would be REALLY convenient for Reminders to automatically resolve if the ticket they are linked to gets resolved. Actually, we can’t think of a reason to NOT have done this in the origin design. So, other than having to re-login the first time we try to do something after the initial sign on, AND the above-mentioned problems with query, we like it just fine (come on in! The water is just “ffffiiiiiinnnnneee” an old Cosby joke). Are there any fixes (for any of the above) about ready to implement? Kenn LBNL Ruslan Zakirov wrote:

Hi, brave users of RT 3.6.4.

In the mentioned version of RT I changed SQL queries we generate to
searches tickets by watchers(requestors, cc or admicc). Logic of those
queries is better now. However, I’ve broken performance of queries
like “Requestor = ‘X’ OR Owner = ‘Y’”, “Requestor = X OR Status = ‘Y’”
and most probably other where condition on watcher is joined with
another condition using OR aggregator.

We have two ways to fix the problem. I sent one patch already to the
list, but we really need more feedback (positive or negative) to make
right choice, so I post it again.

Please do the following steps to collect feedback I need.

  1. build a query (see above) in the query builder using sane values
    for your setup
  2. execute search and wait for results, we expect it to be very slow,
    so you shouldn’t wait to much
  3. apply the patch
    cd /opt/rt3;
    cat /path/to/the/patch | patch -p0
  4. stop and start web server
  5. try search again

Send feedback. People who know how to deal with slow-logs, explain are
more than welcome to send additional info, but even if you don’t know
how to deal with those it’s ok, just send description of the system
behavior and wallclock timings.

  1. revert patch
    cat /path/to/the/patch | patch -p0 -R
  2. stop and start web server


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Rus;

Just applied the patch a query similar to the below:

  • before the patch I stopped it after 3 minutes no results,
  • after the patch it returned the correct results within seconds …

Regards;
Roy

James Moseley wrote:

Kenneth, don’t you know that sending unrelated things to a thread on
mailing lists is very bad habit. Sorry, but I ignore this mail as it
has nothing to do with the patch.On 8/3/07, Kenneth Crocker KFCrocker@lbl.gov wrote:

Ruslan,

    We just installed 3.6.4 in our test environment and have found a few

problems with the Query:

    1) Although "OwnerName" appears as a field to display, it is not

included into the choices for a sort. “Custom.Owner” doesn’t work worth
a !@$*&^%.
2) The “highly-touted” sort by custom field feature doesn’t work, At ALL.
3) When deleting fields from the default display of choices, we must do
so one field at a time. Very time-consuming and ANNOYING! Why can’t we
just highlight the ones we want to delete (like the ones we choose to
add from the left side) and do it in one swell foop (he he).

    On Reminders; we think it would be REALLY convenient for Reminders to automatically resolve if the ticket they are linked to gets resolved. Actually, we can't think of a reason to NOT have done this in the origin design. So, other than having to re-login the first time we try to do something after the initial sign on, AND the above-mentioned problems with query, we like it just fine (come on in! The water is just "ffffiiiiiinnnnneee" an old Cosby joke). Are there any fixes (for any of the above) about ready to implement? Kenn LBNL Ruslan Zakirov wrote:

Hi, brave users of RT 3.6.4.

In the mentioned version of RT I changed SQL queries we generate to
searches tickets by watchers(requestors, cc or admicc). Logic of those
queries is better now. However, I’ve broken performance of queries
like “Requestor = ‘X’ OR Owner = ‘Y’”, “Requestor = X OR Status = ‘Y’”
and most probably other where condition on watcher is joined with
another condition using OR aggregator.

We have two ways to fix the problem. I sent one patch already to the
list, but we really need more feedback (positive or negative) to make
right choice, so I post it again.

Please do the following steps to collect feedback I need.

  1. build a query (see above) in the query builder using sane values
    for your setup
  2. execute search and wait for results, we expect it to be very slow,
    so you shouldn’t wait to much
  3. apply the patch
    cd /opt/rt3;
    cat /path/to/the/patch | patch -p0
  4. stop and start web server
  5. try search again

Send feedback. People who know how to deal with slow-logs, explain are
more than welcome to send additional info, but even if you don’t know
how to deal with those it’s ok, just send description of the system
behavior and wallclock timings.

  1. revert patch
    cat /path/to/the/patch | patch -p0 -R
  2. stop and start web server


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.