I received a query from one of our users who
is seeing tickets backing up in their queue
because they are not able to handle the volume
at present and he is wondering if there is a
point where that volume will adversely impact
the perforance of RT. I’m thinking that
number must be very large, but I’m wondering
if anyone has any more concrete experience.
Thanks,
John
John Hascall, john@iastate.edu
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)
IT Services, The Iowa State University of Science and Technology
I received a query from one of our users who
is seeing tickets backing up in their queue
because they are not able to handle the volume
at present and he is wondering if there is a
point where that volume will adversely impact
the perforance of RT. I’m thinking that
number must be very large, but I’m wondering
if anyone has any more concrete experience.
The largest RT I know about does between 40,000 and 70,000 tickets per
day. They do shred historical tickets, lest they end up with tens of
millions of tickets per year in their production database.
At any change in database scale, you’ll be looking at doing some tuning
to keep your DB running fast and efficient.
-Jesse
signature.asc (197 Bytes)
Hi John,
sounds strange. about how many ticket inside this queue we talk? We have
some queues with more then 30.000 Tickets status new and the users are
easily able to handle this?
Another Question: How does the user settings looks like for searchresults?
Possibly set to unlimit per page? Then the page load can take a fucking long
time.
Torsten2010/4/7 John Hascall john@iastate.edu
I received a query from one of our users who
is seeing tickets backing up in their queue
because they are not able to handle the volume
at present and he is wondering if there is a
point where that volume will adversely impact
the perforance of RT. I’m thinking that
number must be very large, but I’m wondering
if anyone has any more concrete experience.
Thanks,
John
John Hascall, john@iastate.edu
Team Lead, NIADS (Network Infrastructure, Authentication & Directory
Services)
IT Services, The Iowa State University of Science and Technology
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
The largest RT I know about does between 40,000 and 70,000 tickets per
day. They do shred historical tickets, lest they end up with tens of
millions of tickets per year in their production database.
that’s really big!
I’m curious is it possible to know which version of RT, which kind of
httpd/db/cgi-perl handler, how many servers?
Hi Emmanuel,
i think jesse is talking about our installation 
To your Questions:
that’s really big!
Hmm, it’s growing each day
I’m curious is it possible to know which version of RT, which kind of
httpd/db/cgi-perl handler, how many servers?
It is still an very old Version 3.6.5 but in progress of migration to
3.8.7(8) within the next weeks.
We’re using Apache 2.x on RedHat Enterprise Linux with FastCGI and FCGID
(different Webserver with different Setups, too many problems with FastCGI
and some major Problems with FCGID)
Frontends Webservers are some huge Webservers with lots of ram loadbalanced,
will be replaced end of this month by several VM’s around the world (if
jesse can help us !) and a 64 Processor SUN with tons of RAM at the
backend.
Some words to the Backend. We use an addon from BPS to store attachments not
inside the DB anymore, we store everything inside a f***ing fast NetApp
connected by 4 x 1GB ETH to the Servers. DB is also stored inside the NetApp
on several hundred disks.
tob
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
MFG
Torsten Brumm
http://www.brumm.me
http://www.elektrofeld.de
Hi Emmanuel,
i think jesse is talking about our installation
thanks, that’s an interresting setup.