Gdy m\u00f3wimy o wydajno\u015bci aplikacji, wi\u0119kszo\u015b\u0107 mened\u017cer\u00f3w my\u015bli o czasie \u0142adowania strony czy liczbie zapyta\u0144 na sekund\u0119. Tymczasem prawdziwy problem le\u017cy g\u0142\u0119biej \u2013 w kodzie, kt\u00f3ry dzia\u0142a poprawnie, ale generuje ukryte koszty. Znam startup, kt\u00f3ry przez p\u00f3\u0142 roku p\u0142aci\u0142 za infrastruktur\u0119 chmurow\u0105 40% wi\u0119cej, ni\u017c potrzebowa\u0142, przez jeden nieoptymalny indeks w bazie danych. Nikt tego nie zauwa\u017cy\u0142, bo aplikacja dzia\u0142a\u0142a \u2013 tylko wolniej i dro\u017cej. Jako CTO nie musisz sam pisa\u0107 kodu, ale musisz wiedzie\u0107, jak szuka\u0107 takich problem\u00f3w. Oto pi\u0119\u0107 technik, kt\u00f3re powiniene\u015b zna\u0107.<\/p>\n
Wi\u0119kszo\u015b\u0107 zespo\u0142\u00f3w profiluje aplikacj\u0119 na \u015brodowisku deweloperskim. To b\u0142\u0105d. W produkcji ruch, dane i konfiguracja s\u0105 inne. U\u017cywaj narz\u0119dzi takich jak Blackfire<\/strong> (dla PHP) czy Pyroscope<\/strong> (open source) do ci\u0105g\u0142ego profilowania w produkcji. Pozwalaj\u0105 one zobaczy\u0107, kt\u00f3ra cz\u0119\u015b\u0107 kodu sp\u0119dza najwi\u0119cej czasu na CPU lub IO.<\/p>\n Przyk\u0142ad:<\/strong> Klient skar\u017cy\u0142 si\u0119 na wolne \u0142adowanie dashboardu. Profilowanie ujawni\u0142o, \u017ce 60% czasu zajmuje serializacja JSON-a w jednej bibliotece \u2013 wymiana na szybsz\u0105 skr\u00f3ci\u0142a czas o 70%.<\/p>\n Dla CTO:<\/strong> Wprowad\u017a profilowanie jako standard w pipeline CI\/CD. Je\u015bli nowa wersja zwi\u0119ksza czas odpowiedzi w produkcji o 5%, powinna by\u0107 automatycznie odrzucana.<\/p>\n Narz\u0119dzia APM (np. New Relic, Datadog) pokazuj\u0105 \u015bredni czas odpowiedzi, ale \u015brednia k\u0142amie. W aplikacji webowej 90% u\u017cytkownik\u00f3w mo\u017ce mie\u0107 czas 200 ms, a 10% \u2013 5 sekund. \u015arednia wyniesie wtedy ~680 ms \u2013 wygl\u0105da dobrze, ale tracisz 10% klient\u00f3w. Patrz na percentyle<\/strong>: p50, p95, p99.<\/p>\n Konsekwencje biznesowe:<\/strong> Ka\u017cdy 100 ms op\u00f3\u017anienia na stronie e-commerce mo\u017ce obni\u017cy\u0107 konwersj\u0119 o 1-7% (dane Amazon). Je\u015bli nie \u015bledzisz p95, mo\u017cesz nie wiedzie\u0107, \u017ce tracisz najcenniejszych klient\u00f3w (kt\u00f3rzy cz\u0119sto maj\u0105 najwolniejsze po\u0142\u0105czenia).<\/p>\n Wskaz\u00f3wka:<\/strong> Ustaw alerty na p99. Je\u015bli przekracza 2 sekundy, to sygna\u0142 do interwencji, nawet je\u015bli \u015brednia wygl\u0105da dobrze.<\/p>\n Bazy danych to najcz\u0119stszy winowajca spadku wydajno\u015bci. Ale zamiast \u015bledzi\u0107 przeci\u0119tn\u0105 liczb\u0119 zapyta\u0144, \u015bled\u017a koszt zapyta\u0144<\/strong> \u2013 czas ich wykonania, liczb\u0119 odczytanych wierszy i u\u017cycie indeks\u00f3w. Narz\u0119dzia jak pgstat<\/em>statements<\/strong> (dla PostgreSQL) czy performance_schema<\/strong> (MySQL) pozwalaj\u0105 na identyfikacj\u0119 zapyta\u0144, kt\u00f3re wykonuj\u0105 si\u0119 d\u0142ugo i cz\u0119sto.<\/p>\n Praktyczny trick:<\/strong> Wprowad\u017a limit czasu wykonania zapytania w aplikacji (np. 100 ms). Je\u015bli zapytanie go przekracza, loguj do osobnej tabeli z pe\u0142nym kontekstem (URL, u\u017cytkownik). To szybsze ni\u017c analiza log\u00f3w po fakcie.<\/p>\n **Case z \u017cycia: Firma z sektora fintech mia\u0142a 3 zapytania, kt\u00f3re odpowiada\u0142y za 80% obci\u0105\u017cenia bazy. Po optymalizacji (dodaniu indeksu i zmianie typu JOIN) czas ich wykonania spad\u0142 z 2 s do 20 ms, a miesi\u0119czny rachunek za baz\u0119 o 30%.<\/p>\n Wi\u0119kszo\u015b\u0107 firm my\u015bli o cache\u2019owaniu jako o jednej warstwie \u2013 Redis czy Memcached. To za ma\u0142o. Powiniene\u015b stosowa\u0107 wielowarstwowy caching:<\/p>\n Przyk\u0142ad:<\/strong> Aplikacja do zarz\u0105dzania projektami mia\u0142a stron\u0119 listy zada\u0144, kt\u00f3ra generowa\u0142a si\u0119 5 sekund. Po dodaniu Redis do cache\u2019owania wynik\u00f3w zapyta\u0144 oraz Edge Cache dla stron niezalogowanych czas spad\u0142 do 200 ms.<\/p>\n Dla CTO:<\/strong> Popro\u015b zesp\u00f3\u0142 o diagram przep\u0142ywu cache\u2019owania w aplikacji. Je\u015bli nie istnieje \u2013 to znak, \u017ce optymalizacja jest chaotyczna.<\/p>\n Nowoczesne aplikacje cz\u0119sto korzystaj\u0105 z kolejek (RabbitMQ, Kafka) do asynchronicznego przetwarzania. Wydajno\u015b\u0107 mierzona jako czas obs\u0142ugi \u017c\u0105dania mo\u017ce by\u0107 dobra, ale je\u015bli zadania w kolejkach czekaj\u0105 d\u0142ugo, u\u017cytkownicy nie otrzymuj\u0105 rezultat\u00f3w na czas (np. e-mail z potwierdzeniem zam\u00f3wienia po 20 minutach).<\/p>\n Jak to debugowa\u0107:<\/strong> Monitoruj g\u0142\u0119boko\u015b\u0107 kolejek i czas oczekiwania. U\u017cyj narz\u0119dzi do \u015bledzenia rozk\u0142adu czas\u00f3w. Gdy widzisz, \u017ce najd\u0142u\u017csze zadania czekaj\u0105 najd\u0142u\u017cej, to objaw problemu z priorytetyzacj\u0105.<\/p>\n Konsekwencje:<\/strong> W e-commerce op\u00f3\u017anienie w wysy\u0142ce potwierdze\u0144 mo\u017ce prowadzi\u0107 do porzuce\u0144 koszyka (klient my\u015bli, \u017ce zam\u00f3wienie nie przesz\u0142o). W SaaS \u2013 do utraty zaufania.<\/p>\n Wskaz\u00f3wka:<\/strong> Wprowad\u017a mechanizm \u201etime-to-first-action\u201d \u2013 czas od momentu umieszczenia zadania w kolejce do rozpocz\u0119cia jego przetwarzania. Je\u015bli jest wi\u0119kszy ni\u017c 1 sekunda, optymalizuj konsument\u00f3w.<\/p>\n Debugowanie wydajno\u015bci nie jest jednorazowym zadaniem. To proces, kt\u00f3ry wymaga odpowiednich narz\u0119dzi, metryk i kultury. Jako CTO mo\u017cesz nie zna\u0107 ka\u017cdej linii kodu, ale mo\u017cesz wymaga\u0107 od zespo\u0142u, aby:<\/p>\n Pami\u0119taj: ka\u017cda zaoszcz\u0119dzona milisekunda to pieni\u0105dze \u2013 dla Ciebie (mniejsze koszty infra) i dla Twoich klient\u00f3w (lepsze do\u015bwiadczenia). Zacznij od jednej techniki, wdro\u017c j\u0105, a efekty zobaczysz w ci\u0105gu miesi\u0105ca. Je\u015bli potrzebujesz pomocy w implementacji \u2013 w JurskiTech pomagamy firmom w optymalizacji wydajno\u015bci od podstaw.<\/p>\n","protected":false},"excerpt":{"rendered":" Wst\u0119p: Wydajno\u015b\u0107 to nie tylko szybko\u015b\u0107 Gdy m\u00f3wimy o wydajno\u015bci aplikacji, wi\u0119kszo\u015b\u0107 mened\u017cer\u00f3w my\u015bli o czasie \u0142adowania strony czy liczbie zapyta\u0144 na sekund\u0119. Tymczasem prawdziwy problem le\u017cy g\u0142\u0119biej \u2013 w kodzie, kt\u00f3ry dzia\u0142a poprawnie, ale generuje ukryte koszty. Znam startup, kt\u00f3ry przez p\u00f3\u0142 roku p\u0142aci\u0142 za infrastruktur\u0119 chmurow\u0105 40% wi\u0119cej, ni\u017c potrzebowa\u0142, przez jeden nieoptymalny<\/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":[475,1003,539,530],"class_list":["post-2599","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-cto","tag-debugowanie-wydajnosci","tag-optymalizacja-aplikacji","tag-wydajnosc-backendu"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2599","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=2599"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2599\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2599"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2599"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2599"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. APM i rozk\u0142ad percentyli<\/h2>\n
3. Logowanie koszt\u00f3w zapyta\u0144<\/h2>\n
4. Caching \u2013 nie tylko pami\u0119\u0107 podr\u0119czna<\/h2>\n
\n
5. Monitorowanie czasu sp\u0119dzonego w kolejkach<\/h2>\n
Podsumowanie: Wydajno\u015b\u0107 to ci\u0105g\u0142y proces<\/h2>\n
\n