First let me say, I can’t program, nor do I fully understand the RT
architecture… That said, I was wondering if any of the following ideas
make sense:
Could the query builder page and pick lists, be preloaded via the mason
interpreter under modperl? (There seems to a mason option)
One could also try using mason caching for the the picklists, (Mason
does have a caching mechanism) We would just have to add cache control
code to the RT GUI areas that could modify the picklist entries…
Brian Gupta
Time Inc
Information Technology Dept
212-522-1401
Message: 2Date: Sat, 8 Jan 2005 16:52:11 -0500
From: Andrew Sullivan ajs@crankycanuck.ca
Subject: Re: [Rt-devel] 3.4.0rc1 slow
To: rt-devel@lists.bestpractical.com
Message-ID: 20050108215211.GA16581@phlogiston.dyndns.org
Content-Type: text/plain; charset=us-ascii
I’d love to see suggestions about how we can improve the search UI
without completely breaking it for users of downlevel browsers. (Which
Well, the problem here seems more to be the number of round trips.
One of my DB guys is looking at how the queries could be altered to
get more in one go, but he’s convinced that it needs a great deal of
work to solve.
right out.) Would people be satisfied if the pick lists for users and
groups were transformed into text entry widgets?
I think that’d just create a new problem, that you’d end up with
groups and users that are typos.
A
Andrew Sullivan | ajs@crankycanuck.ca
The plural of anecdote is not data.
–Roger Brinner
First let me say, I can’t program, nor do I fully understand the RT
architecture… That said, I was wondering if any of the following ideas
make sense:
Could the query builder page and pick lists, be preloaded via the mason
interpreter under modperl? (There seems to a mason option)
One could also try using mason caching for the the picklists, (Mason
does have a caching mechanism) We would just have to add cache control
code to the RT GUI areas that could modify the picklist entries…
Part of the problem is that those lists vary (or should be varying)
based on the queues you have selected and the permissions you have right
now. They’re supposed to be smart and dynamic and that hurts,
performancewise.
Does RT currently take advantage of Apache sessions via cookies? The
MASON caching directives can be done on a per session basis. (If you do
something like log out or change the configurations, the code would need
to be added to should clear the session cache(s))
Brian Gupta
Time Inc
Information Technology Dept
212-522-1401-----Original Message-----
From: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Sunday, January 09, 2005 4:15 PM
To: Gupta, Brian - Information Technology brian_gupta@timeinc.com
Cc: rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] RE: Rt-devel Digest, Vol 10, Issue 7
On Sun, Jan 09, 2005 at 03:28:20PM -0500, Brian_Gupta@timeinc.com wrote:
First let me say, I can’t program, nor do I fully understand the RT
architecture… That said, I was wondering if any of the following
ideas make sense:
Could the query builder page and pick lists, be preloaded via the
mason interpreter under modperl? (There seems to a mason option)
One could also try using mason caching for the the picklists, (Mason
does have a caching mechanism) We would just have to add cache control
code to the RT GUI areas that could modify the picklist entries…
Part of the problem is that those lists vary (or should be varying)
based on the queues you have selected and the permissions you have right
now. They’re supposed to be smart and dynamic and that hurts,
performancewise.
Brian_Gupta@timeinc.com wrote:
The MASON caching directives can be done on a per session basis.
That doesn’t help much; the list content changes not just on the current
user’s permissions, but also on the context of the list… when setting
an owner, the list only shows users that are permitted to own the
particular ticket being modified, for example.
The memory required to cache a list of potential owners for every ticket
viewed in a session makes such caching somewhat less than entirely
practical.
matthew@trebex.net
signature.asc (254 Bytes)