Kešatmiņas maģija

Kādēļ tomēr viss ir tik lēns? Skatāmies vēlreiz izejas kodu : notiek datu atlase pēc lietotāja parametriem, pieprasījums aiziet uz datubāzi, tiek izveidots dataset, dati tiek attēloti un formatēti, attēlojas lietotāja pārlūkā…

Papildinājām izejas kodu ar detalizētu trasēšanas informāciju par atsevišķu sekciju izpildes laiku. Secinājām, ka ievērojams laiks (daži simti ms) paiet nolasot un atgriežot datu kopu no datubāzes. Mūsu klients nevēlējās pārlieku ierobežot lietotājam atgriežamo datu apjomu, tādēļ izlēmām izstrādāt kešatmiņas mehānismus.

Šī bija pati sarežģītākā izstrāde visā optimizācijas procesā. Realizējām vairāku līmeņu kešatmiņu:

• Pilns datu komplekts ir relatīvi neliela apjoma - to visu glabājam statiskā kešatmiņā.

• LRU (Least Recently Used) kešatmiņā glabājam sagatavotus filtrētus un nefiltrētus datasetus.

Dataset LRU kešatmiņā arī ir iebūvēts līdzīgs invalidācijas mehāsims kā pilno datu komplektu kešatmiņā – kad notiek ieejas datu izmaiņas lietotājiem tiek atdoti vecāka datu versija no Dataset kešatmiņas kamēr tiek veidota jaunāka datu versija. Tas neļauj veidoties situācijai, kad daudzi lietotāji sēdēs un gaidīs rezultātus kamēr atjaunojas dati Dataset LRU kešatmiņā, jo ir ienākuši jaunāki pilno datu komplekti.

Testējam vēlreiz

Testējam, tagad ar 200 paralēlām plūsmām:

Rezultāti

• Caurlaides spēja visos testos nav mazāka par 3500 pieprasījumiem minūtē. Šis ir apmierinošs rezultāts, ņemot vērā prognozējamo maksimālo portāla noslodzi;

• Reakcijas laiks nevienā no testiem nepārsniedz 500ms. Pilnīgi pieņemams rezultāts no lietojamības viedokļa;

• Appdex score indikators visu laiku ir 0.8 (Fair) – 1.0 (Excellent);

• Pilnībā ir novērsta servera atmiņas noplūde, kas bija novērojama iepriekš. Maksimālais atmiņas patēriņš : 500Mb.

Tomēr arī šie rezultāti nav ideāli. Ja mūsu klienta portāls kļūtu par interneta uzlecošo zvaigzni, mums varētu būt nepatikšanas. Bet vismaz šajā mirklī varētu ar mierīgāku sirdsapziņu teikt : dubultojam procesora kodolu skaitu …