Recentemente, ouvi alguém sugerir que o rastreador de solicitações de RT pode ter problemas de escalabilidade devido a seu banco de dados não normalizado (alguém em uma reunião de Perl fui encaminhado de forma positiva como hipernalnormalizado, mas acho que ele pode ter entendeu mal o que é normalização). Por outro lado, sei que empreendimentos de grande porte, como o CPAN da Perl, usam RT. Será que este nível de escala requer medidas especiais a serem tomadas para lidar com o que acontece quando o banco de dados cresce muito? Quais foram suas experiências?
Quão ocupado você espera que um rastreador de bugs seja? Minha suspeita é que o conjunto de trabalho é relativamente pequeno e deve ser facilmente armazenado em cache pelo DB.
Os únicos relatos de problemas de escala de RT que eu posso encontrar são de 2003, e apenas na pesquisa. Os principais usuários do RT provavelmente serão o e-mail, que deve ser relativamente leve em comparação com consultas aleatórias de pesquisa do banco de dados.
Eu trabalhei em uma empresa que tinha centenas de milhares de ingressos na RT, e antes que um filtro de spam duro fosse colocado em ação, estava adicionando milhares de novos tickets por dia apenas devido ao spam.
Apesar de estar em uma caixa que pelos padrões de hoje é antiga (classe P4), nunca teve um problema de desempenho. Isso acontece principalmente com o uso de um Postgres adequadamente gerenciado como backend, o MySQL funciona bem, mas o RT é melhor otimizado para isso.
Você pode dizer à RT para limpar tickets antigos, mas isso está destruindo dados e um desperdício de tempo IMHO.
Tags mysql perl scaling request-tracker