Завантаження за мить: вдосконалення швидкості вашого вебсайту [ukr]

Привіт усім! Дякую, що сьогодні всі прийшли. Дуже приємно повертатися в офлайн режим. Велика подяка ЗСУ і всім вам за участь. Давайте сьогодні обговоримо завдання нашого проєкту. Мене звуть Гісем Йожев, і я співпрацюю з компанією МаcРоw в ролі staff engineer. Що таке staff engineer? Ми можемо про це поговорити пізніше. Це не дуже поширене поняття в Україні, де зазвичай використовують терміни "синьйор", "мідл", "техлід" та інші.

Для конструктивної дискусії про те, як прискорити наш проєкт, давайте створимо віртуальний проєкт. Порозмовляємо про його технології та підхід, який ми використали в нашому проєкті. Давайте розглянемо вхідні дані нашого X-проєкту. У нас є система з користувачами, які можуть здійснювати платежі та активувати свої продукти. Далі вони отримують інформацію про продукти та використовують дистриб'юційний склад для продажу.

Розуміємо, що це значною мірою великий проєкт, і не можна просто всю його функціональність розмістити в одному сервісі. Ми обговоримо, чому ми обрали певні технології, такі як PHP для бекенду та SEO-архітектури. Наша база даних - PostgreSQL, а хостинг - Google Cloud. Ми плануємо зрозуміти, як використовувати Google Cloud для оптимізації виконання завдань. Шлях вибору технічних рішень доволі простий: виникає задача, і ми її вирішуємо. Проте важливо розуміти, як це впливає на систему в цілому, як відбувається масштабування, і як це пов'язано з інфраструктурою.

Реальне прискорення роботи наших веб-ресурсів залежить від змін у початковій системі роботи. Нам потрібно переглянути підхід до вирішення завдань, зосереджуючись на їх важливості та взаємозв'язку з системою в цілому. Перейдемо до порядку виконання завдань, де кожен крок обдумується, а не просто виконується. Такий підхід дозволяє нам краще розуміти вимоги та вплив задач на систему. Необхідно уважно вивчити задачу, розглянути її вплив на існуючі структури та визначити, як вона впишеться в загальний контекст.

Зміни у системі повинні бути обгрунтовані та підкріплені планом дій. Це допомагає уникнути конфліктів, покращує масштабованість та забезпечує ефективність виконання завдань. Таким чином, важливо не тільки виконувати завдання, а й розуміти, як вони впливають на систему та як можна покращити їх виконання. Ми створюємо таку довгу, синхронну структуру, щоб показати невелику сторінку. Таким чином, коли ми вже маємо такі проблеми, наш проект дійшов до точки, де уявімо, що у нас є певна сторінка, і її завантаження займає багато часу.

Тоді приходить обурений PM і говорить тобі: "Чувак, тобі треба це виправити. Тепер у тебе є час. Ти не вибираєш його, це обов'язково. Тобто, ти доходиш до точки кипіння, коли PM говорять: "Це проблема, вирішуй її. Бери час, який тобі потрібен. Аналізуй, якщо хочеш. Бери будь-які інструменти, які тобі потрібні, наприклад, купуй дорогий Blackfire і аналізуй ним. Ти можеш і не знати, але ти аналізуєш, взагалі так. Ми починаємо аналізувати проблему. Знову я пропоную вам аналізувати проблему, щоб скласти певний клієнтський шлях. Я не говорю зараз про те, що ми питаємо під час співбесід, але якщо клієнт заходить в браузер, який є його шлях? UI контролери, фронт контролери, індекс PHP і так далі? Ні, я не про це.

Давайте уявимо, як бізнес розмовляє з вами наразі. Нам потрібно уявити, як наші продукти заходять. Як ми працюємо. Так, наприклад, у нас є клієнт. Це фронтенд, отже. Далі є сервер, наш бекенд, типу, якийсь. І є наша база даних, отже, яка зберігає дані. Ну, там не одна, може бути кілька, реплікації. Ну, ти можеш робити все, що хочеш. І коли сторінка завантажується протягом 40 секунд, тебеі питають, де проблема? Ти відповідаєш, можливо тут. Ти кажеш: "Давайте виправимо її". Але ти думаєш: "Ну, подумаємо ще".

І можливо тут. Тобі говорять: "Давай виправимо там. Що нам не вистачає? Інфраструктурної частини? Давайте додамо пул колекцій, розколимо базу даних, зробимо репліки. Ну, що хочеш робити". А ти кажеш: "Можливо тут подумав, що може бекенд написав неправильно". І тобі говорять: "Ні, якщо ти написав бекенд неправильно, то це проблема. Треба її вирішувати". Ти кажеш: "Ну, може бд я взяв не там. Може я щось не так зробив. Денормалізація в мене не вийшла і щось інше". І ти сидиш над проєктом і думаєш: "Ну, у мене все добре. Все добре, я знайду цю проблему".

У принципі, для цього нам потрібно знову визначити допоміжний інструмент. А скільки у нас часу? Визначити інструмент, який допоможе зрозуміти, де є проблема з бекендом. Я пропоную для вас. Ми бачили тільки що слайд, де був клієнт, сервер і база даних. Це проста діаграма. Спробуємо її обробити. Тобто, ми беремо нашу базу даних, і нам потрібно проаналізувати її. Що ми знаємо про нашу базу даних? У нас є можливість використовувати SQL для швидкого пошуку. Круто. Тепер треба йти далі. Що ми можемо зробити? У нас є Google Cloud. О! Це точка контакту. У нас є Google Cloud. Ми можемо вже щось зробити. У нас вже є сервіс, який надає нам багато ресурсів. Я зараз говорю, що ви можете зайти в свій Google Cloud, відкрити його сервіс Google Cloud SQL, і там багато чого подивитися. Ви можете, наприклад, подивитися всі ваші запити до бази даних. Вона не завжди логується. Тому, зрозуміло, якщо ви завжди включаєте лог, то це уповільнює вас. Тобто, далі не треба шукати. Вимикайте його і пробуйте.

Ти починаєш логувати всі свої квері, щоб зрозуміти, як ви взаємодієте з базою даних – оптимально чи не дуже. Хочу відзначити, що на слайді це погано видно, бо тут не можна вивести всі квері через їхню величезність. Проте, це ефективно демонструє, скільки разів квері виконуються і який середній час на кожну. Ти можеш зрозуміти, наприклад, що у тебе є декілька схожих квері, які роблять одне й те саме, але написані різними інженерами. Один використовує індекс, інший – ні. Ти такий: "Ага, отже, у нас вже є проблема з тим, що нам потрібно переглянути наші репозиторії".

У нас є команда з 10 людей, і ти не можеш просто так перевірити всі на Code Review. Ти не можеш розуміти, наприклад, що коли ти створюєш задачу для вибору продуктів клієнта, інша команда не створює задачу для вибору всіх продуктів клієнта. А коли ти робиш merge, ти такий: "В мене все добре, репозиторій схожий, я написав знизу, він написав знизу, я все мержу, і ви робіть однакові квері, просто різними способами написані – ваша проблема". Таким чином, ти починаєш оцінювати свій стек, наприклад, свої квері.

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

Наприклад, мобільний може зберігати токен 30 днів, а у веба – всього лише 1 день. Якщо ти працюєш із рефрешами, то взагалі дякуєш, що вони є. Таким чином, ти оцінюєш ймовірність того, що у тебе є проблеми з сесіями. У нашому випадку, у нас було 2 мільйони клієнтів і 8,5 мільйонів активних сесій через специфіку дистрибуції. Ось перші два кроки, які я пропоную: спочатку ретельно розглянь свої SQL-квері, а потім пройди по своїх репозиторіях, де ти зберігаєш квері. Я сподіваюся, ви використовуєте патерни репозиторіїв. Якщо ні, то знайдіть всі місця, де генеруються ці квері, винесіть їх в одне місце, перепишіть і йдіть далі.

Другий крок – перевір індекси. Часто буває так, що коли ти приходиш в компанію, і дивишся на проект, який працює 10 років, виявляється, що індекси стоять не в тому напрямку. Люди писали, наприклад, що будемо керуватися планом, беремо плани, там є люди, і від них отримуємо різні замовлення, дані про платежі та інше. Пройшло два роки, приходить новий сіньйор і каже: "Ребята, давайте тепер будемо брати все від клієнта в зворотному порядку". Індекси не переставляють, або переставляються неправильно. Таким чином, твій сервіс залишається з тим самим завданням. Наприклад, якщо у тебе є таблиця з трьома полями, і ти робиш індексацію на всі три поля, це добре чи погано? І що далі?

Якщо у тебе є таблиця з трьома полями, і на всі три поля ти навісиш індекси, це добре чи погано? Дякую. От. Так, і ситуація така: тобто, ти маєш проводити рев'ю завжди. Рев'ю твоїх запитів, доктрин, анотацій і іншого. Результат, але щодо індексів - ти можеш подивитися, є система моніторингу твоїх запитів, ти можеш розуміти, коли вони вже відпрацьовані. Так, це те, що на якомусь демо я покажу цей результат, і PM такий, вау, це класно. Тобто, ти розповідаєш про написану апішечку, вони кажуть: "Молодець! А як там на UI покрасили кнопки?" Так, покрасили чотка. От. А тут вони вже хоча б розуміють, що ти зробив. Вони такі: "А, це вже можна щось поміряти". Я вже, як продукт, можу з цим зрозуміти.

Друге питання. Ми знайшли отаку QUERY. Були дуже здивовані. У нас, типу, є CRM, куди треба вивантажити всіх юзерів, наприклад, по 10 людей з пагінацією, розтягнути сторінки і так далі. Ми використовуємо Doctrine Pagination як вбудований. Ми знайшли таку QUERY і думаємо: "Блін, тут все повинно було давно бути написано і працювати нормально". Але отримуємо результат - відпрацьовує 4 секунди на 2 мільйонах клієнтів. Ти думаєш: "Щось я в цьому світі роблю не так". Тобто, навіть просте рев'ю твоїх SQL-запитів може призвести до проблем. Можна взяти EXPLAIN, подивитися всі свої запити і інше. Треба робити це. Але я хочу сказати ще більше. В Google Cloud є інструмент, який вам показує, і ви можете агрегувати результати запитів одразу. Вам не потрібно заходити в production і виконувати EXPLAIN. І подивитися, що там буде. Для деяких це може бути проблемою. Типу, так, у нас є такий інструмент, його можна використовувати і радіти. Ну, типу, це прямо класна штука.

Щодо бази даних, ми повинні розуміти, що перед вашою базою даних завжди є якийсь пулер, такий як pgbouncer для Postgres, наприклад. Якщо ви його не використовуєте, не використовуйте. Але, в цілому, вам треба розуміти, що ваш пулер може вплинути на ваші дані. Стокові конфіги часто не дуже класні, тому визначте свій пулмод. Але вони можуть вам вертати неправильні типи даних, тому будьте обережні. Також, коли працюєте з Doctrine, розумійте, як працює його "магія" і як вона впливає на ваші запити.

От ми встановили там, подивилися, що для нас той пул транзакцій нормальний. Типу, у нас є багато запитів, вони маленькі, і нам не потрібно тримати коннекшн завжди, завжди, типу, довго. Типу, нам добре, типу, відкривати маленький конекшн і відразу його закривати. Ну, цей пул нам підходить. Так ще подивіться на це. У всьому є конфіги. Все, що перед вашою базою даних стоїть, має свої конфіги. Прочитайте про них і вибирайте під свою систему. Я не можу сказати, що є ідеальним, типу, тут вже треба прочитати про всі моди, наприклад, пул конфіги, як pgbouncer.config.poolmod. Прочитайте, що підходить під вашу систему. У нас багато просто малих запитів, ми не обробляємо, наприклад, вкладеності в респонсах у нас немає. Тому ми такі, от, класно, типу, нам підходить транзакційний мод, який, типу, відкривається і закривається, типу.

Ми говорили про базу, так, швиденько, типу, взагалі це такі, знаєте, як просто рекомендації, які вам слід дотримуватись. І якщо ви розробляєте великі проекти, вам слід розуміти, що вам потрібно періодично до них повертатись. Ви не можете, так сказати, я стикався з ситуацією, коли у вас працює довго беклог, ти кажеш: "Так, нам треба подивитися, що у нас з кверями", а йому такий відповідає: "Да, ми чотири роки тому дивилися". І ти такий: "Чотири роки тому". А він відповідає: "Ну, а чого ми кожні чотири роки будемо, так сказати, ревізію робити?" Ти такий: "Ну, в принципі, хоча б, типу, кожні два". І він відповідає: "Ну, це дорого". Ти такий: "Добре, давайте тоді зробимо A/B-тест, як там, наприклад, конверсія вашого стора падає від того, що він завантажується довго. Чи готові люди довго чекати?" Ті, які хочуть в тебе купити, готові. Ті, які не хочуть в тебе купити, такі, просто, йдуть за маркетингом до тебе, ти будеш лодитись 10 секунд, і вони такі: "О, Боже ти, він не працює, цей сайт". Особливо в Україні, після агресії в 2014-му році, коли почали банити російські сайти. Ну, пам'ятаєте, був hubber.ru, і люди заходили на hubber.ru, і у них, так сказати, був довгий лоудінг, а потім вони вибивали, що він заблокований. Це виховало людей і навчило їх, що якщо довго лодиться, значить, так сказати, недоступний сервіс, і вони виходять. Це реально так.

Отже, давайте поговоримо про бекенд. Бекенд, як ми говорили, у нас там PHP, пізніше ми апгрейднулись там, давайте поговоримо про сервіс Symfony. І тут ми розуміємо, що у нас є гроші доступні. Вже до нас прийшов EPM і сказав: "Беріть, що хочете". Я особисто зараз не пропагандую Blackfire, типу, сам, чесно кажучи, на останньому проекті трошки користувався ним. Класно виглядає, все добре, але його налаштування, так сказати, боляче. Особливо, коли ви приходите і маєте Kubernetes, і ви просите ще одну поду, куди я можу вставити Blackfire, і ми будемо з ними взаємодіяти.

І такий опис, може, вам це не потрібно, чому ви не робите це на продакшн, на стейджі, наприклад, зробіть, там, навантажувальне тестування і все інше. Коротше кажучи, якщо, так сказати, їхній логотип, в двох словах - дуже класний інструмент, який допомагає вам перевірити, коли ви маєте складну логіку. Я кажу, що це основне застосування, коли у вас є складна логіка, і ви дуже сильно опираєтеся, скажімо, на якісь процесорні дії, і ви працюєте максимально синхронно, тобто ви не можете нічого викидати в асинхрон, так сказати, і у вас, так сказати, дуже довгі такі, от, команди, які йдуть одна за одною. Тоді це цікавий інструмент.

Особливо вона нам допомагала, коли ми, я вже не пам'ятаю точно рік, почали використовувати Symphony Messenger, і ми такі, вау, давай його використовувати, класна штука, давай. І ми просто жопою по всіх граблях в них проїхалися, просто, а це не працює, а як з rabbit працювати, а коннекшн з rabbit падає, а чому він падає там, а що давай база, а що, типу, у нас там немає моніторинга ніякого з коробки, ну, коротше. Ми прямо проїхались по ньому, і в цьому випадку нам дуже-дуже прямо допомагав, прямо в Blackfire, бо ми там, наприклад, розуміли, що у нас є ребіт, і ми, типу, коли меседж хочемо в нього класти, ми прямо дуже довго чекали, і ми такі, а чому ми довго чекаємо?

А там просто в цей момент ребіт, типу, переголосував, вибрав нового мастера, а той вже відмер, а ти висиш, і він не може зробити реконект, бо він, типу, ще чекає відповіді, тому що у нього там тайм-аут по дефолту 60 секунд. І ти такий, так, у мене, типу, тайм-аут уже в клієнта швидше вискочить, я 60 секунд буду чекати, щоб він зрозумів, що він не може підконектитись і зробити реконект. І ти такий, ага, і в цьому ця тулза прямо дуже допомагає. Ви можете прямо зрозуміти чітко, де у вас, на якому класі, лісенері у вас йде оцей от момент. Ще дуже класний кейс, якщо ви пишете консольні команди, які обробляють дуже багато даних, і вам треба зрозуміти все-таки, де у вас memory leak, в PHP є memory leak, і вам треба його зрозуміти, де він, бо ви не готові, наприклад, ваші воркери ложити після кожної десятої зробленої дії, ви хочете, щоб вони подовше пожили, то що у вас дії, наприклад, якісь там дуже сильно нагружені, там, наприклад, треба чудли напівбази виставити, або там предікшени в якусь IE за систему запушити, то ти маєш зрозуміти, де воно. І це допомагає. Memory leak прямо офігенно відсікає, де воно, він тобі показує, де ти втрачаєш пам'ять, для цієї задачі він прямо максимально підходить.

Далі я рекомендую, після того, як ви могли подивитися на свою логіку, бо про бізнес-логіку я не хочу зараз розказувати там із ряду, ну є ці макрооптимізації, і люди там на конференціях часто ще про макрооптимізацію розказують. Там юзайте тайпи, там і все інше, тоді ми тіпа-бистріше почнемо працювати, а от є PHP функція нативна, яка там відпрацьовує стільки секунд, а от є стільки мілісекунд, там все тіпа, ну то есть для цього там підключити якийсь PHP inspection, який вам буде просто підказувати, бо це для всього тіпа, ну це вже знайомий і просто рефакторить зразу, навіть не задумовитись. Ну це моя суб'єктивна думка. Я би звернув увагу, опять, на конфіги. Конфіги, знову ж таки, багато проєктів, коли ти приходиш, вони в продакшн, коли вони виходять, вони ідуть зі стандартними дефолтними конфігами.

Ну того, що просто часу не хватає. Тіпа, нам треба зробити бета-реліз, всі такі та ми не встигаємо по фічам, та зробіть. Ти просто задеплоїв, такий, тіпа, все, ми виходимо впроти, всі такі, да-да, виходимо впроти, ви виходите впроти, забули конфіги поміняти. Ну типу, ну просто навіть не поміняли їх. Того я би звернув увагу на них в плані, мені здається, після виходу PHP 7.4 це вже стає для нас тіпа, нормою, тіпа, дивитися, тіпа, обкешати наші конфіги, міняти PHP іні конфіги і розуміти, як це бустить систему. Але, типу, якщо ви не дивилися в своєму проєкті, я раджу, тіпа, подивитися в свій проєкт, в конфіги, в PHP іні, і особливо вони отакі штуки. Що би я вам перше, це обкешувати, тіпа, включити його, фашодавн включити йому, ну це такі, меморі налаштувати, тіпа, зрозуміти, скільки ви вижираєте меморі, не давайте йому багато меморі, тіпа, не давайте йому мало меморі і так далі. Далі, екзекюшн тайм зробіть для себе, щоб не чекати 60 секунд.

Я буду прискорюватися, вибачте. Далі у нас є, типу, display_error, ну я не знаю, типу, хтось дивиться в ці помилки, типу, які випадають, типу, для цього мають існувати у вас нормальні моніторингові системи, типу, які це все роблять, виключайте, на мою думку. Validate timestamp, валідувати файли, типу, по їхній зміні. Ну, давайте так, з цим конфігом треба обережно, якщо у вас на сервері можуть мінятися файли вами руками, то так, типу, включайте його. Ну, якщо ви робите redeploy з чистою, типу, тобто, ви чисті ноди, а потім їх підзаміняєте, а це робите, в цьому немає ніякого сенсу. Ну, типу, файл не змінюється, типу, його час буде останній час deploy. Ну, і opcache прилетів, типу, включайте там, вже дивитися від цього, там, Symfony, вип'є, типу, вона сама рекомендує, тож, якщо зайти там Symfony optimization, от всі, там, приблизно половину з цих шагів воно вам розкаже, от, і покаже. Моя думка, знову ж таки, дивіться в конфіги, почитайте про них, тепер є чат GPT, спитайте в нього, наприклад, які конфіги варто, там, наприклад, подивитися. Ну, типу, він теж підказує, там, половину з цього, що я показував. От. І читайте, і змінюйте. Пробуйте, тестуйте точно для себе, це у вас піде.

Щодо проєктів, особливо тих, на які я завітав, і які були розроблені ще 10 років тому, вони мали досить принципову структуру. На той час типовим було витягувати усе відразу відповіддю на фронт. Загалом, коли я тільки починав, в ситуаціях часто зустрічалися такі стеки, як PHP або чистий HTML для рендерингу. Ми спрощували собі життя, створюючи великий масив в кінці контролера і передавали його в шаблон, де вже обробляли все інше. З течією часу, коли з'явилися AJAX-запити, ми зрозуміли, що можемо отримувати дані після завантаження сторінки. Тепер, коли більшість з нас вже не працює над фронтендом, ми розуміємо, що якщо у вас немає GraphQL або подібного, і якщо бекенд в контролері віддає дані з інших сервісів, то це може бути проблемою. Моя особиста думка полягає в тому, що хоча питання про те, чи краще мати великі або багато малих контролерів, є досить обговорюваним, мені особисто здається зручніше працювати з супермаленькими контролерами та легкою логікою, яку може зрозуміти кожен.

Раніше використовувалися так звані сервіси, коли браузер робив послідовні запити для отримання різних частин сторінки. Це призводило до довгого завантаження сторінки. Однак, вирішенням не завжди було кешування, особливо великих проектів. Одне з головних питань при використанні кешу - це інвалідація. Коли користувач щось змінив, вам потрібно оновити кеш. Це може вимагати великої кількості ресурсів і зусиль." Будь ласка, повідомте мені, якщо вам ще щось потрібно виправити або доповнити.

Моя думка - кешування взагалі це дуже добрий інструмент. Але коли ви вже надто активно користуєтеся ним, ваш проект може виглядати приблизно так. Ви сидите, і щось не працює щодо ресурсів, і тут я вже забув про інвалідацію кеша. Я вперто прихильник іншої структури, про яку ми зараз поговоримо. Уявіть наш проект, який ми оглядали в UI. Він виглядатиме приблизно так: інформація з billing, інформація про план, інформація про користувача, інформація про ордер та інше. Ми вже змонтажували сторінку, коли всі ці дані синхронно вибиралися - це просто якась моделька, спочатку рендер, а потім синхронізація.

Користувач вибрав 200 секунд, план 200 секунд, продукт. Інформацію вибирали протягом 500 мілісекунд, інформація про пристрій - 200 секунд, інформація про платіж - 200 секунд, інформація про ордер - 400 мілісекунд. В результаті ми витратили багато часу, і тільки тоді відрендерили сторінку. Ми можемо розпочати це використовувати, ми вже це робили, ми створимо гарну верстку, покажемо її, а потім будемо догружати дані. Але лоудери виглядають не дуже красиво. Що я пропоную?

Замість кешування і для прискорення ваших сервісів використовуйте більше синхронізації. Дуже смішно це звучить, особливо коли ми говоримо про PHP. Може хтось скаже, але в вашому бекенді може нічого не змінитися. Я пропоную вам використовувати гейтвеї. Це дуже гарна практика, використовуйте гейтвеї, наприклад, Node.js, вони вже там просто написані за вас. Ви можете взяти там дві жки, які, наприклад, у нас на фронтенді кажуть: "Хочемо GraphQL". Ми також хочемо GraphQL. Ми не хочемо GraphQL. Але ми хочемо GraphQL. Та, класно з GraphQL.

Ми будемо вибирати мінімальну кількість даних, тільки те, що нам потрібно. Ми все одно вам все повернемо. Але ми хочемо обмежити об'єм вибраних даних. Але ми все одно вам все повернемо. Ні, ми хочемо. Ми все одно вам все повернемо. "Ну добре, візьміть свій гейтвей, використовуйте там GraphQL." Є купа інструментів, які роблять апі для GraphQL, все вже готово. І аналізуйте через Apollo Studio, якщо у вас GraphQL. Це дуже гарна тулза, до речі. Вона дозволяє побудувати багато класних графіків. Прямо 95-й перцентіль, сто-й перцентіль. І це краще не показувати п'яницям, особливо коли у вас є деякі малі відключення. Обираєте за ендпоінтом, дивитеся на завантаження сторінки та інше.

Дуже зручний ідеальний ресурс, особливо для п'яниць, якщо вам потрібно показати, що у вас є проблема. Якщо у вас є GraphQL і вам потрібно показати, що у вас є проблема, місячний триал підписки, ви підписуєтеся на нього на продуктивному сервері і розумієте, де у вас є проблема. Або якщо її немає, і ви такі: "В принципі, немає проблеми, це у мене локально лагає." Так далі і тому подібне. Отже, повертаючись до всіх оптимізацій, які ми вже розглядали, я хочу сказати, що ми з вами пройшли малий процес вдосконалення одного продукту, який зайняв тривалий час. І мій заклик в цій презентації - не просто розповідати про теорію, яку кожен з вас вже знає. Це заклик просто взяти і подумати: "Коли я востаннє переглядав свій PHP-код? Що відбувається на моєму проекті? Як рендериться ця сторінка?

Так от, я хочу сказати, що наш приклад сторінки, яку я показував, виглядає був таким. Ми її завантажували за 3 секунди. З появою шлюзу (gateway), коли у нас було все синхронно, максимальний час завантаження сторінки зараз становить 900 мілісекунд. Все працює дуже швидко, все виглядає дуже класно, і ми дуже задоволені. Зокрема, якщо у вас є SEO-архітектура, вам тепер не потрібно вчити сервіси комунікувати між собою, добирати дані. Ви просто визначаєте якийсь ресурс, за яким ви завжди будете вибирати дані. У нашому випадку це Customer ID. Потім ви завжди вибираєте за цим індексом і стаєте дуже швидкими. Так що це моя історія про оптимізацію - реальний приклад, який призвів одну невідому компанію до значних прибутків. Вони зрозуміли, що вони втрачали багато, коли їх сторінки рендерилися довго.

І коли їхня оптимізація знизилась з 10 секунд до 1 секунди, а навіть менше 1 секунди, ця компанія розуміє теоретично може підняти ще 800 тисяч доларів річно. Тепер невеличкий інтерактив. Я, якщо чесно, трохи проспав сьогодні і, типово, забув про слоника. У мене є симпатичний слоник, і інтерактив полягає в тому, що штучний інтелект генерує багато питань на цю тему, є безліч розповідей про те, як люди оптимізували. Зараз на слайді представлені питання, згенеровані через чат GPT.

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