Comments 11
Если честно, я два раза читал в заголовке "большие", и только на третий увидел, что речь про "небольшие" приложения. И как-то картинка резко поменялась.
Меня все время что-то смущало в этом тексте, но я не мог понять — что. И вот это несоответствие (называть распараллеленную на 10 серверов систему "небольшой" — это скромность, граничащая и идиотизмом троллингом) прямо щёлкнуло. Я понял, что в этом тексте не так: в нем перемешаны советы из, вроде бы, личного опыта, с очевидными байками "из интернета". И начала закрадываться мысль, что всё это написано нашим модным другом, Птицей-говоруном, которая отличается умом и сообразительностью, но находится в сложных отношениях с объективной реальностью.
- Постоянные соединения для небольших приложений? Последняя, я бы сказал, вещь, которая им требуется. Особенно учитывая, что подавляющее число небольших приложений используют php/mysql, где от пконнекта больше вреда чем пользы.
- непонятно, как использование редиса для сессий и кэша относится к использованию реплик. Кэш — это не реплика.
- Кэшируем простые выбираемые данные из базы — возможно, я не работал с "небольшими" приложениями, но выглядит как решение проблему ХУ: неправильную конфигурацию БД исправляем кэшированием. При этом логика выглядит, как всегда в таких случаях, опосредованной: не " БД долго выполняетпростые запросы", а "если кончаются коннекты, то БД долго выполняет запросы". А у таракана уши в ногах.
- Кэшируем всё. Я думаю, что любой разработчик в свое время приходил к этой идее "ну мы будем инвалидировать после изменения в админке". И сталкивался с суровой реальностью.
- Использование реплик (слейв-БД) с весами. Тут прямо всё прекрасно. "настраиваем несколько коннектов" — ха, так вот куда делись коннекты из пункта "кэшируем простые запросы!". Причем внятного объяснения так и нет — зачем открывать несколько соединений, если по максимуму нужно два, на чтение и на запись. Как нет и объяснения про сами "веса". И почему слейвы должны иметь ту же мощность, что и мастер, учитывая многочисленные решения по проксированию и кластеризации.
- Используйте память сервера как более быстрый кэш: какой-то совет из прошлого века, который выглядит больше как рекомендация ИИ, взятая из воздуха, чем реальный юзкейс.
- Переходим на другую модель работы интерпретатора. Вот тоже, для "небольших" приложений, да.
И при этом в статье ни слова про опкод кэш и способы его оптимизации, прелоадинг. С одной стороны я понимаю, что статья "общая", но с другой она зачем-то ведь размещена из всех языковых хабов только в РНР?
preload даёт максимум 10% ускорения бутстрепа - в моих тестах подтвердилось. opcache включён по умолчанию. Как вначале и писал, не хочу повторяться с сотней других мануалов по ускорению.
А теперь по пунктам:
Особенно учитывая, что подавляющее число небольших приложений используют php/mysql Не знаю что там с mysql, но с postgres - обязательная настройка, позволяющая под нагрузкой держать стабильное околонулевое время соединения с пулером/бд.
непонятно, как использование редиса для сессий и кэша относится к использованию реплик Шардирование данных между разными редисами позволяет не нагружать один редис, что негативно скажется на его производительности. А реплики - это про БД в основном. Видимо, объединение шардирования и репликации в одном блоке вводит в заблуждение.
если кончаются коннекты, то БД долго выполняет запросы. Всё верно. Именно с этим мы и боремся. Открывать по 2к коннектов к postgres - зачем? если можно иметь в четыре раза меньше и выбирать из них только важную связанную информацию, а простые строки выбирать из кэша (что быстрее чем БД и не занимает коннекты).
Кэшируем всё. Я думаю, что любой разработчик в свое время приходил к этой идее Сталкивался каждый. И приходилось выбирать: важнее актуальность или быстродействие. Совсем уж важные данные можно вытягивать без кэша либо с очень небольшим временем жизни, а всё остальное - можно кэшировать.
Причем внятного объяснения так и нет — зачем открывать несколько соединений, если по максимуму нужно два, на чтение и на запись У нас как раз два и открывается - одно к мастеру на запись и ~30% чтения и один к случайной реплике для чтения остальных данных. Зря я использовал "несколько", видимо, тоже вводит в заблуждение. Причём оба идут через один и тот же пулер, и поэтому 3.6k воркеров php используют всего ~520 коннектов до мастера и 280 коннектов до каждой из реплик (на данный момент их 2). А до кэширования простых записей из БД все коннекты к БД утилизировались и пришлось бы уменьшать work_mem postgres чтобы увеличить кол-во max_connections. А зачем, если можно не тратить время БД на то, чем может заняться кэш (просто выдать данные по ключу)?
Используйте память сервера как более быстрый кэш: какой-то совет из прошлого века, который выглядит больше как рекомендация ИИ Зря вы так категорично. Около полугигабайта некритичного к актуальности кэша (которые опять же, выбрали раз в 5 минут из БД, сагрегировали и положили) на каждой из нод приложения очень хорошо хранятся: и не требуют сети для передачи, и очищаются при редеплое, и выбираются очень быстро. Что там "прошловекового" я так и не понял.
Если вас так сильно зацепило "небольшие", то да - это проблема. Заменю на "средний". Я исхожу из того, что несколько серверов - это вполне себе обычный бэкэнд: парочка для бд, штук 5 для приложения, ещё для кэша и s3.
Большинство советов применимы к любому backend, но в огород java/go - я не лезу, не любят они этого.
У меня как-то "вполне себе обычный бэкэнд" на 10 серверов что-то тоже плохо в голове укладывается... Чисто для примера, интернет-магазин с посещаемостью 500 уников в сутки вы бы на бэкэнд из скольки серверов сориентировали?
ВПС с 1 ядром и гигом памяти
Спасибо, конечно, но вопрос был адресован @wapmorgan :)
Немного ресурсов. Выделил бы 1 машину с 4 ядрами и 4гб минимум.
500 уников - это примерно в 100 раз меньше чем dau бэкэнда, на основе которого написаны рекомендации.
Назовём его бэкэнд больших размеров [для php] и средних размеров [для backend'а в целом].
Назовём его бэкэнд больших размеров [для php]
У вас какое-то странное предубеждение против РНР, причем непонятно, на чем основанное. Зачем вы тогда пишете в этот хаб, если не любите и не знаете этот язык? Ну, то есть, вы и в целом попали пальцем в небо — и это можно понять — но при зачем-то решили ещё походя пнуть РНР — и здесь я просто теряюсь в догадках.
500 уников — это фактически отсутствие трафика. Я, кстати, тоже погорячился, там и одного ядра много, как и гига памяти — они будут все время простаивать. Тут хватит даже шаред хостинга, причем с использованием любой технологии, хоть питон, хоть нода, хоть нет. Причем даже с учетом кривого софта — именно под такой трафик писались всякие вордпрессы и битриксы.
Но меня интригует почему вам вдруг именно РНР не угодил. :) "Большой для РНР", сириозли? :)
большой для php потому что на php исторически не пишут нагруженные бэкэнды. Ну вот так сложилось, это не моя выдумка.
Давайте не буду выделять тут стэк, просто назову бэкэнд с dau 50k средним бэкэндом. Можно? Вы не против?
С чего вы взяли что не люблю или не знаю?) баг в ext-zlib исправил, парочку opensource-библиотек веду, пишу ещё со времён php 5.3.
большой для php потому что на php исторически не пишут нагруженные бэкэнды. Ну вот так сложилось, это не моя выдумка.
Выдумка, да еще и не ваша... а зачем?
Судя по тому, что вы раздуваетесь от гордости за свои 50к, с действительно серьёзной нагрузкой вы не сталкивались. Но зачем-то беретесь про неё рассуждать. Не очень, правда, понятно, почему вдруг зациклились на языке бэкенда, при том что все эти DAU в конечном счете упираются в БД, а язык особой роли не играет.
Но в любом случае, спасибо что открыли нам глаза. Теперь будем знать, что vimeo, lamoda, всякие duolingo, skyeng, mamba та же пресловутая — это либо "небольшие" проекты, либо написаны не на РНР. А на языке эльфов, наверное.
Я посмотрел ваши репозитории, вроде бы толковые. И теперь ещё больше теряюсь в догадках, чем вам РНР не угодил. Может быть, дело в том, что именно ваш код не тянет большую нагрузку? И у вас получается такая ошибка выжившего наоборот? "Если меня дельфины толкали к берегу, значит они всех толкают. Если мой код тормозит, значит любой РНР код тормозит". На мой взгляд, вполне логичное объяснение.
Несколько обычных и не очень способов оптимизации производительности serverside-приложений