Если подходить глобально, то:
1. Нужны ресурсы с запасом (мощный сервер под мастер).
2. Избавиться от костылей прошлых лет в коде.
3. Делать это через очереди, и тут опять упираемся в ресурсы.

Но проблема в продуктовой команде, где никто не даст времени на столь глобальные изменения. Плюс к тому не всегда получается договорится с девопсами.

По этому имеет то что имеем и костыль в виде локов.

@vudaltsov приходи к нам лидом на недельку, может получится убедить в использовании правильных инструментов

Профилируй и устраняй узкие места. Нагрузка уменьшится.

А чем профилируете?

tideways

Много чем, зависит от проекта, команды и используемых технологий, а также от того, известно ли что тормозит - БД или бэкенд.

На прошлой работе использовали NewRelic, он так себе, много чего не показывает. Для собственных проектов настроил Pinba + Grafana.

Если проблема в БД, то надо искать тяжёлые запросы (включать slow query log), а также смотреть их частоту. Так как даже быстрые запросы могут тормозить, если их очень много.

Очень часто бывает, что выполняется много лишних запросов из-за косяков проектирования. Или например выгружаются все колонки, когда достаточно одной-двух.

В баду используют liveprof, я так понимаю его тяжелее установить чем Pinba, но если осилить установку, то он очень классно должен в профилировании помочь. Так как умеет строить flame graph )

Зачем работать с людьми, которых надо убеждать в том, что 2+2=4 ?

где-то не так?)

Точнее выражайте мысль. Что «не так»?

в любой конторе найдется неадекват, занимающий важную должность.

Нет. Не в любой.

ну а кто адекват а кто нет - сугубо субъективная штука...

В моей такой только один - я сам ))

тоже вариант)

Ну если человек flock для бд придумывает, это объективная неадекватность ))

Проблемы вообще могут быть самые разнообразные, например:
1. Тяжёлые запросы в БД (не используются индексы либо неоптимально построен запрос)
2. Много лишних запросов в БД
3. БД не тянет такое количество одновременных подключений
4. Есть обращения на внешние API, которые блочат потоки PHP
5. Много файловых операций
6. Плохая связь между серверами (например между бэкендом и БД)
7. Тупит кеш, не справляется с нагрузкой
8. Некорректное использование блокировок
9. Тормозят PHP-сессии
10. Нагрузку не теянет сам веб-сервер (имеется в виду Nginx, Apache)
11. Подклинивает одно из хранилищ (БД, Redis, MongoDB, Memcache)
12. Код выполняет не то что должен

так делать нельзя, но не неадекватность а скорее неопытность и бессилие

Этим нужно переболеть... Заткнуть проблему технологией, это любимая привычка технаря.