Tag: czas

Blockchain – niezmienna, zaszyfrowana, zdecentralizowana baza danych ma potencjał, aby każdy scentralizowany proces, działalność i organizacja były w pełni autonomiczne. Oznacza to, że możemy wyeliminować pośredników i w ten sposób usprawnić każdy biznes, zarządzanie czy działalność non-profit. Choć brzmi to niesamowicie, nadal jest to odległa przyszłość. Pośród wielu możliwości związanych z technologią Blockchain, istnieje wiele wątpliwości co do jej przyszłości. W artykule tym omówimy kilka zagadnień związanych z przyszłością technologii Blockchain.

4. Zapewnienie bezpiecznego Internetu przyszłości

Najważniejszą cechą technologii blockchain jest to, że zapewnia niespotykane do tej pory bezpieczeństwo w Internecie, w którym nielegalne wyłudzanie danych, złośliwe oprogramowanie, spam i hacki stanowią zagrożenie dla globalnego biznesu.

Jedną z głównych korzyści, które zapewnia blockchain nad innymi typami oprogramowania jest to, że opiera się na kryptografii i jest zbudowany tak, aby nie można było wprowadzić zmian do istniejącego już łańcucha bloków. Po prostu nie można wrócić do pewnego punktu w blockchainie i zmienić tam informacje. Przez 10 lat istnienia technologii blockchain, nigdy nie został zhackowany.

Inną kluczową zaletą technologii blockchain jest rozproszenie w sieci, dzięki czemu niemożliwe jest przejęcie nad nią kontroli przez np. autorytarny rząd lub wielkie korporacje w przypadku nielegalnych praktyk biznesowych. Na przykład, nieruchomości zakupione i udokumentowane w blockchainie nie mogą być usunięte lub ukryte przez jakikolwiek organ administracyjny, dzięki czemu właściciel chroniony jest przed nadużyciami.

Wreszcie, blockchain jest doskonałym narzędziem do przechowywania ogromnej ilości ważnych dokumentów w branżach takich jak służba zdrowia, logistyka, prawo autorskie i wiele innych. Blockchain eliminuje potrzebę pośrednika, jeśli chodzi o legalizowanie umów. Inteligentne platformy kontraktowe są wciąż doskonalone, jeśli chodzi o przyjazność dla użytkownika i uważa się, że znajdą szerokie zastosowanie w ciągu najbliższych 5 lat.

5. Blockchain w reklamach cyfrowych

Reklama cyfrowa napotyka wyzwania, takie jak oszustwa w przekierowaniu na inną domenę, fałszywy ruch w postaci botów, brak przejrzystych, jednolitych modeli płatności. Problem polega na tym, że stymulacja rynku nie jest równomierna, co powoduje, że zarówno reklamodawcy, jak i wydawcy nie do końca są zadowoleni z osiągnięcia celów biznesowych. Blockchain jest rozwiązaniem zapewniającym przejrzystość w łańcuchu dostaw, ponieważ z natury wnosi zaufanie do bardzo szybko zmieniającego się środowiska.

Dzięki zmniejszeniu liczby złych praktyk w środowisku reklamowym, dobre firmy mogą się rozwijać. Co najważniejsze, wydawcy mogą zebrać wyższy procent łącznej kwoty reklam wpuszczanych do ekosystemu i będą to robić w momencie dostarczania trafnych wyświetleń. Blockchain jest wciąż jeszcze w powijakach, ale podstawowa technologia jest tu na miejscu, a wszystkie firmy zajmujące się technologiami reklamowymi powinny się zastanowić, w jaki sposób może to pomóc w usprawnieniu ich działalności.

6. Wpływ tzw. ‘Streaming Money’ na biznes

Przyzwyczailiśmy się do miesięcznego (w Europie zachodniej tygodniowego) okresu rozliczeniowego, który bierzemy pod uwagę w biznesie i jako pracownicy. Jednak rok 2018 wyznacza nowe podejście, w którym nie jest to już obowiązujaca norma. Bardzo ekscytującą możliwością technologii blockchain są nowe formy mikropłatności. Kolejną są inteligentne kontrakty (Smart Contracts). Chociaż było to przewidywane wiele lat temu przez Andreasa Antonopolisa, rzeczywistość dopiero teraz przynosi efekty.

Bitcoin początkowo miał bardzo niskie opłaty, ale blokowanie/zatykanie się sieci spowodowało zniknięcie mikropłatności. W tym roku możemy obserwować sieć ‘lightning’ i sieć Raiden. Obie zyskują na popularności oraz przywracają szybkie mikropłatności.

Za pomocą prostego inteligentnego kontraktu pracownik może otrzymywać wynagrodzenie w czasie rzeczywistym, gdy pracuje. A to oznacza, że faktycznie działa. Programy monitorujące mogą z łatwością śledzić naciśnięcia klawiszy, widzieć, czy pracownicy nie robią sobie przerwy na Facebooku oraz mierzą produktywność. Płać, w czasie rzeczywistym, gdy pracują.

Jest to zaleta zarówno dla firmy, jak i pracownika. Zasady są jasne i proste a bardziej zaangażowani pracownicy otrzymają lepsze wynagrodzenie. Chcesz zarobić trochę więcej? Zostań w pracy dłużej i zwiększaj aktywa swojego konta w czasie rzeczywistym. Wiele firm korzysta już z usług takich jak np. Upwork. Programy te monitorują pracę zdalnych pracowników w czasie rzeczywistym. Stoimy zatem u progu wielkich zmian systemu płatności.

7. Czy jesteśmy już gotowi na rewolucję

Chociaż perspektywy wydają się bardzo optymistyczne, istnieje wiele ograniczeń związanych z pełniejszym wykorzystaniem technologii blockchain. Jeff Stollman, futurysta ds. technologii, podzielił się swoimi przemyśleniami na temat obecnych ograniczeń technologii o tak dużym potencjale. Od ponad trzech lat projektuje rozwiązania blockchain dla klientów i oczekuje na cztery patenty w obszarze tej technologii. Oto, co powiedział:

„Potencjał technologii Blockchain w przedsiębiorstwach jest olbrzymi, ale wdrożenia działających rozwiązań dla korporacji będą trwały jeszcze parę lat. Istnieją dwa powody tego stanu. Po pierwsze, sama technologia blockchain jest niewystarczająco dojrzała, aby obsłużyć wolumeny transakcji niezbędne do obsługi większości aplikacji dla przedsiębiorstw. Po drugie, aplikacje korporacyjne, które będą wykorzystywane w różnych sektorach przemysłu, wymagają ustanowienia nowych zasad zarządzania. Wypracowanie nowych może trwać wiele lat.

Jeśli chodzi o technologię, jedynymi dostępnymi obecnie aplikacjami opartymi o blockchain dla przedsiębiorstw są aplikacje działające w dość ograniczonej skali, takie jak Everledger Dimond Platform śledzący własność i pochodzenie certyfikowanych, oszlifowanych diamentów. Każdy rejestr/baza danych zarządza i monitoruje ponad 1,6 miliona diamentów. Ale diamentami nie handluje się z wysoką częstotliwością. Jest to inwestycja raczej długoterminowa.

Duże systemy płatności, takie jak VISA, obecnie przetwarzają płatności w tempie, które pozwoliłoby obsłużyć całą bazę diamentów Everledger w ciągu nieco ponad 1 minuty (~ 24 000 transakcji na sekundę). Wśród popularnych kryptowalut Bitcoin przetwarza tylko 7 transakcji na sekundę, a Ethereum obsługuje tylko 20 tps. Nie ma żadnego ograniczenia, aby przyspieszyć szybkość przetwarzania danych w technologii blockchain. Potrzebne są jednak nowe rozwiązania, aby spełnić wysokie wymagania dotyczące przepustowości i poufności takich aplikacji dla przedsiębiorstw. Na przykład twórcy BigChainDB, który nie jest prawdziwym blockchainem, ale oferuje wiele pożądanych funkcji, twierdza, że są w stanie przetworzyć 1 milion transakcji na sekundę.

Jeśli chodzi o zarządzanie, większość aplikacji korporacyjnych będzie działać na dedykowanych, prywatnych łańcuchach bloków. Nie będą to aplikacje typu single-owner, takie jak Everledger. Własność będzie dzielona przez grupę kontrahentów. Banki współpracują w celu opracowania nowych systemów płatności. Firmy logistyczne i banki współpracują ze sobą w celu opracowania nowych rozwiązań finansowych w handlu. Przedsiębiorstwa te będą unikać popularnych łańcuchów blockchain, takich jak Bitcoin i Ethereum, w celu osiągnięcia wymaganej przepustowości i lepszej kontroli poufności. Dzisiejsze transakcje na Bitcoin i Ethereum są prywatne tylko dlatego, że ich transakcje są niewystarczające, aby umożliwić analitykom (big-data) identyfikację stron transakcji. Nie dotyczy to większości transakcji w przedsiębiorstwach.

Ponieważ łańcuchy bloków będą prywatne, członkowie będą musieli uzgodnić zasady zarządzania, w ramach których będą działać. Jest to proces podobny do negocjacji międzynarodowych standardów, który zwykle trwa lata. Dzieje się tak, ponieważ różni członkowie starają się wypracować swój szczególny standard działania. Zarządzanie zdecentralizowanym łańcuchem bloków zazwyczaj wymaga osiągnięcia konsensusu w wielu aspektach działalności: członkostwo, kontrola dostępu, jakie dane są w łańcuchu i jakie dane są przechowywane poza łańcuchem, procedury weryfikacji i sprawdzania poprawności transakcji, własność blockchain, zarządzanie blockchain itp.

Z czasem uda się wypracować pożądane standardy, przezwyciężając zarówno przeszkody technologiczne, jak i prawne. Ale znaczny postęp będzie potrzebny na obu frontach, zanim korporacyjne aplikacje blockchain osiągną szerokie zastosowanie. „

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.