Продуктивність проти надійності: чому Java-додатки схожі на боліди F1


Дізнайтесь більше про нові кар'єрні можливості в EchoUA. Цікаві проекти, ринкова оплата, гарний колектив. Надсилайте резюме та приєднуйтеся до нас.

Розповідає Стів Бертон


Ви дотепер вважаєте, що продуктивність і надійність – те саме? Подумайте ще раз

Чи пов’язані продуктивність і надійність (productivity і reliability в оригіналі), або ж це протилежні  поняття? На мій погляд, правильним є другий варіант. У наш час більшість людей в галузі IT вважають, що продуктивність і надійність додатків – це синонімічні поняття, але вони помиляються.

Давайте розглянемо, як команди Формули 1 ставляться до продуктивності й надійності. У попередньому сезоні McLaren Honda були повільними і ненадійними. Ferrari були швидкими в кваліфікаційних заїздах, але ненадійними в основних. Mercedes останні два роки були супер-швидкими і супер-надійними.

Продуктивність

Болід F1 зазвичай оцінюється за трьома показниками: силова установка, тривимірна характеристика двигуна і аеродинамічні характеристики. Тривимірна характеристика двигуна показує рівень споживання ресурсів силовою установкою, а аеродинаміка боліда залежить від того, як поводиться потік повітря при русі авто. Чим вище потужність і чим нижче посадка, тим менше опору, швидше розгін і вище максимальна швидкість. Від притискної сили залежить швидкість і точність входження в повороти.

Продуктивність – той чинник, який визначає час проходження кола болідом. Команди F1 за вихідні можуть випробувати сотні різних конфігурацій в гонитві за частками секунди переваги.

Аналогічно, продуктивність додатків залежить від трьох речей: JVM-середовища (потоків, процесора, пам’яті), логіки додатка і потоку транзакцій. Логіка додатка споживає ресурси JVM-середовища (потоки, пам’ять і т. д.), а потік транзакцій характеризується кількістю переходів за компонентами інфраструктури або сторонніми сервісами.

Продуктивність – це сукупність таймінгу запитів користувачів і розуміння затримок між логічним апаратом додатка та потік транзакцій. Розробники, так само як інженери F1, вносять сотні змін для оптимізації додатка і отримання прибутку. Основним параметром продуктивності є час відгуку, і для його виміру використовуються засоби моніторингу продуктивності додатка (Application Performance Monitoring, APM), такі як AppDynamics, New Relic і Dynatrace.

Надійність

Надійність боліда F1 залежить від якості його компонентів, електронного блоку управління і мільйона дивних даних, параметрів і функцій, що поступають від сенсорів. Варто не врахувати пару параметрів, і машина тут же зупиниться. Минулого року таке двічі відбувалося з одним пілотом, хоча у нього була одна з найшвидших машин.

Надійність – це вміння розрізняти два запитання: чому речі ламаються і чому вони працюють повільно?

З додатками все так само, тільки коли падає додаток, це означає, що десь сталася логічна помилка або згенерувався виняток. Це істотно відрізняється від випадку, коли додаток працює повільно.

Логічний апарат приймає дані, обробляє їх і щось виводить. Як і у болідів перегонів, у додатків є тисячі компонентів (функцій) з мільйонами рядків коду, що обробляють сотні тисяч параметрів (об’єктів і змінних) у кожен момент часу. Продуктивність не має сенсу без надійності. Помилки і винятки “живуть” у логах.

Запитання: Що важливіше: швидкість пошуку авіарейсів або відсутність помилок при резервуванні квитка?

Відповідь: І те, і те однаково важливо для всієї системи, тому займатися треба і тим, і тим.

Помилка при резервуванні квитка

Ласкаво просимо у світ непотрібних даних

Припустимо, що вищезгадані APM-рішення справляються з управлінням продуктивністю. Наша індустрія досі вважає, що лог-файли (чи “big data”, як називають їх деякі) є ключем до розуміння причин падіння додатків. Я б назвав ці дані, м’яко кажучи, непотрібними.

Логам не надають достатньої глибини описів, що приводять осяяння, яке допомагає знайти корінну причину помилки. Звичайно, це краще, ніж нічого, але давайте подивимося, що треба розробникові для того, щоб виявити реальну причину помилки:

  1. Трасування стека додатка – показує, які компоненти додатка були частиною помилки.
  2. Вихідний код додатка – показує, який рядок коду викликав помилку.
  3. Стан додатка – показує параметри додатка, які оброблялися компонентами / вихідним кодом.

Більшість логів містять мільйони повторюваних трасувань стека. Саме тому Splunk (компанія-розробник програмного забезпечення для обробки і аналізу машинно-генерованих даних) коштує $6 млрд, адже робота з кожним трасуванням коштує грошей. Так, розробники можуть кастомізувати лог-файли, поміщаючи в них будь-які дані. Погано те, що не можна поміщати у логи все (через оверхед), а створення осмислених повідомлень про помилки часто передбачає знання того, що в додатку може зламатися.

Без передбачення неможливо створити ефективні лог-файли, тому команди годинами, а то й днями шукають голку в копицi сiна. Відсутність вихідного коду або стану додатка означає, що розробникам доведеться діяти навмання, що погано.

На жаль, трасування стека недостатньо. Все одно, що команда боліда F1 сказала б інженерам: “Телеметрія показала, що кермо машини зламане, але більше ми нічого не знаємо – нумо, швиденько у всьому розібралися і полагодили!”. І що подумають інженери? На жаль, саме в таку ситуацію потрапляють більшість розробників, коли в додатку виникають помилки.

Джерело: Блог Takipi

Київ, Харків, Одеса, Дніпро, Запоріжжя, Кривий Ріг, Вінниця, Херсон, Черкаси, Житомир, Хмельницький, Чернівці, Рівне, Івано-Франківськ, Кременчук, Тернопіль, Луцьк, Ужгород, Кам'янець-Подільський, Стрий - за статистикою саме з цих міст програмісти найбільше переїжджають працювати до Львова. А Ви розглядаєте relocate?


Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *