[rt-users] number of queues

[Kenneth Crocker]

Matt,


	The performance in RT seems to drop off when the are a lot of users 
with a lot of permissions to the tickets in a queue. We have over 75 
queues and restrict the ability to update tickets to a select few 
(specific groups for specific queues) and we have pretty good performance.
	We have a lot of software support so we prefix the name of the queue 
with the organization the software is supporting. For example, all of 
out financial software is broken down into individual queues for each 
package (like GL, AP, AR) but with the prf-fix for the organization. 
i.e. FS-GL, FS-AP, FS-AR where "FS" is for "Financial Services". It 
makes it easier to find them on a page or menu. We also limit how many 
queues a person sees by limiting such rights as "SeeQueue", 
"ShowTicket", "CreateTicket", ModifyTicket", "OwnTicket", etc. to the 
specific groups for those queues. It cuts down on them having to page 
thru 75 different queues AND it speeds up page loading and searches.
	We also have a general "Bucket" or "Request" queue to act as a review 
and approval queue for about 20 queues that are related. This keeps 
requestors from dumping a bunch of tickets into a queue when the support 
team isn't ready to work on them AND, more importantly, it allows those 
group members that review the requests in the "bucket" queue to evaluate 
and set the priorities. After prioritization, they are either rejected 
or approved for work, at wich time they are moved to the appropriate 
"support" queue. This keeps things moving along evenly and without alot 
of melodrama and trauma.
	We highly recommend RT, but if your session is going to be a busy one 
with more than 10 queues, we suggest that you create "User" groups for 
those that only need to send/create requests (in other words, these 
users are not to be working on the tickets, just getting results) and 
"Support" groups for those users that will be working on those requests. 
We further recommend you name the groups such that they can be 
identified by the queue they create/own/resolve tickets in and the type 
of function the perform. This will nip a lot of confusion in the bud.
	Also, spend ALOT of time learning about the granting of privileges and 
how they relate/cascade for both tickets AND Custom Fields. Hope this helps.


Kenn
LBNL

On 4/23/2008 2:26 PM, Matt Zagrabelny wrote:
> Greetings,
> 
> I am in the early throws of setting up and configuring RT for our
> university. I have a question about the granularity with which to create
> queues.
> 
> First off, is there a performance or otherwise soft or hard limit on the
> number of queues that are created? Or is the "only" downside of creating
> many queues the fact that you now need to sift through the multitude of
> queues to find the one you are interested in?
> 
> Secondly, is there namespaces for queues? That is, some way of
> organizing queues into logical groups?
> 
> Lastly, I am wondering if anyone can confirm the track that I am going
> down or otherwise point me in another direction.
> 
> I am thinking that we will have somewhere between 4 and 10 "top level"
> queues at our university.
> 
> Some off the top of my head are:
> 
>   - help desk
>   - phone network requests
>   - maintenance requests
>   - projects
> 
> Underneath those headings there could be queues such as the following:
> 
> + help desk
>   |
>   + systems team
>   + desktop team
>   + maintenance team
>   + phone net team
>   +
>   .
>   .
>   .
>   + team number 50
> 
> + phone net requests
> 
> + maintenance requests
> 
> + projects
>   |
>   + systems project 1
>   +
>   .
>   .
>   .
>   + systems project N
>   + classroom project 1
>   +
>   .
>   .
>   .
>   + classroom project N
>   + other project
>   + etc.
> 
> I am looking at creating too many queues? What have others done that are
> trying to use RT as the single ticketing system for many different
> facets of a large organization?
> 
> Thanks,
> 
> -Matt Zagrabelny
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
>