Imagine that you've been given an old project, a Food Delivery app, with the backend written in Laravel 8 and PHP 8.0. The web and mobile interfaces communicate with the backend through an API, but it's currently performing poorly with an average response time of 600ms. The product owner has requested you to optimize the performance and wonders if it's possible to reduce it by a factor of 10. What would you do? Topics to be Covered: Nginx Cache Rememberable package Redis Cache Queues: Redis/SQS Horizon Octane: Swoole / Roadrunner Upgrading PHP and Laravel While you may be familiar with most of these points and possibly already using them, the focus will be on ensuring that you're using them correctly and effectively. In a real-world example, I will demonstrate how we managed to reduce average response times by 10 times. We'll explore what's hidden under Laravel's package magic and discuss ways to mitigate the negative impact on project performance. By the end of this performance optimization session, you will not only have improved your performance but also gained a deeper understanding of how to utilize the Laravel framework more efficiently.

2. Герасимчук Єгор
Co-founder & CTO
Dotsplatform.com
yehor@dotsplatform.com

3. Герасимчук Єгор
● Co-Founder & CTO @ Dots Platform
● Certified Laravel Developer
● Більше 10 років у розробці
● Автор телеграм каналу ASAP Developer де розповідаю про
продуктову розробку
● Розповідаю про архітектуру і бекенд у своєму ютуб каналі
● Автор і ментор курсів по Laravel та PHP
● У вільний час пишу код для себе, і навіть одного разу став
переможцем UaWebChallenge
3

4. Спойлер:
Сьогодні буде багато слайдів.
Cлайдів з кодом

5. Як оптимізувати сервіс на PHP?

6. Перепишіть все на closure

8. “
Не займаєтесь предчасною
оптимізацією. 80% коду будуть
використовуватись менше 1%
користувачами.

10. Куди витрачається час взагалі?

11. 1. Network & Webserver

12. 1. Network & Webserver
2. Ініціалізація фреймворку

13. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД

14. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД
4. Запити до зовнішніх АПІ

15. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД
4. Запити до зовнішніх АПІ
5. Бізнес логіка

16. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД
4. Запити до зовнішніх АПІ
5. Бізнес логіка
6. Обробка і видача даних

17. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД
4. Запити до зовнішніх АПІ
5. Бізнес логіка
6. Обробка і видача даних
7. Завантаження даних користувачем

18. Типове розподілення часу виконання запиту

19. На що ми можемо вплинути?

20. В теоріі - на все

21. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД
4. Запити до зовнішніх АПІ
5. Бізнес логіка
6. Обробка і видача даних
7. Завантаження даних користувачем

22. Який ідеальний - реальний результат?

24. Як?

25. Хто використовує Nginx?

26. Nginx proxy cache

27. Nginx кешування - це найпростіше і найефективніше
рішення, що можна зробити

28. Nginx
Database
PHP
App
20 ms
40 ms
730 ms

29. Додамо Nginx cache

30. Nginx: 8001
Database
PHP
App
20 ms
40 ms
730 ms
Nginx: 443
Proxy cache

31. Ми закешували всі публічні API запити на 3 хвилини.

33. https://t.me/asapdeveloper/56

34. Результат кешування за допомогою Nginx Cache

36. Типове розподілення часу виконання запиту

37. Найбільше часу займають запити до БД

38. Що можна зробити?

39. 1. Оптимізувати запити
2. Закешувати запити
3. Оптимізувати код (N+1)

40. 1. Оптимізувати запити
2. Закешувати запити
3. Оптимізувати код (N+1)

41. composer require watson/rememberable
https://github.com/dwightwatson/rememberable

47. “
Перший раз - 5 запитів

48. a. 0
b. 1
c. 4
d. 5
А другий?

49. a. 0
b. 1
c. 4
d. 5
А другий?

50. Залежності треба кешувати окремо.

52. В цей раз залежності кешуються.
І буде 0 запитів.

53. Кеш наше все.

54. Але що ще?

56. 1. Network & Webserver
2. Ініціалізація фреймворку
3. Запити до БД
4. Запити до зовнішніх АПІ
5. Бізнес логіка
6. Обробка і видача даних
7. Завантаження даних користувачем

57. Як можна швидко оптимізувати код?

58. Не переписуючи

59. Швидко - OPCache

61. https://medium.com/@edouard.courty/make-your-php-8-apps-twice-as-fast-opcache-jit-8d3542276595

63. Swoole / Roadrunner

64. Laravel Octane
https://laravel.com/docs/10.x/octane

65. Laravel Octane наркотики для
застосунку.

67. Octane завантажує код один раз в
оперативну пам’ять, а потім передає їй
запити на надзвуковій швидкості.

68. Ми прописали 3 строчки коду

69. Конфігурація vapor.yml

73. Але

74. Оскільки код завантажується в пам'ять - всі
класи повинні бути Stateless

75. Не використовуйте
View::share

78. Якщо користувач зайшов на сторінку архіву
компанії - компанія може бути виведена на
сторінці архіву

80. Static instances || Stateful Singletons

84. 2 користувачі з різними куками
account=burgers
account=pizza

85. Можлива ситуація коли користувачеві з
аккаунту burgers покажуться замовлення
аккаунту pizza

86. Тому статичних інстансів краще уникати з
octane.

87. Або робити іх під кожен реквест

90. Ми намагаємося уникати таких класів, але
є те шо є.

92. Це точно вартує результату

95. Що ще можна зробити?

96. Зменшити кількість даних в відповідях

97. Тут все специфічно під проект

99. Так ось, на цій сторінці кожне замовлення
рендерило +40-50Кб тексту

101. 200 Активних замовлень -
10 Мб html

102. Знаю, що ви подумали.

104. Ми зробили 2 речі:
- Оптимізували сам код - найскладніший шлях
- Мінімізували html

107. Зараз 800 активних замовлень на сторінці
займають 5 Мб Html
1 замовлення 5-6 Кб

108. “
Слідкуйте за кількістю даних

110. Що ще?

111. Upgrade PHP & Laravel

114. Навіть консольні команди

116. Але після оновлення
PHP 8.1 -> PHP 8.2
Laravel 9 -> Laravel 10

120. Після апгрейду php 8.2 та laravel 10
приросту по швидкості не отримали, але
швидше фічі робити стали

121. Але це не точно

122. “
Продакт каже: АПІ працює супер швидко.
Замовлення створюються дуже повільно.
Користувач чекає 2-3 секунди. Треба
швидко. Супер швидко. Зробіть, що
небудь.

123. Закатуємо рукава, і дивимся в код

126. Це супер

128. Та взагалі ідеально, де проблема то?

130. Проблема в тому, що ми синхронно
створюємо замовлення. І в нас 100+
запитів до БД

131. Ще запити до внутрішніх сервісі і сторонніх
АПІ.

133. Що робити?

134. Queues

135. Redis/SQS чи що завгодно

138. Використовуйте або повертайте ID(UUID),
замість всієі моделі.

141. “
Продакт: Хлопці, ви красунчики, тепер
користувач відразу бачить, що
замовлення створюється. Але довго
чекає створення .

142. Рознесемо процес створення замовлення
через черги

144. “
Продакт: Це magic. Для користувача все
стало супер. Але що там у вас по
навантаженню після релізу черг?

145. Але щось пішло не так

152. Передаємо тільки id моделей і дані

156. Якщо у вас Laravel, черги на Redis і немає
Laravel Horizon - то я вам заздрю

157. Laravel Horizon - супер потужний
інструмент для моніторингу ваших черг.
https://laravel.com/docs/10.x/horizon

159. Резюме

160. 1. Nginx Proxy Cache
2. Cache DB queries with watson/rememberable
3. Upgrade PHP & Laravel
4. PHP-FPM Opcache
5. Laravel Octane
6. Minimise HTML
7. Queues Relations: ID vs models

161. Звісно це не все, є ще чекліст по перфомансу Laravel. Гарна ідея перевірити,
що у вас все ок!
https://laravel-news.com/performance-checklist

163. https://t.me/asapdeveloper https://youtube.com/@YehorHerasymchuk

164. Герасимчук Єгор
Co-founder & CTO
Dotsplatform.com
yehor@dotsplatform.com