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