Если производительности "стандартного" пакета к мускулю не достаточно, то можно взять альтернативу: https://github.com/go-mysql-org/go-mysql/. Он не особо совместим с database/sql, но позволяет прокачивать значительно больше запросов через себя за счет минимизации абстракций и аллокаций. Плюс умеет быть не только клиентом, но это уже не по теме поста.
Имхо, очень зря забыли про Ninebot KickScooter MAX G30P. При примерной той же категории, скорости и весе, дает более-менее адекватный запас хода. Ну и качество у Ninebot хорошее.
Мидл способен сделать довольно крупную локальную задачу (скорее всего, по заранее продуманному плану/эпику/архитектуре), но за ним нужно еще довольно много приглядывать и внимательно ревьюить.
В некоторых кампаниях еще применяются карточки НаЛанч (https://nalunch.ru/) с очень похожей на Яндекс системой. Разве что вариантов мест и способов потратиться на еду там очень много.
Для быстрой реакции (переключения) нужен, конечно, резерв, причём горячий. И мощности закладываются так, чтобы фактор репликации учитывался в запасе мощности. Иначе, как вы и привели пример, при отказе и временном росте нагрузки, все может стать ещё хуже.
В случае использования стандартного железа (без подходов вертикального масштабирования), это стоит адекватных денег и окупается примерно после первого сбоя, если сервис критично важен. Но тут, конечно, не могу сказать за всех, проекты бывают разные.
Ну вылетела железка и ладно. Просто берётся запасная.
Даже комментировать это не буду.
Речь про то, что потеря одной (и более) железок вообще не должна сказываться на работе сервиса. Либо время частичного простоя измеряется долями-единицами секунд. Речь про такую систему.
Если в ТЗ есть требования по производительности, то это 1-2 шаги (иначе задача как раз таки еще считается не сделанной корректно).
Например, код должен укладываться в 100мс на 99м перцентиле. Ок. И если он работает за 110мс — это не выполненное задание.
Но после первого релиза можно, при наличии времени, оптимизировать до 50мс, и тем самым немного поднять метрики продукта. (Пример из более-менее реальной жизни).
Закладывание возможности ускорения (как и будущие итерации) я воспринимаю как закладывание возможности дальнейшего развития и доработок. Если код уже написан так плохо, что его уже нельзя поддерживать уже на таких ранних этапах, то тут все плохо, как бы быстро/медленно решение не работало.
А возможность развития — это ведь вообще основополагающее требование к коду (если речь опять же не про «олимпиадное программирование»).
Тоже "по молодости" ставил на performance-first, это казалось крутым. Но это требовало очень точного и зафиксированного описания задачи ("мамой клянусь, не поменяется до релиза ничего").
Вот только в реальной жизни это не так.
Единственное место, где реально такой подход применять, если хочется, — это всякие соревновательные контесты, типа отечественного highload cup или всякие примеры олимпиадного программирования.
В реальной жизни все очень быстро меняется, либо остаётся недосказанность и отсутствие конкретики в неучтенных краевых случаях. А чем больше система (и задание на нее), тем выше шанс не заметить/не учесть что-то.
И, если сразу делать эффективное решение, то потом будет очень больно его переделывать.
Так что много лет уже следую принципу:
Сначала сделать по т.з.;
Потом сделать корректно (тесты, ручные тесты, выдача early bird, и любые другие способы проверить логику и реализацию с обратной связью. Тут может всплыть огромное количество нюансов, которые сразу и правятся);
// Тут может произойти релиз, если нужно минимизировать time-to-market;
Потом сделать быстро там, где есть проблема. А для этого нужны бенчмарки решения целиком, чтобы видеть бутылочные горлышки;
// Вот тут уже релизим, если ещё нет.
В конце 2019 тоже общался с Лавкой. Суммарно 5 часов общения за ~пару недель. 3-4 задачи из этого поста были и у меня Но ещё были встречи про архитектуру и Одна «Сложная» Задача С Тестами, но я бы ту встречу отнес скорее к категории поговорить за жизнь.
что весь функционал обязан опираться исключительно на «invented here» библиотеки
Это больше к используемым нами БД, а не к (K)PHP.
Решения на Go и C/C++ тоже используют в основном «invented here библиотеки», потому что они очень заточены под эффективное решение именно наших задач.
20 минут на тостере и 20 минут на кластере — абсолютно разные вещи (и деньги).
Во первых, речь про весь пайплайн коммита от машины разработчика до работающего сервера в проде, а не только сборка. Обычно, конечно, код выезжает по расписанию, а не вот так вот «побыстрее».
Во вторых, самое медленное тут звено — компилятор C++ (даже в инкрементальном режиме), а далеко не kphp2cpp. Так что это время и железо, на котором gcc будет компилировать N миллионов строк кода. Можно попробовать собрать какие-нибудь проекты типа Chromium на тостере.
Мягко говоря, странно, что против продакшон-билда даже тесты не запустить, и разработки ведутся под значительно отличающиеся среды
Это можно воспринимать как преимущество качества реализации всехз особенностей php внутри kphp. Все настолько хорошо поддержано (либо оперативно правятся найденные corner case), что разработка на обычном php вполне подходит.
А вот руками, или обязательно при пуше, уже гоняются всевозможные тесты.
Так мы получаем и возможность быстрой разработки на php (и минусы языка, конечно), и плюсы kphp в итоге.
Это прямо сейчас, а судя по статье, на протяжении многих лет это было не так.
Про последние годы и речь. Смысл обсуждать что-то старое?
Но суть не в том, а в том, что монолит — показательный продукт той самой культуры, о которой я говорю
Той, что позволила ВК максимально быстро развиваться?
Это очень старая и распространенная дилема: можно или все делать по уму (и с большой вероятностью загнуться до популярности), или быть растущим проектом, который часть ресурсов тратит на техдолг.
Сколько вам понадобится времени, чтобы переписать, допустим, 6-7 миллионов строк продуктовой логики с PHP на тот же Go? Причем этот код постоянно меняется десятками разработчиков, а останавливать проект никто на год-другой не даст.
Тут вариантов остается два: выносить части в отдельные сервисы на произвольном ЯП (и такие работы у нас ведутся, но это оооочень долгий процесс для такой кодовой базы), и замена рантайма используемого ЯП.
Силы небольшой команды, занимающейся KPHP, экономят просто море ресурсов компании, и позволяют идти обоими вышеприведеными путями.
Путем создания целого нового языка, которому нужно еще и обучать?
Говорилось же, что язык максимально похож на обычный PHP уровня 7.3 — 7.4. Разработка вообще сидит на локальных апачах для тестирования нового кода.
Какой у вас там CI/CD медленный и кошмарный я боюсь представить.
Ну да, сборка и деплой на все тысячи серверов может занимать минут 20. Плохо?
А вместо gofmt вот бы сразу `goimports -format-only -w $ FilePath $`, который и форматирует и импорты нормально расставляет.
P.S. Редактор комментов упоролся и не дает вставить FilePath нормально без пробелов. Их там быть не должно.
Настройка хоткеев в плазме - тот еще адок.
Не против, что уж тут такого.
Просто для более полного обзора.
Если производительности "стандартного" пакета к мускулю не достаточно, то можно взять альтернативу: https://github.com/go-mysql-org/go-mysql/. Он не особо совместим с database/sql, но позволяет прокачивать значительно больше запросов через себя за счет минимизации абстракций и аллокаций. Плюс умеет быть не только клиентом, но это уже не по теме поста.
Имхо, очень зря забыли про Ninebot KickScooter MAX G30P. При примерной той же категории, скорости и весе, дает более-менее адекватный запас хода. Ну и качество у Ninebot хорошее.
Надеюсь, что так, а не нашли лазейку.
И тут перекупы.
Как они ограничение в наличие покупок в аккаунте до июня обошли? Или держат аккаунты с единичными покупками на всякий случай?
Мидл способен сделать довольно крупную локальную задачу (скорее всего, по заранее продуманному плану/эпику/архитектуре), но за ним нужно еще довольно много приглядывать и внимательно ревьюить.
В некоторых кампаниях еще применяются карточки НаЛанч (https://nalunch.ru/) с очень похожей на Яндекс системой. Разве что вариантов мест и способов потратиться на еду там очень много.
Для быстрой реакции (переключения) нужен, конечно, резерв, причём горячий. И мощности закладываются так, чтобы фактор репликации учитывался в запасе мощности. Иначе, как вы и привели пример, при отказе и временном росте нагрузки, все может стать ещё хуже.
В случае использования стандартного железа (без подходов вертикального масштабирования), это стоит адекватных денег и окупается примерно после первого сбоя, если сервис критично важен. Но тут, конечно, не могу сказать за всех, проекты бывают разные.
Речь про то, что потеря одной (и более) железок вообще не должна сказываться на работе сервиса. Либо время частичного простоя измеряется долями-единицами секунд. Речь про такую систему.
Например, код должен укладываться в 100мс на 99м перцентиле. Ок. И если он работает за 110мс — это не выполненное задание.
Но после первого релиза можно, при наличии времени, оптимизировать до 50мс, и тем самым немного поднять метрики продукта. (Пример из более-менее реальной жизни).
Закладывание возможности ускорения (как и будущие итерации) я воспринимаю как закладывание возможности дальнейшего развития и доработок. Если код уже написан так плохо, что его уже нельзя поддерживать уже на таких ранних этапах, то тут все плохо, как бы быстро/медленно решение не работало.
А возможность развития — это ведь вообще основополагающее требование к коду (если речь опять же не про «олимпиадное программирование»).
Тоже "по молодости" ставил на performance-first, это казалось крутым. Но это требовало очень точного и зафиксированного описания задачи ("мамой клянусь, не поменяется до релиза ничего").
Вот только в реальной жизни это не так.
Единственное место, где реально такой подход применять, если хочется, — это всякие соревновательные контесты, типа отечественного highload cup или всякие примеры олимпиадного программирования.
В реальной жизни все очень быстро меняется, либо остаётся недосказанность и отсутствие конкретики в неучтенных краевых случаях. А чем больше система (и задание на нее), тем выше шанс не заметить/не учесть что-то.
И, если сразу делать эффективное решение, то потом будет очень больно его переделывать.
Так что много лет уже следую принципу:
// Тут может произойти релиз, если нужно минимизировать time-to-market;
// Вот тут уже релизим, если ещё нет.
Тоже когда-то подобное делал (разве что в формате C extension): https://github.com/AterCattus/unifiedphp/blob/master/README_ru.me
Наверное, это такой своеобразный "hello world", который пишет многие, кто сталкивался с PHP.
С управлением телеком уже не так зашло.
С новой колонкой один вопрос: куда теперь девать старую :)
Это больше к используемым нами БД, а не к (K)PHP.
Решения на Go и C/C++ тоже используют в основном «invented here библиотеки», потому что они очень заточены под эффективное решение именно наших задач.
Во первых, речь про весь пайплайн коммита от машины разработчика до работающего сервера в проде, а не только сборка. Обычно, конечно, код выезжает по расписанию, а не вот так вот «побыстрее».
Во вторых, самое медленное тут звено — компилятор C++ (даже в инкрементальном режиме), а далеко не kphp2cpp. Так что это время и железо, на котором gcc будет компилировать N миллионов строк кода. Можно попробовать собрать какие-нибудь проекты типа Chromium на тостере.
Это можно воспринимать как преимущество качества реализации всехз особенностей php внутри kphp. Все настолько хорошо поддержано (либо оперативно правятся найденные corner case), что разработка на обычном php вполне подходит.
А вот руками, или обязательно при пуше, уже гоняются всевозможные тесты.
Так мы получаем и возможность быстрой разработки на php (и минусы языка, конечно), и плюсы kphp в итоге.
Про последние годы и речь. Смысл обсуждать что-то старое?
Той, что позволила ВК максимально быстро развиваться?
Это очень старая и распространенная дилема: можно или все делать по уму (и с большой вероятностью загнуться до популярности), или быть растущим проектом, который часть ресурсов тратит на техдолг.
Тут вариантов остается два: выносить части в отдельные сервисы на произвольном ЯП (и такие работы у нас ведутся, но это оооочень долгий процесс для такой кодовой базы), и замена рантайма используемого ЯП.
Силы небольшой команды, занимающейся KPHP, экономят просто море ресурсов компании, и позволяют идти обоими вышеприведеными путями.
Говорилось же, что язык максимально похож на обычный PHP уровня 7.3 — 7.4. Разработка вообще сидит на локальных апачах для тестирования нового кода.
Ну да, сборка и деплой на все тысячи серверов может занимать минут 20. Плохо?