Performance by design
В попередньому дописі я зробив маленький сервіс який скриншотить твітер.
Зазвичай все що я пишу на Java то роблю на Spring Boot, через багату та зрозумілу екосистему та відносну швидкість розробки.
Цього разу для загального розвитку взяв vert.x, який заявлений найшвидшим Java-фреймворком згідно з результатами Ultimate Web Frameworks Benchmark.
Мій проєкт складається лише з двох ендпоїнтів — /health для перевірки чи все ок та /api/screenshots власне для скриншотів, тому бойлерплейту було мінімум.
Але що мене відразу вразило, так це те що фреймворк за замовчуванням виставляє таймаути на обробку HTTP-запитів. Якщо час виконання перевищує софт-ліміт, то в лог пишеться повідомлення:
Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 2031 ms, time limit is 2000 ms
Якщо ж час обробки перевищує хард-ліміт, то ліба викидає експешн:
io.vertx.core.VertxException: Thread blocked
at java.base/java.lang.Thread.sleepNanos0(Native Method)
at java.base/java.lang.Thread.sleepNanos(Thread.java:491)
at java.base/java.lang.Thread.sleep(Thread.java:559)
at java.base/java.util.concurrent.TimeUnit.sleep(TimeUnit.java:446)
at me.rozhkov.snapshottr.App.handleScreenshotRequest(App.java:79)
При цьому код продовжує працювати, але експешн буде в логах.
Це чудовий приклад коли швидкодія закладається самим фреймворком та спонукає розробника думати як організувати обробку, щоб вкладатися в ліміти.
Я завжди виступаю за sane defaults, бо в сучасному світі занадто багато опцій, варіантів, прапорців, та перемикачів, щоб конфігурувати то все кожного разу.
Можливо у Spring Boot теж є таке налаштування, але його треба додатково увімкнути. Розробники роблять все на своїх машинах та не задумуються про швидкодію, поки не прийде час стрес-тесту, але тоді вже може бути запізно.
Раніше я вже згадував про автоматичне логування реквестів, SQL-запитів та часу їх виконання у Rails. Вважаю що це має стати стандартом усіх таких бібліотек. Чим прозоріше для нас, розробників, те, що виконується на сервері та скільки часу воно займає, тим більше можливостей писати відразу нормально, а не як-небудь.
Уявіть проходити мільйон співбесід по алгоритмах та системному дизайну, щоб потім влаштуватися у твітер та писати неймовірно тормозний сервіс, який віддає вам твіт цілу вічність, не може відразу завантажити тред, а глибина дом-дерева може позмагатися з глибиною node_modules того недолугого фронтенду який змогли написати олімпіадники. Це абсолютна ганьба та дискредитація інженерного ремесла від тих, хто заявляє найвищі вимоги до наших вмінь. Пруф що твітер можна зробити швидким та нормальним я вже давав — це Nitter.
Пишуть що Premature Optimization is the Root of all Evil, але я з цим не погоджуюсь. Нормально роби — нормально буде, і для цього не треба витрачати надмірно багато часу та зусиль. Просто з початку задайте собі адекватні обмеження та дотримуйтесь їх.
☝️Практична порада
👉Подивіться чи підтримує ваш фреймворк схожу функціональність та увімкніть її.
#інструменти
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot
В попередньому дописі я зробив маленький сервіс який скриншотить твітер.
Зазвичай все що я пишу на Java то роблю на Spring Boot, через багату та зрозумілу екосистему та відносну швидкість розробки.
Цього разу для загального розвитку взяв vert.x, який заявлений найшвидшим Java-фреймворком згідно з результатами Ultimate Web Frameworks Benchmark.
Мій проєкт складається лише з двох ендпоїнтів — /health для перевірки чи все ок та /api/screenshots власне для скриншотів, тому бойлерплейту було мінімум.
Але що мене відразу вразило, так це те що фреймворк за замовчуванням виставляє таймаути на обробку HTTP-запитів. Якщо час виконання перевищує софт-ліміт, то в лог пишеться повідомлення:
Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 2031 ms, time limit is 2000 ms
Якщо ж час обробки перевищує хард-ліміт, то ліба викидає експешн:
io.vertx.core.VertxException: Thread blocked
at java.base/java.lang.Thread.sleepNanos0(Native Method)
at java.base/java.lang.Thread.sleepNanos(Thread.java:491)
at java.base/java.lang.Thread.sleep(Thread.java:559)
at java.base/java.util.concurrent.TimeUnit.sleep(TimeUnit.java:446)
at me.rozhkov.snapshottr.App.handleScreenshotRequest(App.java:79)
При цьому код продовжує працювати, але експешн буде в логах.
Це чудовий приклад коли швидкодія закладається самим фреймворком та спонукає розробника думати як організувати обробку, щоб вкладатися в ліміти.
Я завжди виступаю за sane defaults, бо в сучасному світі занадто багато опцій, варіантів, прапорців, та перемикачів, щоб конфігурувати то все кожного разу.
Можливо у Spring Boot теж є таке налаштування, але його треба додатково увімкнути. Розробники роблять все на своїх машинах та не задумуються про швидкодію, поки не прийде час стрес-тесту, але тоді вже може бути запізно.
Раніше я вже згадував про автоматичне логування реквестів, SQL-запитів та часу їх виконання у Rails. Вважаю що це має стати стандартом усіх таких бібліотек. Чим прозоріше для нас, розробників, те, що виконується на сервері та скільки часу воно займає, тим більше можливостей писати відразу нормально, а не як-небудь.
Уявіть проходити мільйон співбесід по алгоритмах та системному дизайну, щоб потім влаштуватися у твітер та писати неймовірно тормозний сервіс, який віддає вам твіт цілу вічність, не може відразу завантажити тред, а глибина дом-дерева може позмагатися з глибиною node_modules того недолугого фронтенду який змогли написати олімпіадники. Це абсолютна ганьба та дискредитація інженерного ремесла від тих, хто заявляє найвищі вимоги до наших вмінь. Пруф що твітер можна зробити швидким та нормальним я вже давав — це Nitter.
Пишуть що Premature Optimization is the Root of all Evil, але я з цим не погоджуюсь. Нормально роби — нормально буде, і для цього не треба витрачати надмірно багато часу та зусиль. Просто з початку задайте собі адекватні обмеження та дотримуйтесь їх.
☝️Практична порада
👉Подивіться чи підтримує ваш фреймворк схожу функціональність та увімкніть її.
#інструменти
permalink | @full_of_hatred
👇Щоденні донати💰на ЗСУ🪖
🫡@Donate1024Bot