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 …