Tag: wydajność

Często menedżerowie podejmują decyzję o inwestowaniu w niezależnie opracowane aplikacje na iOS i Androida. Nie uwzględniają jednak zasobów, które pozwolą skutecznie zarządzać tymi osobnymi wersjami w czasie – poprawki błędów, aktualizacje systemu operacyjnego i nowe funkcje wymagają równoległych ścieżek rozwoju.
W artykule tym zajmiemy się jedną z najważniejszych zalet technologii Xamarin: dzięki zastosowaniu jednej podstawy kodu i platformy programistycznej zespoły programistyczne mogą znacznie wydajniej zarządzać i utrzymywać aplikację wieloplatformową przez cały cykl jej „życia”.

Jako zespół programistów Xamarin używamy Xamarin i Xamarin.Forms, aby zaoszczędzić wiele czasu w projektach dla naszych klientów. Tworząc pojedynczą bazę kodu w języku C #, jesteśmy w stanie zaoszczędzić szacunkowo 25% wstępnego czasu rozwoju dla pierwszego wydania. A czas to pieniądz. Krótko mówiąc: Szybsze cykle programowania kolejnych wersji oszczędzają pieniądze naszych klientów.

Ale oszczędność czasu, to nie jedyna zaleta płynąca z wykorzystania technologii Xamarin.

Naprawianie błędów jest prostsze w przypadku technologii Xamarin

Jeśli niezależnie korzystasz z aplikacji na iOS i Androida, zastanów się, co się stanie, gdy zgłoszony zostanie błąd. Tak, błędy pojawiają się nawet w przypadku najlepszych programistów i procesu testowania aplikacji. Jeśli błąd dotyczy zarówno wersji na Androida, jak i iOS, nie jest to jeden błąd, ale dwa. Oznacza to dwa różne działania związane z zapewnieniem stabilności aplikacji oraz co najmniej dwóch programistów, aby znaleźć problem w dwóch bazach kodu. Tworzone są dwie różne poprawki, a następnie dwie nowe wersje są kompilowane, testowane ponownie i testowane pod kątem pełnego zestawu funkcji. Dopiero wtedy aplikacje są publikowane.

Jeśli aplikacja została zbudowana w Xamarinie, jej kod napisany jest jeden raz. Następnie możemy wypuścić nowe wersje na każdą natywną platformę. Oczywiście nawet jeśli korzystamy z Xamarina, w każdym wydaniu należy wykonać pewne zadania specyficzne dla danej platformy. Szacujemy, że podstawowa poprawka w Xamarinie zajmuje około 75% czasu potrzebnego na naprawienie niezależnych błędów w systemie iOS i Android.

W trakcie cyklu życia aplikacji może to przynieść znaczące oszczędności. Jeśli nasz zespół programistów poświęci jeden miesiąc na utrzymanie aplikacji, to biorąc pod uwagę naszą szacunkową oszczędność czasu, możemy zyskać więcej niż cały tydzień – siedem dni cennego czasu, który można poświęcić na tworzenie nowych funkcji.

Nowe funcjonalnosci

Dzięki technologii Xamarin poprawki błędów na różnych platformach można uprościć. Ale co z nowymi funkcjami? Po pierwsze, zastanówmy się, skąd pochodzą nowe pomysły na funkcje. Często wynikają z analizowania wydajności za pomocą narzędzia ‘profilera’ i narzędzi do centralnej analizy UX (User Experience). Jeśli ta analiza może być przeprowadzona w aplikacji wieloplatformowej dla systemu Android i iOS – zamiast oddzielnie – może to być duża oszczędność czasu.

Profilowanie aplikacji w Xamarin

W Akanzie używamy Xamarin Profiler do profilowania aplikacji Xamarin i sprawdzania kodu, który wymaga poprawy z punktu widzenia wydajności. Można także użyć Android Studio lub Xcode Instruments do analizy wydajności aplikacji – ale przewaga Xamarin Profiler pozwala spojrzeć na wydajność w różnych aplikacjach.

User Experience – doświadczenie użytkownika

Po pierwszym wydaniu aplikacji zespół programistów prawdopodobnie spędza dużo czasu na analizie, której celem jest zrozumieć komfort użytkownika – i to, jak UX aplikacji realizuje pierwotne cele biznesowe. Na przykład, jeśli jest to aplikacja e-commerce, będziemy analizować każdy etap procesu zakupu i określać, gdzie użytkownicy mogą porzucić swoje koszyki.

Podobnie jak w przypadku ‘profilera’, bardziej wydajne jest przeprowadzanie tej analizy na różnych platformach, dzięki czemu możemy zobaczyć trendy UX w aplikacjach na iOS i Androida. Dzięki Xamarin możemy zaimplementować kod dla wielu narzędzi analitycznych (np. Mixpanel, Google Analytics lub AppsFlyer) tylko raz, we współużytkowanej warstwie abstrakcji – zamiast dodawać je natywnie do każdej aplikacji. W zależności od narzędzia analitycznego, możemy wciąż napisać kilka linii kodu na każdej platformie, aby skopiować kod do warstwy współdzielonej. Jednak ogólny wysiłek na rzecz rozwoju jest nadal ograniczony. Zespół marketingu / produktu będzie miał możliwość analizowania UX na różnych platformach w jednym widoku.

Ten sam język – back-end

Podczas pracy z wieloplatformowymi aplikacjami Xamarin koncentrujemy się na ilości kodu współdzielonego między systemem Android i iOS, a w niektórych przypadkach na platformie Universal Windows Platform (UWP).

Jednak większość aplikacji mobilnych pobiera dane z back-endu. W wielu projektach istnieje spora szansa, że back-end używa Microsoft Azure. Jeśli nie wiesz, firma Xamarin została przejęta przez Microsoft w 2016 r. W dość krótkim czasie Xamarin został złożony w Visual Studio i jest również częścią nowego Centrum aplikacji Microsoft Visual Studio. Wszystkie narzędzia w App Center dobrze integrują się z Azure Microsoft.

Tak więc Microsoft ma kompletny zestaw narzędzi do tworzenia aplikacji, starszej platformy dla przedsiębiorstw w .NET i wielu usług w chmurze na platformie Azure – a wszystko to oparte jest na języku programowania C#. Wszystkie te elementy Microsoftu sprawiają, że korzystanie z Xamarin jest efektywnym sposobem na rozwijanie oraz zarządzanie aplikacjami mobilnymi.

Podsumowanie

Xamarin to świetny sposób na zwiększenie wydajności tworzenia aplikacji mobilnych – potencjalnie oszczędzając koszty i czas. Ale nie wszystkie elementy kodu i funkcje można łatwo udostępniać między różnymi platformami. Powiadomienia push to jeden z przykładów funkcji, w której Android i iOS różnią się. Konieczne jest napisanie niestandardowych rozwiązań na platformach natywnych – jednak nadal możemy stosować wspólną logikę w warstwie udostępnionej. Innymi słowy, możliwe jest zarządzanie powiadomieniami push za pośrednictwem Xamarin na wielu platformach, gdy zaimplementujemy natywny kod w odpowiednim miejscu.

Istnieją inne przykłady funkcji, które muszą być obsługiwane w macierzystym systemie operacyjnym – ale wraz z rozwojem systemów Android i iOS stają się one coraz bardziej do siebie podobne. Xamarin, pod kontrolą Microsoftu, nieustannie dodaje nowe możliwości korzystania z funkcji na różnych platformach.

Niezależnie od rozmiaru projektu, firmy lub zastosowanej technologii, można zauważyć te same rodzaje błędów związanych z testowaniem wydajności oprogramowania.Nie jest to rzecz zaskakująca, ponieważ ludzka natura jest taka sama niezależnie od firmy, a każde środowisko projektowe i biznesowe ma terminy i deadliney, których musi dotrzymać. Czasami sytuacja wymaga tego, że testowaniem zajmujemy się bardzo szybko i wykonujemy je pobieżnie.  Niestety droga „na skróty” może prowadzić do kosztownych błędów i niedopatrzeń.
Jednak dzięki odrobinie samoświadomości i kilku pomocnym narzędziom towarzyszącym można w łatwy sposób wyeliminować te błędy.

1. Nieadekwatny User Think Time – czas od zakończenia jednego żądania do rozpoczęcia następnego żądania

Bombardowanie aplikacji czy programu setkami lub tysiącami żądań na sekundę bez żadnego czasu na przetworzenie zapytań (think time) powinno być stosowane tylko w rzadkich przypadkach, w których konieczne jest zasymulowanie tego typu zachowania – ataku Denial of Service (atak na system komputerowy lub usługę sieciową w celu uniemożliwienia działania poprzez zajęcie wszystkich wolnych zasobów). 99% osób nie testuje jednak tego scenariusza tylko próbują sprawdzić, czy ich strona może obsłużyć obciążenie docelowe. W takim przypadku czas przetworzenia informacji (think time) jest bardzo ważny.

Wiele osób przeprowadza testy bez uwzględniania czasu przetworzenia informacji (think time) z tysiącami użytkowników a następnie zadaje pytanie: dlaczego moje czasy odpowiedzi są wolne? Kiedy ręcznie odwiedzam witrynę za pomocą mojej przeglądarki, wydaje się, że odpowiada ona dobrze.

Dość łatwo można rozwiązać ten problem, dodając pewnego rodzaju czas oczekiwania/oczekiwania pomiędzy krokami użytkownika wirtualnego, skutecznie spowalniając użytkownika do bardziej realistycznego tempa. Prawdziwy użytkownik nigdy nie wykonałby żądań strony w ciągu 1 sekundy. Czas myślenia pozwala dodać ludzką pauzę, naśladując prawdziwą osobę, która będzie czekać kilka sekund, zanim wejdzie w interakcję z witryną. Prostym rozwiązaniem jest użycie losowego zegara Gaussa podczas projektowania testów, który pozwala użytkownikom na interakcję w sposób losowy, tak jak w rzeczywistym świecie.

2. Używanie niedokładnego modelu obciążenia

Model obciążenia jest szczegółowym planem, zgodnie z którym powinno się programować kolejne funkcjonalności aplikacji czy strony internetowej. Model ten powinien zawierać opis procesów biznesowych, wymaganych kroków, liczby użytkowników, liczby transakcji na użytkownika i obliczonego tempa dla każdego użytkownika.

Posiadanie dokładnego modelu obciążenia ma kluczowe znaczenie dla ogólnego sukcesu testów i późniejszego działania systemu w ogóle. Często łatwiej to powiedzieć, niż zrobić, ponieważ wymagania biznesowe nie były uważane za wykraczające poza stwierdzenie, że „system powinien być szybki”.

W przypadku istniejących aplikacji czy sklepów internetowych zawsze warto mieć dostęp do statystyk, które pokażą wiele informacji, takich jak:
• Jakie są najczęstsze/najbardziej popularne transakcje?
• Ile transakcji odbywa się w typowy dzień roboczy?
• Ile z każdego rodzaju transakcji odbywa się w szczytowych okresach aktywności użytkowników?
• Jakie są ogólne czasy lub okresy, w których transakcje te występują?
• Jakie transakcje wiążą się z wysokimi kosztami biznesowymi, jeśli miałyby zawieść w przypadku dużego obciążenia?

Na podstawie tych kryteriów można stworzyć obraz modelu obciążenia, który należy symulować.
W przypadku nowych systemów/sklepów internetowych ogólną zasadą jest jak największa współpraca z przedstawicielami biznesu. Celem tego jest ustalenie realnych i uzgodnionych danych, które są dobrze zdefiniowane, proste i możliwe do przetestowania.

Po pierwszym cyklu związanym z testowaniem i uruchomieniu aplikacji, bieżące monitorowanie użycia zasobów pomoże uzyskać informacje zwrotne dla następnej rundy związanym z testowaniem, w której model obciążenia systemu może być dalej dostosowywany.

3. Konfigurowanie niewłaściwego monitorowania infrastruktury

Wyniki testów wykonywalności, takie jak przepustowość, czasy odpowiedzi transakcji i informacje o błędach, nie są zbyt pomocne, chyba że można zobaczyć, w jaki sposób infrastruktura docelowa radzi sobie ze scenariuszem.

Jest to powszechny problem. Wielu testerów zadaje sobie pytanie, dlaczego czas reakcji zajmuje minuty zamiast sekund. Problem może leżeć albo w generowaniu obciążenia, albo w docelowej infrastrukturze aplikacji.

Jak sobie z tym poradzić? Idealnym rozwiązaniem jest posiadanie niestandardowych pulpitów kontrolnych dla całej infrastruktury generowania obciążenia na żądanie. Niektóre platformy związane z testowaniem, takie jak Tricentis Flood, udostępniają niestandardowe raporty monitorowania. Umożliwiają one przeglądanie wykorzystania zasobów systemowych podczas wykonywania testów, zapewniając, że nie występują żadne „wąskie gardła” po stronie infrastruktury systemu.

Po stronie docelowej aplikacji można zaimplementować je, aby zdiagnozować problemy lub spowolnienia działania aplikacji / systemu podczas testów. W tej chwili dostępnych jest co najmniej 100 usług monitorowania aplikacji – wszystkie z różnymi cenami i funkcjami. Korzystając z wielu popularnych usług, takich jak New Relic, AppDynamics i Splunk należy pamiętać, że mogą być one dość kosztowne w przypadku opcji pełnego monitorowania. Istnieje również kilka darmowych alternatyw open-source, takich jak Nagios i InspectIT. Nie są tak dopracowane, ale przy odrobinie wiedzy i czasu poświęconego na ich ustawienie, rozwiązanie to może być bardziej opłacalne.

4. Używanie zakodowanych danych w każdym zapytaniu

Używanie tych samych danych w żądaniu HTTP dla każdego użytkownika nie jest realistycznym scenariuszem użycia systemu. Często inteligentne aplikacje i istniejąca technologia baz danych rozpoznają identyczne żądania i automatycznie je buforują, dzięki czemu ogólny system wydaje się szybszy niż jest. Prowadzi to do nieprawidłowego testu wydajności.

Pomyślmy o prostej czynności rejestrowania nowego użytkownika dla typowej witryny zakupów on-line. Większość (jeśli nie wszystkie) strony nie pozwalają na zarejestrowanie tego samego użytkownika więcej niż jeden raz bez podania konkretnych informacji.

Nie będziemy w stanie dalej przesyłać tego żądania do witryny sklepowej, ponieważ wymagana jest pewna weryfikacja, szczególnie w polach numeru kontaktowego czy adresu e-mail.
Zamiast tego możemy uczynić te dwa pola unikalnymi, więc za każdym razem uda nam się pomyślnie uruchomić test. Dzięki open-sourcowemu programowi JMeter możemy łatwo korzystać z wbudowanych generatorów liczb losowych. Aby pola takie jak numery telefonów i adresy e-mail były niepowtarzalne.

Kiedy uruchamiamy aplikację w teście obciążenia, każde pojedyncze żądanie będzie miało inny numer telefonu komórkowego i adres e-mail. Ten prosty przykład użycia dynamicznych danych dla wszystkich żądań może zaoszczędzić wielu nieprawidłowych testów.

5. Ignorowanie błędów systemu lub skryptu, ponieważ czasy odpowiedzi i przepustowość wyglądają dobrze

Bardzo łatwo jest wyeksponować szczegóły, które mogą mieć ogromny wpływ na ważność testu. Oto typowy scenariusz:

Test obciążenia działa z docelową liczbą użytkowników, a tester widzi, że czasy odpowiedzi i poziomy błędów mieszczą się w dopuszczalnych zakresach. Oczekiwana przepustowość jest jednak niższa, niż zakładano. Jak to możliwe, gdy platforma związana z testowaniem obciążenia zgłasza bardzo mało błędów związanych z transakcjami?

Może się zdarzyć, że napotkamy błędy systemowe, które nie są zgłaszane w liczbie transakcji/nieudanych transakcji – dlatego wszystko wygląda dobrze na pierwszy rzut oka. Niższa niż oczekiwana liczba transakcji na minutę lub wartość RPM jest znakiem rozpoznawczym tego problemu.

Przejście do dzienników „run time” ujawni problem po stronie skryptów, który można następnie naprawić. Kiedy czas odpowiedzi, liczba błędów i przepustowość znajdują się w oczekiwanej strefie, czy można myśleć, że wszystko jest ok?

Jeszcze nie teraz. Niemal zawsze jest przeoczony obszar, który może mieć wpływ na testy obciążenia: weryfikacja rzeczywistych dzienników systemu lub aplikacji podczas testu.

Można to łatwo monitorować, jeśli używa się specjalnie zbudowanego narzędzia APM (Application Performance Monitoring), takiego jak New Relic lub AppDynamics. Należy jednak pamiętać dużo czasu zajmie ręczne konfiguracja danego narzędzia.

Wyjątki mogą być spowodowane różnymi czynnikami, co oznacza, że należy dokładnie przeanalizować, dlaczego zostały spowodowane przez scenariusz testu obciążenia i jakie mają one wpływ na wydajność i stabilność systemu.

Wyjątki często wiążą się z olbrzymim obciążeniem wydajności związanym z procedurami ich obsługi i wszelkim powiązanym protokołowaniem z operacjami na dyskach lub w pamięci. Może to nie stanowić problemu przy pojedynczej transakcji, ale jeżeli pomnożymy ją przez ponad 1000 równoczesnych użytkowników i może to poważnie wpłynąć na szybkość reagowania systemu.