Handling millions of tickets with RT?


The customer I’m working for has deployed a customized RT version 3.0.10
to handle incoming and outgoing customers emails. With the actual
configuration and recent database optimisations (MySQL 4.0 on a 4 Gb RAM
server, 3 web frontends), the system can handle about 700.000 tickets /
2.100.000 transactions and 100 simultaneous users without slowing down
too much.

But whenever this limit is reached every 3 or 4 months, we have to
create another database instance and restart from scratch, which is a
painful process technically speaking, and it causes some problems on the
business side too (for example because the same tickets Id are being
reused, or because a conversation started in one instance cannot be
continued in the new, empty instance).

With recent RT version is it possible to:

* handle millions of tickets tickets in a single databases? That is:
  keeping many years of history online.


* Easily archive old tickets/transaction in another database, while
  keeping it online, and easily reachable by users?
      o This way the main database would remain small and
        responsive, while historical data would still be available
        at the cost of a longer access time.

And is there a migration path between RT 3.0.10 and the up to date
release 3.4.5?

And a last remark concerning the Wiki: yesterday I found lots of page
content destroyed and replaced by spam! I reverted the content to the
original one on 2 or 3 pages but I think it’d be best to
password-protect the whole wiki.


Farzad FARID ffarid@pragmatic-source.com
Architecte Open Source / Pragmatic Source