nBomber - testy wydajnościowe w .NET

Czasami biznes wymaga od nas przedstawienia raportu wydajności naszego API. Odpowiedni czas odpowiedzi lub ilość zapytań na sekundę może też być zdefiniowane jako element wymagań biznesowych wobec systemu który projektujemy lub którym zarządzamy. Możemy wtedy próbować pisać odpowiednie rozwiązania samemu, lub użyć gotowego rozwiązania. Takim gotowym rozwiązaniem napisanym w .NET i współpracującym z .NET-owymi bibliotekami testującymi (np. xUnitem) jest biblioteka nBomber. 

Linki:

https://nbomber.com/ - strona projektu

https://github.com/PragmaticFlow/NBomber - kod źródłowy na GitHub

AutoMapper

    Jednym z ćwiczeń praktycznych podczas "Zaawansowanego szkolenia z .NET 4.0" organizowanego przez Comarch (opis szkolenia tutaj), było napisanie własnego "AutoMappera" na kilka możliwych sposobów (refleksja, dynamic).
    A czym właściwie jest "AutoMapper"? AutoMapper to biblioteka, która udostępnia funkcjonalność automatycznego przepisywania wartości pól jednej klasy do drugiej. Potrzeba posiadania takiej funkcjonalności często zachodzi w sytuacji wykorzystywania w projekcie ORM. Zamiast pisać kod, służący do mapowania pól/właściwości z jednej klasy do drugiej, lepiej jest wykorzystać gotowe, darmowe rozwiązanie jakim jest AutoMapper, szczególnie, że jego wykorzystanie jest banalnie proste:

Najpierw, przed pierwszym użyciem tworzymy konfigurację mapowania (w jednym miejscu dla całego AppDomain). Najczęściej będzie to 'global.asax' lub 'bootstraper', ale może być też bezpośrednio przed metodą:

public static IMappingExpression<TSource, TDestination> CreateMap<TSource, TDestination>();
np.: Mapper.CreateMap<ClassA, ClassB>();

a nast. w kodzie produkcyjnym do mapowania wykorzystujemy metodę Map:

public static TDestination Map<TDestination>(object source);
np: ClassA classAB = Mapper.Map<ClassA>(classAA);  

//classAA will be copied to classAB and both will have values of classAA

Testowanie:
Najpierw musimy zainicjować konfigurację mapowania (np. poprzez wywołanie Bootstrapera), a nast. wywołać metodę:

Mapper.AssertConfigurationIsValid();

Linki:
Kod źródłowy znajduje się na github, a udost. jest na licencji MIT.
AutoMapper Getting-started
Artykuł na Visual Studio Magizne opisujący bardziej zaawansowane przypadki użycia: link

Chrome DevTools

Jak powszechnie wiadomo, każda praca wymaga specyficznych dla tej pracy narzędzi. W przypadku hydraulika jest to klucz francuski, w przypadku nauczyciela jest to tablica, a przypadku web developera są to tzn. 'DevTools'. Osobiście, do tej pory, jako 'DevTools' używałem narzędzi dostępnych w Internet Explorer (od wersji 8.0). Owszem, byłem świadomy "firebuga" występującego w 'mozilla firefox', jednak siła przyzwyczajenia była zbyt silna, aby się przemóc.'Narzędzia developerskie IE' pokazał jeden z kolegów z pierwszej pracy i... tak jakoś zostało. Do dzisiaj.

Pod wpływem kilku ost. wykładów Gutka (więcej info w moim poprzednim wpisie), postanowiłem poszerzyć moją wiedzę o to, co zaserwował nam Gutek podczas swoich wykładów.

Jednym z miłych zaskoczeń są narzędzia developerskie dostarczone nam przez firmę Google dla ich przeglądarki Chrome o nazwie "Chrome DevTools".

To co jest naprawdę fajne, to fakt, iż google, oprócz dostarczenia nam porządnych narzędzi udostępnia również mini-tutorial, w którym oprócz "wykładów" (filmiki) mamy też do wykonania część praktyczną (ponieważ jak to mówi miły pan na filmiku "nic nie zastąpi praktyki" ;)).

To co mnie najbardziej urzekło w "Chrome DevTools", to możliwość sprawdzania wydajności stron i sposób konkretnego wyszukiwania "wąskiego gardła" (tzw. "bootle neck"), z dokładnością do linii kodu, zarówno przy ładowaniu strony do przeglądarki, jak i późniejsza obsługa tego kodu w przeglądarce.

Link do samouczka z Chrome DevTools


p.s. W kursie jest również odnośnik do innej strony hostowanej przez google (closure-compiler), służącej do minimalizowania objętości plików js (w celu zwiększenia wydajności stron, które tworzymy).

SPMonitoredScope, czyli sprawdzanie wydajności w aplikacjach sharepoint

Tematem aktualnego wpisu jest sposób, na sprawdzenie wydajności naszej aplikacji sharepoint, a dokładniej czasu jaki jest potrzebny, aby wyświetlić naszą aplikację w przeglądarce internetowej. Ponieważ temat wydajności w sharpoint jest bardzo obszerny, a z problemem zwiększania wydajności aplikacji sharepoint spotkał się niemal każdy doświadczony programista, dobrze jest mieć jakieś narzędzie, które zautomatyzuje proces sprawdzania wyników. Narzędzie, dzięki któremu będziemy wiedzieli, jaki dokładnie wpływ na wydajność mają zmiany w kodzie,  które wprowadzamy podczas procesu optymalizacji.

Tutaj z pomocą przychodzi nam SPMonitoredScope, które jest darmowym narzędziem służącym do lokalizacji wydajnościowego "wąskiego gardła". Jedynym ograniczeniem, jakie posiada SPMonitoredScope są rozwiązania typu "sandbox" ("piaskownica"), w których SPMonitoredScope nie działa.

Sposób wykorzystania SPMonitoredScope jest bardzo prosty:
Najpierw odpalamy konsolę (Start -> wyszukaj programy -> cmd.exe). W konsoli natomiast uruchamiamy program stsadm (ja uruchamiałem go z roota, do którego przechodzimy za pomocą komendy "cd..").  Dostępne komendy, możemy znaleźć na MSDN pod tym linkiem.  Osobiście preferuję opcję "on demand", czyli:

stsadm -o setproperty -pn developer-dashboard -pv ondemand 

Wyłączenie SPMonitoredScope następuje poprzez wpisanie w konsoli:

stsadm -o setproperty -pn developer-dashboard -pv off

Sprawdzanie konkretnych, wybranych partii kodu, pod kątem wydajności następuje, poprzez wykonanie naszego kodu wewnątrz "using-a".

using (new SPMonitoredScope("CallMethod1 Monitored Scope"))
{
    //TODO: tutaj będzie kod, który chcemy przetestować.
}

 
Wyniki sprawdzamy w przeglądarce, w nowej zakładce, która się pojawi, gdy tylko będziemy mieli aktywny SPMonitoredScope. Co do samych wyników, to dobrze jest stronę załadować przynajmniej kilka razy i nast. wyciągnąć średnią.

P.S. Link do bloga Tobiasa Zimmergrena, którego wpis stał stał się inspiracją dla mojego wpisu.