Scaling-up \u2013 magiczne s\u0142owo, kt\u00f3re pojawia si\u0119 w ka\u017cdym pitch decku i na spotkaniach zarz\u0105du. Ale prawda jest taka, \u017ce wi\u0119kszo\u015b\u0107 firm rzuca si\u0119 na skalowanie jak na ratunek, zanim w og\u00f3le sprawdzi, czy aplikacja na to zas\u0142uguje. Widzia\u0142em to wielokrotnie: startup dostaje pierwszy wi\u0119kszy ruch, deweloperzy panikuj\u0105, zarz\u0105d ka\u017ce dokupi\u0107 serwery, a po tygodniu okazuje si\u0119, \u017ce aplikacja dzia\u0142a r\u00f3wnie wolno, tylko rachunki s\u0105 wy\u017csze. Brzmi znajomo?<\/p>\n
Skalowanie w g\u00f3r\u0119 (ang. vertical scaling) lub na zewn\u0105trz (ang. horizontal scaling) bez solidnych danych to jak kupowanie wi\u0119kszego samochodu, bo \u017ale wyregulowa\u0142e\u015b ga\u017anik. W dzisiejszych czasach, gdy ka\u017cda milisekunda op\u00f3\u017anienia kosztuje konwersj\u0119, a bud\u017cety M\u015aP s\u0105 napi\u0119te, nie mo\u017cesz pozwoli\u0107 sobie na zgadywank\u0119. Dlatego zanim wydasz pierwsze pieni\u0105dze na now\u0105 infrastruktur\u0119, przeprowad\u017a te trzy testy. Poka\u017c\u0105 Ci, gdzie le\u017cy prawdziwy problem: w kodzie, w architekturze, czy w konfiguracji.<\/p>\n
Pierwszym krokiem jest test obci\u0105\u017ceniowy, ale nie byle jaki \u2013 chodzi o test, kt\u00f3ry odzwierciedla rzeczywiste \u015bcie\u017cki u\u017cytkownik\u00f3w w Twojej aplikacji. Zbyt cz\u0119sto widz\u0119, jak firmy u\u017cywaj\u0105 narz\u0119dzi takich jak Apache JMeter czy Locust do symulacji ruchu, ale robi\u0105 to \u017ale. Wysy\u0142aj\u0105 setki zapyta\u0144 do jednego endpointu, kt\u00f3ry rzadko jest faktycznie obci\u0105\u017cany, albo ignoruj\u0105 my\u015blenie u\u017cytkownika (czas mi\u0119dzy akcjami). Rezultat? Dane m\u00f3wi\u0105, \u017ce aplikacja wytrzymuje 1000 RPS, a w praktyce na 200 u\u017cytkownikach pada.<\/p>\n
Jak to zrobi\u0107 poprawnie?<\/strong><\/p>\n Zacznij od analizy dziennik\u00f3w serwera lub Google Analytics. Dowiedz si\u0119, kt\u00f3re \u015bcie\u017cki s\u0105 najcz\u0119\u015bciej u\u017cywane \u2013 logowanie, przegl\u0105danie produkt\u00f3w, dodawanie do koszyka, finalizacja zam\u00f3wienia. Stw\u00f3rz scenariusz testowy, kt\u00f3ry odtworzy te kroki z op\u00f3\u017anieniami mi\u0119dzy akcjami (np. 3-5 sekund). U\u017cyj narz\u0119dzia, kt\u00f3re pozwoli na stopniowe zwi\u0119kszanie liczby wirtualnych u\u017cytkownik\u00f3w, a\u017c do momentu, gdy czas odpowiedzi przekroczy akceptowalny pr\u00f3g (np. 2 sekundy na stron\u0119).<\/p>\n Co to daje?<\/strong><\/p>\n Taki test od razu poka\u017ce, gdzie aplikacja zaczyna zwalnia\u0107. Mo\u017ce to by\u0107 konkretny zapytanie do bazy danych, s\u0142abo zoptymalizowany kod backendu, albo zbyt ma\u0142a pula po\u0142\u0105cze\u0144. Zamiast zgadywa\u0107, otrzymasz twarde dane, kt\u00f3re mo\u017cesz przedstawi\u0107 deweloperom. Pami\u0119taj, \u017ce skalowanie nie naprawi z\u0142ych zapyta\u0144 SQL \u2013 wr\u0119cz przeciwnie, dodanie wi\u0119kszej mocy mo\u017ce zamaskowa\u0107 problem, ale on wr\u00f3ci w momencie, gdy ruch skoczy.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Drugi test to identyfikacja w\u0105skich garde\u0142 na ka\u017cdym poziomie: CPU, pami\u0119\u0107, I\/O dysku, sie\u0107, pula po\u0142\u0105cze\u0144 do bazy danych, kolejka zada\u0144 asynchronicznych. Sam test obci\u0105\u017ceniowy powie Ci, \u017ce aplikacja zwalnia, ale nie powie dok\u0142adnie gdzie. Potrzebujesz narz\u0119dzi Application Performance Monitoring (APM) takich jak New Relic, Datadog, czy open-source\u2019owy Prometheus z Grafana.<\/p>\n Jak to zrobi\u0107 poprawnie?<\/strong><\/p>\n Podczas testu obci\u0105\u017ceniowego uruchom monitoring na wszystkich serwerach i w samej aplikacji. Patrz na metryki:<\/p>\n Co to daje?<\/strong><\/p>\n Zamiast kupowa\u0107 wi\u0119cej serwer\u00f3w, mo\u017cesz cz\u0119sto rozwi\u0105za\u0107 problem przez:<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Trzeci test to sprawdzenie, czy Twoja aplikacja w og\u00f3le nadaje si\u0119 do skalowania horyzontalnego \u2013 czyli dodawania kolejnych instancji. To test, kt\u00f3ry wi\u0119kszo\u015b\u0107 firm pomija w po\u015bpiechu, a potem dziwi\u0105 si\u0119, \u017ce dodanie drugiego serwera nie daje podwojenia wydajno\u015bci. Dlaczego? Bo cz\u0119sto aplikacja ma stan (session state, stan w pami\u0119ci) lub u\u017cywa monolitycznej bazy danych, kt\u00f3ra staje si\u0119 w\u0105skim gard\u0142em.<\/p>\n Jak to zrobi\u0107 poprawnie?<\/strong><\/p>\n Postaw dwie instancje swojej aplikacji (np. na Dockerze lub w chmurze) i skonfiguruj load balancer. Nast\u0119pnie uruchom test obci\u0105\u017ceniowy na jednej instancji, zmierz maksymalny przep\u0142yw (np. 500 RPS). Potem uruchom ten sam test na dw\u00f3ch instancjach i zobacz, czy przep\u0142yw wynosi 1000 RPS. Je\u015bli nie, to znaczy, \u017ce wyst\u0119puje overhead na komunikacj\u0119 mi\u0119dzy instancjami, problem ze wsp\u00f3\u0142dzieleniem stanu lub baza danych jest bottleneckiem.<\/p>\n Co to daje?<\/strong><\/p>\n Test ten ujawni problemy architektoniczne. Na przyk\u0142ad:<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Zanim zdecydujesz si\u0119 na skalowanie \u2013 w pionie czy poziomie \u2013 wykonaj te trzy testy. Kosztuj\u0105 one kilka godzin pracy, a mog\u0105 zaoszcz\u0119dzi\u0107 tysi\u0105ce z\u0142otych miesi\u0119cznie.<\/p>\n W dzisiejszych realiach, gdzie ka\u017cda sekunda op\u00f3\u017anienia to utrata klienta, a bud\u017cety M\u015aP s\u0105 napi\u0119te, nie sta\u0107 Ci\u0119 na zgadywanie. Skalowanie powinno by\u0107 odpowiedzi\u0105 na rzeczywist\u0105 potrzeb\u0119, a nie panicznym dzia\u0142aniem. Pami\u0119taj, \u017ce cz\u0119sto lepszy kod i odpowiednie indeksy w bazie danych s\u0105 ta\u0144sze ni\u017c dodatkowe serwery.<\/p>\n Je\u015bli potrzebujesz pomocy w przeprowadzeniu takich test\u00f3w lub audycie wydajno\u015bci Twojej aplikacji \u2013 JurskiTech.pl od lat pomaga firmom m\u0105drze skalowa\u0107. Nie hejtujemy bud\u017cet\u00f3w na chmur\u0119 \u2013 optymalizujemy rzeczywiste \u017ar\u00f3d\u0142o problemu.<\/p>\n","protected":false},"excerpt":{"rendered":" Jak realnie sprawdzi\u0107 wydajno\u015b\u0107 aplikacji przed skalowaniem? 3 testy, kt\u00f3re ka\u017cdy CTO powinien zna\u0107 Wst\u0119p Scaling-up \u2013 magiczne s\u0142owo, kt\u00f3re pojawia si\u0119 w ka\u017cdym pitch decku i na spotkaniach zarz\u0105du. Ale prawda jest taka, \u017ce wi\u0119kszo\u015b\u0107 firm rzuca si\u0119 na skalowanie jak na ratunek, zanim w og\u00f3le sprawdzi, czy aplikacja na to zas\u0142uguje. Widzia\u0142em to<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[1003,379,984,988],"class_list":["post-2799","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-debugowanie-wydajnosci","tag-globalne-skalowanie","tag-optymalizacja-api","tag-testy-obciazeniowe"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2799","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2799"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2799\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2799"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2799"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2799"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nPracowa\u0142em z klientem, kt\u00f3ry narzeka\u0142, \u017ce jego aplikacja e-commerce zwalnia przy 500 u\u017cytkownikach. Zrobili\u015bmy test obci\u0105\u017ceniowy i okaza\u0142o si\u0119, \u017ce jeden endpoint \u2013 listowanie produkt\u00f3w \u2013 wykonywa\u0142 zapytanie bez indeksu, kt\u00f3re przy 200 u\u017cytkownikach trwa\u0142o 8 sekund. Dodanie indeksu skr\u00f3ci\u0142o czas do 50 ms, a aplikacja obs\u0142u\u017cy\u0142a 5000 u\u017cytkownik\u00f3w bez zmian w infrastrukturze. Koszt? Trzy godziny pracy developera. Zamiast dok\u0142ada\u0107 serwery za 2000 z\u0142 miesi\u0119cznie.<\/p>\n2. Test w\u0105skiego gard\u0142a (bottleneck identification) \u2013 u\u017cyj narz\u0119dzi APM<\/h2>\n
\n
\n
\nKlient z bran\u017cy fintech: aplikacja do przetwarzania p\u0142atno\u015bci zwalnia\u0142a przy 300 transakcjach na minut\u0119. Monitoring pokaza\u0142, \u017ce CPU jest na niskim poziomie, ale pami\u0119\u0107 stale ro\u015bnie. Debugowanie wykaza\u0142o wyciek pami\u0119ci w jednym serwisie odpowiedzialnym za generowanie PDF-\u00f3w \u2013 nie zwalnia\u0142 on zasob\u00f3w po zako\u0144czeniu zadania. Naprawa wycieku zaj\u0119\u0142a dwa dni, a aplikacja zacz\u0119\u0142a obs\u0142ugiwa\u0107 1500 transakcji bez zmiany sprz\u0119tu.<\/p>\n3. Test skalowalno\u015bci horyzontalnej \u2013 dodaj w\u0119z\u0142y i mierz efektywno\u015b\u0107<\/h2>\n
\n
\nStartup SaaS: aplikacja do zarz\u0105dzania projektami. Pr\u00f3bowali skalowa\u0107 horyzontalnie, ale po dodaniu drugiej instancji wydajno\u015b\u0107 wzros\u0142a tylko o 30%. Okaza\u0142o si\u0119, \u017ce wszystkie stany sesji by\u0142y przechowywane w plikach na lokalnym dysku ka\u017cdej instancji \u2013 load balancer by\u0142 zmuszony do kierowania u\u017cytkownik\u00f3w do tej samej instancji, co powodowa\u0142o przeci\u0105\u017cenie jednego w\u0119z\u0142a. Rozwi\u0105zanie: przeniesienie sesji do Redis \u2013 po tym rozwi\u0105zaniu dodanie drugiej instancji da\u0142o prawie 100% wzrost wydajno\u015bci.<\/p>\nPodsumowanie<\/h2>\n
\n