request tracker “rządzi”

część z was zna może rt (request trackera). tym którzy nie znają wyjaśnię – jest to jeden z najlepszych (albo najlepszy) system do zarządzania zgłoszeniami/błędami. mamy instalację rt. instalacja jest sporawa: > 50000 ticketów, 160 kolejek, około 150-200 nowych ticketów dziennie. instalacja chodziła kiedyś na postgresie (wersja 7.2) ale działała wolno i przenieśliśmy na mysql'a (4.1). i zaczęła działać szybciej. ostatnio dowiedziałem się, że rt po przeniesieniu z postgresa 7.4 na 8.1 działa dużo szybciej, więc stwierdziliśmy, że zrobimy testy. postawiliśmy testowe rt, wgraliśmy mu produkcyjną bazę. po czym odpaliliśmy testy z użyciem fajnego narzędzia: tsunga. kolega który robił testy (hi, filip 🙂 zrobił scenariusz testowy:

  1. wejście na stronę logowania
  2. zalogowanie (i wyświetlenie strony głównej)
  3. wejście w losową kolejkę
  4. wyświetlenie losowego ticketu
  5. wylogownie

łącznie 5 ekranów. zrobił (filip) testy. mysql – 15 sekund. postgres 8.1. – 30 sekund. postgres, ale z dodatkowymi indeksami podpowiedzianymi przez jakiegoś znajomego – 17 sekund. no cóż. kiepsko. nic to. patrzymy co dalej. i tu pojawia się gwódź programu. kto z was zganie ile zapytań do bazy danych wykonało rt po przejściu 100 razy scenariusza testowego (czyli łącznie 500 stron wygenerowane). no? chętni? 1000? 2500? 5000? nie. prawdziwa ilość wykonanych zapytań to: 145937! czyli prawie 300 zapytań *na stronę*! nic dziwnego, że to wolno działa. filip ma napisać (może już napisał?) do best practical z prośbą o wyjaśnienia. ciekawe czy czegoś się dowiemy …

9 thoughts on “request tracker “rządzi””

  1. A ja glupi odpalilem RT3 na sqlite3 – instalacja miala byc “mala” natomiast bardzo szychko dojechalismy do 600 ticketow ( z duzymi zalacznikami) i zdechlo. Teraz przynajmniej wiem dlaczego zdecho 🙂

    Jezeli ktos tez zrobil taki blad to u mnie na blogu jest sposob na konwersje z sqlite3 do mysql.

  2. Nie znam RT, ale czy trac nie ma podobnej funkcjonalności? Może lepiej sprawdziłby się w roli request trackera? 🙂 Można pod niego podpiąć oczywiście PostgreSQL’a, ba nawet jest to zalecane rozwiązanie.

  3. trac jest zupelnie innej klasy systemem niz RT. Natomiast my uzywamy obu rownolegle – z tym ze RT jest blizej obslugi Klienta, zas trac dla developerow.

  4. A można wiedzieć która wersja RT i czy wyłączone jest WebFlushDbCacheEveryRequest ? U nas po migracji na 3.6.1 był spoory przyrost wydajności. Co prawda wielkość bazy jeszcze nie ta (

Comments are closed.