Kilka liczb, które powinien znać każdy programista

Kilka liczb, które powinien znać każdy programista

Gdy przechodzisz z programowania aplikacji webowych do budowy systemów o dużej wydajności, to czujesz się trochę, jakbyś wskoczył za białym królikiem do jego nory - nagle lądujesz po drugiej stronie lustra, gdzie niby wszystko jest podobne, ale obowiązuje nieco inna fizyka.


W świecie aplikacji internetowych 100 ms to szybko, w świecie high performance 100 ms to zwykle nieakceptowalnie wolno.


Dlaczego tak jest?


Budując systemy high performance, bez względu na wybraną technologię czy język programowania, bardzo często zadajemy sobie pytanie: jaka jest graniczna szybkość/opóźnienie, z jaką może działać dany proces, a następnie - co możemy zrobić, żeby zbliżyć się do tej liczby?


Liczba ta zwykle ograniczona jest szybkością naszego hardware, a ten bardzo zmienił się przez ostatnie 20 lat. Dyski HDD zostały zastąpione dyskami SSD. W każdej serwerowni najwolniejszy link między maszynami ma 10 Gbps. A pojedynczy serwer z 48 TB RAM (tak, 48 TB RAM, nie 48 GB RAM) można sobie kupić przez internet.


Jak wyglądają te liczby? Świetne zestawienia przygotowali Jonas Bonér, autor frameworku Akka: oraz Collin Scoot.


Różnią się one w szczegółach, ale rząd wielkości pozostaje ten sam:



(źródło: https://colin-scott.github.io/personal_website/research/interactive_latency.html)


Co z tego wynika?


  • Współczesne CPU są kosmicznie szybkie,


  • Cache CPU, czyli pamięć znajdującą się bezpośrednio przy procesorze, jest także niesamowicie szybka,


  • Dostęp do pamięci RAM jest wolniejszy od dostępu do CPU cache o dwa rzędy wielkości,


  • Odczytanie danych z SSD jest o rząd wielkości wolniejszy od odczytania danych z RAM,


  • Internet jest bardzo wolny, o dwa rzędy wielkości wolniejszy niż czytanie z dysku.


Jak możemy zbliżyć się do tych wartości w realnym, codziennym programowaniu?


Wnioski nasuwają się same


  • Im bliżej CPU trzymamy dane, tym lepiej. Czyli: korzystamy ze struktur danych oraz metod alokacji pamięci, które organizują dane blisko siebie, w odpowiedniej kolejności,


  • Programujemy w sposób, który ułatwia CPU przewidywanie, w jaki sposób będziemy korzystać z danych, tym samym ułatwiając eleganckie ładowanie do CPU cache,


  • Unikamy bezproduktywnej modyfikacji danych w RAM - typowy przykład to ciągła serializacja/deserializacji między formatami i interfejsami,


  • Unikamy dostępu do dysków oraz przesyłania danych w sieci lokalnej, absolutnie wzbraniamy się przed budowaniem systemów rozproszonych w różnych data center.



Ale co z architekturą, nasze mikroserwisy, CQRS, może chociaż REST API i jak to zrobić w Javie?


To świetne pytania. 


Bardzo często oceniając i wybierając różne modele architektur patrzymy na takie cechy, jak możliwość mieszania technologii, rozwijania systemu przez niezależne zespoły, łatwość integracji z innymi komponentami. 


Niestety żadna z tych cech nie ma zbyt wiele wspólnego z profilem wydajności, który staje się kolejnym, niezależnym kryterium do oceny.


Jeśli spodobał Ci się ten post, daj znać, będzie to sygnał dla mnie i innych osób ze Stratoflow, żeby napisać coś więcej o tym, jak analizujemy i budujemy takie rzeczy w Javie - tak, w Javie :)


Autorem tekstu jest Michał Głomba, CEO Stratoflow.

44komentarze
Podziel się
27.01.2022 13:20
27.01.2022 13:20

Kilka liczb, które powinien znać każdy programista

Kilka liczb, które powinien znać każdy programista

Gdy przechodzisz z programowania aplikacji webowych do budowy systemów o dużej wydajności, to czujesz się trochę, jakbyś wskoczył za białym królikiem do jego nory - nagle lądujesz po drugiej stronie lustra, gdzie niby wszystko jest podobne, ale obowiązuje nieco inna fizyka.


W świecie aplikacji internetowych 100 ms to szybko, w świecie high performance 100 ms to zwykle nieakceptowalnie wolno.


Dlaczego tak jest?


Budując systemy high performance, bez względu na wybraną technologię czy język programowania, bardzo często zadajemy sobie pytanie: jaka jest graniczna szybkość/opóźnienie, z jaką może działać dany proces, a następnie - co możemy zrobić, żeby zbliżyć się do tej liczby?


Liczba ta zwykle ograniczona jest szybkością naszego hardware, a ten bardzo zmienił się przez ostatnie 20 lat. Dyski HDD zostały zastąpione dyskami SSD. W każdej serwerowni najwolniejszy link między maszynami ma 10 Gbps. A pojedynczy serwer z 48 TB RAM (tak, 48 TB RAM, nie 48 GB RAM) można sobie kupić przez internet.


Jak wyglądają te liczby? Świetne zestawienia przygotowali Jonas Bonér, autor frameworku Akka: oraz Collin Scoot.


Różnią się one w szczegółach, ale rząd wielkości pozostaje ten sam:



(źródło: https://colin-scott.github.io/personal_website/research/interactive_latency.html)


Co z tego wynika?


  • Współczesne CPU są kosmicznie szybkie,


  • Cache CPU, czyli pamięć znajdującą się bezpośrednio przy procesorze, jest także niesamowicie szybka,


  • Dostęp do pamięci RAM jest wolniejszy od dostępu do CPU cache o dwa rzędy wielkości,


  • Odczytanie danych z SSD jest o rząd wielkości wolniejszy od odczytania danych z RAM,


  • Internet jest bardzo wolny, o dwa rzędy wielkości wolniejszy niż czytanie z dysku.


Jak możemy zbliżyć się do tych wartości w realnym, codziennym programowaniu?


Wnioski nasuwają się same


  • Im bliżej CPU trzymamy dane, tym lepiej. Czyli: korzystamy ze struktur danych oraz metod alokacji pamięci, które organizują dane blisko siebie, w odpowiedniej kolejności,


  • Programujemy w sposób, który ułatwia CPU przewidywanie, w jaki sposób będziemy korzystać z danych, tym samym ułatwiając eleganckie ładowanie do CPU cache,


  • Unikamy bezproduktywnej modyfikacji danych w RAM - typowy przykład to ciągła serializacja/deserializacji między formatami i interfejsami,


  • Unikamy dostępu do dysków oraz przesyłania danych w sieci lokalnej, absolutnie wzbraniamy się przed budowaniem systemów rozproszonych w różnych data center.



Ale co z architekturą, nasze mikroserwisy, CQRS, może chociaż REST API i jak to zrobić w Javie?


To świetne pytania. 


Bardzo często oceniając i wybierając różne modele architektur patrzymy na takie cechy, jak możliwość mieszania technologii, rozwijania systemu przez niezależne zespoły, łatwość integracji z innymi komponentami. 


Niestety żadna z tych cech nie ma zbyt wiele wspólnego z profilem wydajności, który staje się kolejnym, niezależnym kryterium do oceny.


Jeśli spodobał Ci się ten post, daj znać, będzie to sygnał dla mnie i innych osób ze Stratoflow, żeby napisać coś więcej o tym, jak analizujemy i budujemy takie rzeczy w Javie - tak, w Javie :)


Autorem tekstu jest Michał Głomba, CEO Stratoflow.

KOMENTARZE (0)

Dodaj pierwszy komentarz

Ostatnie komentarze w Random
Tu właśnie ciekawie się dyskutuje

Najpopularniejsze w społeczności
Te treści czekają też na Twoją uwagę

Oh My Dev logo
Oh My Dev logo

OhMyDev.pl - to, co najważniejsze w IT - od devów dla devów

Oh My Dev to społeczność dla każdej osoby, która interesuje się lub zajmuje szeroko pojętym IT. Najnowsze i najpopularniejsze informacje z całego świata IT. Szukaj, oceniaj, komentuj, czytaj, twórz.