[Erp5-poland] testowanie wydajności, szukanie wąskich gardeł - UI i odczucia userów

[Łukasz Nowak]

Witam,

On 2007-11-26, 10:30:30
bartek <bartek w erp5.pl> wrote:

(...)
> Nie wiem czy to jest akurat zope-2 (tj nie wiem czy zope-1 i
zope-3
> są jakoś znacząco szybsze), ale generalnie rzeczywiście rakieta to
> nie jest.

Tego się spodziewałem.

> > Mamy coraz więcej różnorodnie powiązanych ze sobą danych w
> > systemie. Od pewnego czasu zaczynają być problemy z wydajnością.
> > Np. wyświetlanie accounting_module listboxa trwa...8 sekund.
> > Niektóre raporty generują się po 20 sekund, a sposób ich używania
> > czy potrzeby firmy zakładają, że powinny być dostępne w 1-2 sekundy.
> > 
> 
> Można by spróbować przechowywać wartości które są często wyliczane.
> Np wyliczenie stanu magazynowego dla produktu to jest sporo pracy dla 
> systemu, a prawdopodobnie robisz to bez przerwy do prawie każdego 
> raportu. Można by więc wyliczać stan przy pomocy interaction workflow
> i przechować go gdzieś - GuidelinesForCodingCrimes podają dwa
> rozwiązania, poza tym być może można by wykorzystać cache (jeżeli
> tylko da się odświeżyć cache dla konkretnej wartości a nie od razu
> cały, trzeba by zajrzeć do API).

Cache oszukuje. Mam z nim więcej problemów niż pożytku - vide
CurrencyExchange_getExchangeRateList. Można paczować, rozwiązywać na
tysiące sposobów, a użytkownik i tak zdoła doprowadzić do sytuacji,
kiedy cache jest przestarzały. Poza tym zauważyłem, że cache używają
często dla "przykrycia" problemu wydajności konkretnego zagadnienia -
jak predykatów w CurrencyExchange_getExchangeRateList.

Co do wpisywania wyliczonych wartości w interaction workflow - gdzie
się da staram się tego używać. Ale ma to kilka problemów. Obiekty są
"dotykane" edycją wielokrotnie, co wywołuje wiele innych interakcji.
Poza tym niektóre rzeczy ciężko łapie się z interakcji - np. fakt
usunięcia podobiektów. Co gorsza, nie są opisane metody, które można
wyłapywać - lista powstaje[1].

Niestety nie wszystko da się wyliczyć offline - niekiedy fakt
konieczności przeliczenia jest niedeterministyczny (trudniejsze
słowo niż "synergia" - dobrze użyłem? ;) ). Wtedy klops - mamy
niepoprawne informacje z których korzysta system.

Problem często dotyka skomplikowanych listoboxów. Polecam na site, z
dużą ilością transkacji księgowych przeprowadzenie eksperymentu.
Zmierzyć czas renderowania listboxa z samym title oraz z
title + delivery_mirror_section_title. Czas skacze o 200-300% - a to
tylko jedna kolumna. (Może nie dotyczyć aktualnych rewizji, to się
dzieje na 15401 - ale takich problemów jest więcej).

Mam nadzieję, że korzystanie z wartości skatalogowanych przyspieszy
listboxy - właśnie wkładamy do katalogu co się da. Jakaś poprawa jest,
ale o 10-20%, a użytkownicy spodziewają się o 50-80%. Jak uda mi się
odseparować obciążające system problemy postaram się raportować.

Łukasz

[1]http://www.erp5.org/HowToUseAndDefineInteractionWorkflows#head-ae5934e3acf92291315f1284d6149c3593a7fe9a

-- 
Łukasz Nowak R&D Ventis http://www.ventis.com.pl/
tel: +48 32 768 16 85 fax: +48 32 392 10 61
``Use the Source, Luke...'' I am only craftsman.