Нещодавно один відомий консультант по перформенсу рельс написав твіт, де стверджував що більшість Rails апок тримають 1.5 req/sec на одному ядрі й тому треба мільйони vCPU, пам'яті та серверів, щоб воно хоч якось працювало.
Надзвичайно контроверсійна заява яка породила відповідну реакцію спільноти, де різні люди заявляли що в них все працює як мінімум в 10 разів швидше.
Згодом по треду виявилося, що 1.5 req/sec це те що автор бачить на своїх консалтингових проєктах. Тобто не всі проєкти, а ті, куди його запрошують (очевидно, з перформенс проблемами). І не нормально написані проєкти, а нездало написані. І основна проблема не в повільному Ruby, а в I/O до бази. Короче як в тому анекдоті, «— Чули Рабінович виграв мільйон у лотерею? — Все так, тільки не Рабінович, а Петренко, не мільйон, а тисячу, не в лотерею, а в карти, і не виграв, а програв».
Я звичайно крінжанув з поста, потім крінжанув що люди ганьблять Ruby, потім пішов дивитися скільки ж тримає сайт https://donate1024.org/
Поставив модну зараз програму oha, запустив у 20 потоків на 30 секунд: oha -c 20 -z 30s -m GET --latency-correction --disable-keepalive --redirect 0 https://donate1024.org/ і отримав наступний результат:
Summary:
Success rate: 100.00%
Total: 30.0017 secs
Slowest: 18.8368 secs
Fastest: 0.2681 secs
Average: 1.1295 secs
Requests/sec: 9.7328
Total data: 2.68 MiB
Size/request: 10.11 KiB
Size/sec: 91.64 KiB
Response time distribution:
10.00% in 0.4612 secs
25.00% in 0.5410 secs
50.00% in 0.6348 secs
75.00% in 1.0161 secs
90.00% in 1.9351 secs
95.00% in 2.4722 secs
99.00% in 16.0569 secs
99.90% in 18.8368 secs
99.99% in 18.8368 secs
~10 req/sec на одному ядрі з ±нормальним p95, бо сервер в мене найдешевший: shared-cpu-1x@512MB
Ця сторінка звісно не рендерить нічого такого, але десяток запитів в базу і яка-не яка логіка присутня. Звісно всі запити оптимізовані по максимуму, але все ж.
Маю гіпотезу, що більшість часу що витрачається, це не Ruby, а I/O в базу. Тобто якби сюди запулити джаву, то результат був би не набагато кращим, бо код аплікейшена це десятки мілісекунд, стислися б вони у два рази, в загальній частці це не дало б суттєвого прискорення. Щоб перевірити, може знайду час написати два ідентичних сервери на Ruby та Java і порівняти.
І це я просто написав нормальний код. Простору для оптимізацій ще багато: додати кешування, оптимізувати рендерінг HTML (замінити стандартний шаблонізатор ERB на Phlex). Якщо запаритися, то гадаю, що вдалося б покращити результат вдвічі.
Я ж зупинився на тому, що в мене сторінка віддається за 300 мс.
Тому сміливо пишемо на тому, що подобається, оптимізуємо дані та SQL запити, а всім хейтерам які заявляють про тормознутість вашого рантайму у порівнянні з джавою/растом/го сміливо плюємо в обличчя ставимо реакцію клоуна.
P.S.: я звичайно не метр перформенсу, але ще 4 роки тому писав про те що корені всіх проблем веб апок — це запити в базу даних.
P.P.S.: особливо прискіпливі можуть сходити на TechEmpower Web Framework Benchmarks та подивитися, що Spring не набагато швидший ніж Rails, Laravel та Django повільніші, а виграють не фреймворки, а голі бібліотеки вебсерверів.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred
