[rt-users] Handling millions of tickets with RT?

[Farzad FARID]

Hi,

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.

or

    * 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.

 Regards

-- 
Farzad FARID <ffarid at pragmatic-source.com>
Architecte Open Source / Pragmatic Source
http://www.pragmatic-source.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20060609/a49b4857/attachment.htm>