Дмитрий, ну, почему же. fpm, вроде как, не падает. Просто процессы висят, вероятно на коннектах к бд. Пул, как я вижу, позволяет лишь 5 доп процессов, поэтому они быстро кончаются и там уже начинается ругань, мол фпм не работает. Но расширять пул, конечно, не вариант в данном случае. Думаю тут дело в базе, она либо блокируется сама, либо блокирует какие-то важные таблицы и не отпускает. Как себя чувствует база во время выполнения этих запросов? Можно ли к ней подключиться через стандартный клиент например и погонять запросики по таблицам, проверяя, нет ли чего-то зависшего?
Anton Mashletov, ладно, уговорил, к инту все равно надо приводить от греха подальше. И все равно я за empty так же от греха подальше) Я приведу, кто-то не приведет, кто-то даже подготовленные запросы не использует и поместит как есть результат после isset, а у кого-то злой коллега внезапно S_GET меняет по своим правилам еще до него. Да много тут вариантов, без остального кода не скажешь, насколько ему нужно параноить. А я параноик со стажем, потому всегда, когда меня не интересуют отсекаемые empty значения его использую.
Anton Mashletov, ну допустим по isset у него в page может пройти false, 0, пустая строка, пустой массив, и если после isset еще раз не обработать page, то что-то может пойти уже не так.
Anton Mashletov, если нужен 0 как отдельное значение, то вернее не будет. Обычно для страниц 0 приравнивается к пустым значениям и ставится то, которое принято по умолчанию в системе (чаще всего 1) или вовсе игнорируется. В целом empty для проверки значений лучше, чем isset, а нужен 0 или нет в вопросе не сказано.
Дмитрий, я вот что думаю. злой запрос настолько злой, что блокируется существенная часть бд на его выполнение, поэтому при установлении соединений от фпм они просто ожидают окончания блокировки. По статистике видно, что есть высокая нагрузка на дисковый io, получается база там какие-то конкретные непотребства выотряет. Возможно есть какой то способ базу поинспектировать, поведение совсем не здоровое, она как минимум всякие слоу и транзакционные логи заваливать должна.
sinevik, насколько я знаю у коммитов есть только ссылки на своих родителей, то есть по ссылке HEAD и по хешам можно устраивать относительыне переходы через ~number и ^number. Но, у коммитов нет никаких ссылок на своих детей. Наверное единственный способ перейти это вызвать git log и чекаут делать по хешу.
А чтобы увидеть в логе хеши других коммитов (не те, где HEAD) можно сделать к примеру git log master --oneline. То есть получать лог по ветке, где сейчас HEAD.
Так же есть вот такая штучка:
git log --all --graph --oneline
Но при большом количестве коммитов там заблудишься.
Олег, возможно еще в этом плагине найдется нужное тебе. trim spaces, remove spaces in selected например. Думаю только этот плагин без разбора и нужные пробелы в коде удалит, что его попросту сломает.
Олег, можно, наверно, вот тут покопаться, но кажется мне, что это не проще, чем скопипастить в онлайн минифактор. Настраивать вотчеры на отдельыне файлы.
Олег, тогда не знаю, в доках джетов по сути все тоже самое и делается, кусками минифицировать не дает вроде. Мб это связано с тем, что минификация включает не только отсутствие табов с пробелами, но и переименование всего подряд в короткие (но нечитаемые) имена, что может с легкостью нарушить целостность кода, если не миницировать все и сразу. С другой стороны хотя бы через шторм это будет всегда под рукой.
Олег, гугл
Весь топ выдачи - доки jetbrains по этой теме. Вообще если для фронтенда, то обычно этим не шторм занимается, а webpack например.
Вот ссылочка небольная на малую часть того, что вебпак может (минификация коротко там тоже раскрыта): webpack production