Залипла минут на 40 там, пока статью готовили))

Витя предусмотрительно предупредил близ седевших, что в рабочее время туда лучше не ходить

Надо было в статье написать warning )

Седевших, господи //_-

Да, там очень легко зависнуть…

Алин, спасибо)

В свете последней статьи интересно услышать отношение баду к использованию готовых/популярных фреймворков/библиотек в среде с высокими нагрузками и о том, как такое отношение сформировалось

Но там же написано, в конце статьи - "объяснялка" отношения Badoo к данным принципам :)

Нам в Badoo близки принципы, про которые рассказывает автор. Главное отличие заключается в том, что ...

Ок, спасибо, не заметил ранее

мы можем и подрбонее рассказать, если что-то более конкретно интересует)

для основного продукта у нас два своих самописных фреймворка: один используется для апи части, другой для «старого веба, не апифицированного». оба очень-очень простые, ничего лишнего, только чистый php и полезная работа :)

в сторонних проектах, не связанных с большими нагрузками недавно использовали ларавель. выбрали по принципу «проще всего взять и с нуля на нем сделать проект»

Там где больших нагрузок нету - понятное дело - на первое место выходят лаконичность, удобство, гибкость и прочие "высокие" стандарты

Вопрос именно в мире хайлода - насколько важны микрооптимизации? Какой перегрев даёт фреймворк?
Наверняка проводились такого рода исследования

Никакой. Всегда есть опкэш и пхп7 и грамотно написанный код и слой данных. Ты можешь сэкономить на спичках, но ты сам себя закопаешь в долгосрочной перспективе если начнёшь делать "вау смотрите зато быстро"

Можно написать супер-оптимизированный код который потом нельзя будет поддерживать )

Ну и по ресурсам – ты будешь жечь время продуктов, впиливая в свой "самописный без всякого лишнего фреймворк" тривиальные вещи

другими словами фреймворк - это не та вещь, с которой стоит начинать оптимизацию и главная его задача - приносить удобство
как в лоулоде, так и в хайлоде. Правильно я понял мысль?

Кому как, основным преимуществом, но в тоже время проблемой фреймворков является их универсальность, как следствие куча лишних абстракций, которые не бесплатны + усложнённый код (в какой-то момент появится необходимость что-то поправить внутри, и без бутылки и такой-то матери это будет не столь тривиально). Более того, общие решения, как правило, в какой-то момент не покрывают моего уникального случая или же выясняется что то же самое можно было бы сделать _проще_ и получить более эффективное решение, но в ущерб универсальности.
И где-то здесь мы придём к пониманию того, что универсальность нужна и полезна в одном случае из 10 (а то и 100), а в остальных она избыточна и стоит денег (железа, человеческих усилий, etc). В случае 1+ серверов - эту проблему можно заткнуть железом. В случае когда кол-во серверов идёт на сотни и более приходится бороться за миллисекунды и лишние вызовы. Привет переписывание большей части условного симфони/ларавеля. Поэтому, как написал выше клин, однозначного ответа тут нет, но выбирая готовый фреймворк, нужно быть готовым к тому, что вместе с ростом проекта придётся переписывать стандартные решения на специализированные, заточенные только под ваши задачи и данные, без оверхеда абстракций созданных ради себя самих (выкинуть орм, и пр)

Максима - любой внешний софт (будь то фреймворк, или база или тарантул или коллеги) - придется разобрать на составляющие, понять и пропатчить

Рано или поздно

Либо выкинуть и написать своё