Максим Бабичев, это самое наивное решение, конечно, вы правы.
Обычно вложенность ограничена сколькими-то уровнями и можно просто жадно загрузить parent.parent.parent.parent. А можно вообще сделать всё иначе и использовать nested set.
Надо будет глянуть, как их в базу писать, чет сходу не увидел такой опции
Это стандартный функционал фреймворка, который адекватно работает в связке с Horizon, но к самому Horizon не имеет отношения: Dealing With Failed Jobs.
я пришёл к тому, что общее кол-во хэндлеров не должно превышать кол-во процессоров и критичные джобы на отдельные хендлеры.
А этот автоскейлинг сервер не завешивал ни разу?
У нас довольно неравномерная нагрузка на протяжении дня на разные очереди - какие-то ночью запускаются, какие-то только днём. Поэтому нет смысла держать воркеры там, где задач точно не будет. А как задачи появляются, автоматом поднимается нужное количество. Проблем не было пока ни разу, при том, что даже минимальное количество всегда запущенных воркеров превышает (ненамного) количество процессоров. Для каждой очереди максимальное разумное количество процессов указано тоже.
Жаль, что нельзя 0 процессов указать в качестве минимума - есть очереди, которые вообще раз в неделю джобы получают, зато сразу тысячи. Приходится им большую часть времени вхолостую крутиться, но, опять же, никаких проблем от этого я не вижу.
Вы эту инфу могли бы почерпнуть из первого и второго моих комментариев, где ровно это и написано. Больше мне нечего добавить, потому что в вопросе нет важной информации.
Судя по вашему описанию, во втором случае просто используются данные индекса, без обращения к таблице. Соответственно, может помочь составной индекс. А может и не помочь.
Без схемы таблицы, запроса и результата команды explain дальнейшее обсуждение лишено смысла, мой дар провидения уже напряжён до предела.
Планировщику виднее, что делать с индексом с низкой кардинальностью.
0.02 с — это больше похоже на хит в кэш, а не на использование одного конкретного индекса.
А нужна эта настройка для того, чтобы вы могли некоторое число ядер отключить. Считайте, что она называется «использовать не более N ядер».
Добавлять ядра процессору Windows, разумеется, не умеет.
Десять человек уже тут написали — проверять содержимое БД нужно в том же тесте, который данные создаёт. И тогда вопрос очистки или неочистки БД вообще не будет стоять. Arrange, Act, Assert.
Василий Банников, ну так они же не от процесса резолва появились, как в ответе написано, вот я о чём.
Иван Шумов, на всякий случай поясню — по сути вы всё правильно написали, только не очень понятно и некорректно в деталях. Но и первое и второе важно для новичков, поэтому я и полез уточнять, а не чтобы вас как-то принизить.
Давайте, посоветуйте. Что в вашем ответе должно быть мне очевидно?
Когда оказалось, что после «резолва конфликта при мердже» остаются какие-то конструкции, я понял, что ничего очевидного дальше не будет и решил уточнить.
Поясню на всякий случай — резолв как раз подразумевает, что никаких конструкций не осталось, он от них избавляет.
Ну, ладно, я по контексту и последующему комментарию, кажется, понял, что автору предлагается исправить у себя, а потом заслать правку в основную репу. Но то, что это следовало из формулировки «просто сделать pull request где просто не будет» — ни разу не очевидно, тем более для людей, которые со всем этим на «вы».
