Михаил

Купите ssd.

Какое оптимальное количество запросов в БД в yii2?

На этот вопрос нет ответа, все зависит от проекта и его функциональности поэтому никто Вам не скажет конкретную цифру. Чем меньше запросов тем лучше.

И обнаружил что этот самый модуль делает порядка 35 запросов в базу.

Насколько я понимаю к таблицам в которых хранятся RBAC-данные, в таком случае необходимо включить их кэширование

скорее всего идет ленивая загрузка, нужно жадную
https://habrahabr.ru/post/306248/

Какое оптимальное количество запросов в БД в yii2?

46
Вы спросите: "почему 46"? А я отвечу: "а почему бы и нет". Раз уж Вы попросили дать Вам ни чем не обусловленную цифру - пусть это будет 46.

В общей сложности на один action приходится 40 запросов к БД. Скажите, нормально ли это?

Нормально, ведь это меньше, чем 46. А вот можно ли сократить? Это уже другой вопрос, на который могут ответить экстрасенсы, я без кода не могу.

Не много ли для проекта небольшого уровня?

Теперь сложнее. Надо понять что такое "проекта небольшого уровня". Ну раз мы уж начали говорить о вещах не классифицированных - давайте договоримся. Для проекта небольшого уровня - 42. Для среднего - 46, а для большого - 67. Но это только при условии, что

ничего такого глобального из БД не тянется

а если тянется, то вводим "коэффициент глобального тягания" (КГТ 0.3) . Итого 46*0.3 = 13,8 запроса в БД

PS: ограничение по кол-ву запросов для проекта - это глупость. Ваша задача - оптимизировать проект. В процессе оптимизации следует обратить внимание и на количество запросов в БД. И тут мы должны смотреть "а можем ли мы сделать их оптимальнее, сделать их количество меньшим и т.д.", а не подгон под какую-то цифру. Ведь задача - "быстро работает", а не "создает меньше 46 запросов"
Соори за стеб, не хочу обидеть, просто хотел так обозначить. Сам когда-то задавался таким же вопросом.

Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули"

Один из первых модулей, который стоит отключить у Apache'а, для скорости - это поддержку файлов .htaccess, сама эта поддержка производительности не добавляет, а наличие этих файлов - уж и подавно.

1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?

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

2) Поможет ли в такой ситуации FastCGI?

FastCGI - это режим работы PHP, напрямую, на производительность в значительной степени он не влияет, более того, сама логика работы FCGI (если сравнивать Apache-FCGI и Apache-mod_php) будет медленнее, по тому как для взаимодействия FastCGI будет использоваться сокет ("обычный" или unix-сокет), что подразумевает сетевое взаимодействие, вместо непосредственной работы интерпретатора PHP "внутри" сервера. Думаю, Вам поможет несколько другое (постараюсь описать ниже).

3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?

Понятия не имею, почему они не популярны и откуда у Вас такая статистика... Но, возможно, дело в том, что eAccelerator морально и физически устарел, и если верить например, вот такой банальной статье (нет, я не работаю с такой "шедевральной" CMS как "Битрикс", просто это первое упоминание про eAccelerator, которое пришло мне в голову) - с версиями PHP выше 5.3 не работает.

Я знаю, что многие из них заброшены, но это не причина, а следствие.

Не могу прокомментировать это, так как Вы не указали следствие - чего именно. Другими словами, я не совсем понимаю, что Вы хотели этим сказать.

4) Что еще может помочь?

Ну так, сходу, по памяти (варианты могут быть не связаны между собой):
1. Отказ от поддержки .htaccess в Apache или хотя бы сокращение их количества
2. Установка Nginx в качестве фронтального сервера, для отдачи статики
3. Полный отказ от Apache вообще и переход на Nginx+FCGI (только не подумайте, я очень люблю Apache за его гибкость в настройке и широкие возможности, другой вопрос, что мало кому эта гибкость фактически нужна и мало кто способен его грамотно, качественно и полноценно настроить... Nginx в этом плане будет куда попроще). Почему FCGI? По тому, что другой приемлемый способ взаимодействия Nginx'а с PHP мне не известен. Настройка FCGI-пула - обязательна.
4. OpCache - с версии 5.5 встроено "искаропки", к включению и настройке - настоятельно рекомендуется. Я не знаю, как обстоят дела с CMS и используете ли Вы CMS на сайте, но из моей практики, скорость работы PHP-фреймворков возрастает в среднем 8-20 раз.
5. HHVM, как альтернатива
6. Проверка:
а) Того, что дело действительно в PHP. В частности, стоит собрать все логи сервера, например, сколько длились запросы, в БД, их количество и так далее.
б) Проверка скорости работы дисковой подсистемы... Не буду "тыкать пальцем", но одно время я арендовал довольно большое кол-во VPS'ок у одного популярного хостера, и в какой-то момент, я заметил, что средняя скорость работы дисковой подсистемы - 1.4Кбайт/сек., при этом "отказы" (аки "невозможно записать блок") были примерно в 50% случаев... это продлилось не очень долго, но и через несколько месяцев, у этого же хостера, тарифы с "обычным HDD", почему-то обладали более быстрой дисковой подсистемой, нежели тарифы с "быстрыми SSD"... можно сделать выводы...
в) Проверить реальную скорость работы процессора, не редко она отличается от завяленной достаточно сильно.

P.S. Если Вы сформулируете вопрос(ы) более точно - я смогу дать более точные рекомендации, если конечно они Вам нужны :)

P.P.S. Есть вариант решения проблемы вообще "в лоб", самый наверное сложный и пожалуй самый производительный в ряде случаев. Это Varnish + тонкая настройка оного, позволяет выдавать большую часть страниц из кэша (оперативной памяти) за наносекунды, иногда позволяет обслуживать очень много тысяч запросов в минуту, при этом, это не просто кэширование кода или что-то подобное... это кэширование целиком страниц и/или ответов сервера. Среди прочего - позволяет "не трогать бэкенд вообще", т.е. при запросе страницы, может не быть ни обращений к БД, ни выполнения того же PHP (или любого другого) кода, на стороне сервера. Требует довольно тонкой настройки, не очень подходит для сайтов "на CMS", для сайтов на фреймворках - требует изначально корректного подхода к разработке и продумывания того, что и как будет/должно кэшироваться. При некорректном подходе - наиболее вероятный результат - работать будет, но не так быстро как хотелось бы, а часть сайта вообще может перестать нормально функционировать. Есть так же другие решения, но с учётом довольно общих формулировок вопроса - говорить о них довольно сложно.

Ах, да, забыл важную деталь... Почему "хостинги" используют Apache и не откажутся от него (совсем)? В большей степени по тому, что Apache позволяет делегировать часть настроек пользователю через .htaccess. При этом, для статики не редко стоит всё тот же Nginx, который, как Вы понимаете, подобным образом делегировать часть настроек пользователю не позволяет, в виду чего для этих задач не подходит и не "буксует" на этом (в отличии от Apache'а). В т.ч. и по этому, мы на 99% отказались от "хостингов" (по причине наличие Apache'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).

1. Я хватку потерял, в плане позиционирования себя как разработчика.

не исключено

2. В связи с сезонностью. Пора отпусков и т.п.

возможно

3. Тренд React Native. Стоит отметить, что работа на гибридных приложениях есть, включая React Native (хоть и не совсем гибрид)

не думаю, не настолько это и тренд (ПМСМ, естессна)

4. Обилие новоиспеченных iOS разработчиков, которые обвалили рейты.

ну, может, но скорее

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

Git использовать. Для бд миграции, для конфигов .gitignore

Словарь имен, фамилий, названий для слов, которые должны быть с большой буквы всегда. С аббревиатурами все сложнее, так как их овердофига, но тут можно схитрить, причем очень конкретно. Нужен какой-то набор аббревиатур, если проверяемого слова там нет, то стоит проверить по обычному словарю, если оно есть, то это обыкновенное слово, а если нет, то предположить что это аббревиатура. Т.е все неизвестные комбинации букв считать аббревиатурами.

Как можно ускорить этот процесс?

Шаг 1: провести профилирование, найти тормозящий этап. Это может быть получение данных из БД, бэкенд, фронтенд, сеть - что угодно.
Шаг 2: понять, почему конкретно этот этап тормозит.
Шаг 3: внести изменения.
Шаг 4: наслаждаться результатом.

Оптимизация кода методом пристального взгляда (а это единственный доступный посетителям Тостера способ) - дело неэффективное.

А вам никто еще руки не оторвал за такой код? Привыкли, что за вас компиляторы думают?
Например, проверять $a != $b внутри десяти вложенных циклов - это [к сожалению, цензурных слов не нашлось].
Кстати, РНР проверяет условия по порядку, и ставить первым самое тяжелое - это [ну, скажем, саботаж...].

Эм... давайте я отвечу (если не от всех, то хотя бы от лица себя и своих коллег) "битриксойдов" - никак.

Поясню свой ответ: дело не в битриксе, а в подходе. Именно этого и не понимают многие разработчики, которые после Yii, Zend, Symfony и т.д. видят Bitrix.

Во-первых, у продукта (я имею ввиду Битрикс24, и именно продукт, а не CMF/CMS) есть определенная парадигма: User First & Business insight.

User First - это означает, что для реализации базовых вещей, например бизнес-процессы, пользователь с правами администратора должен иметь возможность сделать 80% работы без привлечения разработчика (читать - без привлечения, а я не без опыта/знаний/навыков/образования). Реальность такова, что Вы не сможете за столь короткий срок, сделать ВСЕ ТО ЖЕ САМОЕ, НО ЛУЧШЕ (я не сомневаюсь в Ваших способностях, но одному человеку за измеримые 1-5 лет это практически нереально).

Business Insight - это означает, что в продукте уже заложена логика, а "кривизна результата" зачастую складывается из того, что Бизнес диктует свои условия (Продукт не для всех, но каждый пытается его использовать как хочет и как умеет). Как пример: купив зубную щетку Вы можете чистить ей зубы И/ИЛИ мыть машину, но согласитесь машину мыть неудобнее, но "бизнес решает не тратиться и на имеющуюся щетку нацепить тряпку побольше и ручку подлиннее".

Во-вторых, увы, с этим сталкиваются чаще - кривизна разработчиков. Так как система распространенная, то порог в ее вхождение чуть выше чем в сам язык. Поэтому обилие не сертифицированных, неквалифицированных и необразованных разработчиков очень и очень много. Чтобы "наговнокодить" в том же Symfony нужно сначала понять где это делается, а для этого придется как минимум разобраться как он работает. В битриксе вы можете "говнокодить" почти не разбираясь в нем (я видел сайт, который от битрикса взял только лицензию, ни инфоблоки, ни orm, ничего...)

В-третьих, а давно ли Вы видели битрикс? Сейчас он движется в нужную сторону и, я Вас уверяю, если вы подключите к нему Yii/Silex и т.п., ничего кроме бОльшего "говнокода" Вы не получите. Я не говорю о том, что Вы плохой программист, но что будет после Вас? Вот уволитесь Вы, а это все достанется очередному бедолаге и ему с этим жить.

Желательно понимать, что делают и зачем нужны следующие команды:

git status
git checkout
git reset
git fetch
git pull
git push
git diff
git add
git commit
git stash

Ограничить на сервере количество запросов в час/минуту, особо рьяным отправлять капчу. Все. Вы никогда не узнаете, исполняется на клиенте запрос от живого человека или от бота. csrf, jwt - это не та песня, они созданы, чтобы защитить клиента от постороннего вмешательства, но если клиент сам решит написать бота, вы никак не сможете этому препятствовать.