Lēnā pdf ģenerēšana

Kāpēc tik katastrofāli lēni notiek pdf failu ģenerēšana. Skatāmies kodā. Tiek izmantota PdfSharp bibliotēka.

Īsumā - pdf ģenerēšana notiek 2 soļos:

• Ielādējot fona attēlu ar XGraphics
• Rakstot pa virsu tekstu

Tieši pirmā daļa – attēla ielāde radīja pāris sekunžu aizturi. Par laimi, fona attēls visiem uzražotajiem failiem ir vienāds, atšķiras tikai teksti, līdz ar to optimizācija ir acīmredzama. Ievietojam pdf sagatavi ar jau ielādētu attēlu kešatmiņā!

Tāpat aizliedzam milzīgos atgriežamos datu apjomus, ieviešot stingrākus filtrēšanas kritērijus. Mēs nedrīkstam atgriezt desmitiem tūkstošu ierakstu uz katru pieprasījumu.

Laiks atkārtotiem testiem

Palielinām slodzi līdz 100 paralēliem pieprasījumiem un uzpildām iepriekš sagatavotos ApacheBench testus

Redzam, ka atmiņas “plato” pie 2Gb pa lielam ir pazudis un arī caurlaides spēja jau mērāma tūkstošos pieprasījumu minūtē.

Arī pdf ģenerācijas laiki uzlabojušies līdz 700ms un kļūdas ir pazudušas.

Ir labāk, bet nav īsti labi

Tomēr 700ms atbildes laiks uz pieprasījumu – tas nav apmierinoši. Tāpat ir redzams, ka dažiem testiem pie šādas slodzes atbildes laiki pieaug līdz 5-7s. Par to signalizē arī NewRelics rīka rādītājs “Appdex score”, kas skalā 0 (katastrofāli) - 1 (ideāli) ilustrē mūsu portāla responsivitāti.

Vēl vairāk palielinot slodzi, līdz 200-300 paralēliem pieprasījumiem, paliek vēl sliktāk. Vēl jo vairāk – izvērtējam mūsu slogošanas metodoloģiju. Nav īsti korekti visu laiku “raustīt” vienu un to pašu saiti, dot vienu un to pašu POST pieprasījumu. Ir jāvariē ieejas parametru kopa plašā diapazonā. Izveidojam plašu testu piemēru kopu ar nejaušiem parametriem un sākam izmantot Siege rīku slodzes testiem. Palika vēl sliktāk.

Sākam nākamo analīzes un uzlabojumu iterāciju…