Опираться только на фактическое число ядер в кластере я бы не стал. Как правило, потоки простаивают на ожидании данных от СУБД, дисковой подсистемы, сети и т.п. При этом ядро вполне успешно может использоваться другим потоком.
Из практики, на сервере 1С с 8 ядрами постоянно работают 30 исполнителей, которые выполняют очень ресурсоемкие для задания. Значение было получено экспериментальным методом. Система в равновесном состоянии — уменьшение количества исполнителей приводит к увеличению времени обработки заданий, увеличение — не уменьшает время.
По количеству исполнителей, простого ответа нет. Ресурс, который станет узким местом при распараллеливании, зависит от прикладного кода внутри заданий и железа (сервер 1С и СУБД). Кроме ресурсов, узким местом могут стать блокировки.
Самый простой способ — провести тесты с разным количеством исполнителей. В качестве отправной точки выбрать значение, которое подсказывает опыт. При этом наблюдать за работой системы и посматривать в журнал регистрации. Заодно можно выявить места для оптимизации.
Полностью согласен. В OpenSource проектах очень даже интересует.
Сразу становится понятно какое количество боли будет вызывать использование той или иной OpenSource библиотеки.
Я правильно понимаю, что это 1С на английском? Очень непривычно.
Интересное у Вас решение по передаче информации между фоновыми. Я в таком направлении даже не думал.
Когда мне нужно между заданиями передать информацию, я использую общее хранилище значений. В качестве идентификатора в хранилище использую ключ задания.
Проблема о которой Вы пишите понятна, она связана с изменением данных.
Так же совершенно справедливо, что не каждый алгоритм можно распараллелить.
Что же касается отчетов и NOLOCK (он же READUNCOMMITTED) — хинт используется для не блокирующего чтения. В момент пока выполняется SELECT тысячи других транзакций могут изменять вычитываемые данные. Если же отказаться от не блокирующего чтения, то получим огромные проблемы с производительностью базы данных.
Консистентность данных, как правило, важна в алгоритмах с пишущими транзакциями. Отчеты же строятся используя запросы с хинтами NOLOCK иначе они будут сильно тормозить работу системы.
Каждый исполнитель — это отдельная сессия и свои транзакции при работе с БД. Чтобы не было проблем с блокировками нужно свести к минимуму общие ресурсы между исполнителями.
Технико-экономическое обоснование нам бизнес предоставляет. Иногда дополнительно интересуемся, какая методика расчета была.
Дело в том, что бизнес-подразделений много и они между собой конкурируют за ИТ ресурс.
Тут уж вопрос, а что вы вкладываете в понятие ответственности?
Есть такое определение:
Ответственность — личностная характеристика человека, описывающая его способность обстоятельно анализировать ситуацию, заранее прогнозировать последствия (весь комплекс следствий) своих действий или бездействий в данной ситуации и делать выбор формы своих поступков с готовностью принять последствия выбора, как неизбежные свершившиеся факты.
Таким образом, ответственность возникает ДО того как что-то было сделано или не сделано. Мы всего лишь хотим, чтобы сотрудники ответственно относились к своим обязанностям и ничего больше.
Задачи менеджера не перекладываются, сотрудник сам принимает решение о том, над какими задачами он будет работать, и ответственность за его своевременное и качественное выполнение.
И объёмы должны быть меньше, потому что аналитика — это тоже работа.
Сотрудник получает карму за любую работу, которую он выполняет.
Ценность в плане отдачи обеспечивается накопленной кармой за месяц. Если человек взявший на себя лидерство не привел к результату, за ним больше не пойдут.
Клан я интерпретировал как команду, не знаю насколько я вас правильно понял. Если сформируется относительно фиксированная и, при этом, эффективная команда, то я не вижу в этом проблемы.
Основная проблематика, освещенная в докладе, заключается в том, что многие сотрудники просто проводят время на работе, мало у кого есть чувство ответственности. Тем более нет командной ответственности, зато есть отговорки, много отговорок. Тут появляются проблемы с эффективностью, качеством, требуется постоянный контроль над сотрудниками. Всех все устраивает, нет желания меняться.
Проблема была та же самая. Думали, что Agile поможет повысить качество и скорость разработки. Не помог. На помощь пришла карма. Забавно, что при этом Agile практики сами как то начали применяться.
Раньше мнение о человеке было на уровне «я не доверяю», сейчас на уровне конкретных цифр. Напомню, что показатели общедоступные.
Кроме того это стало очевидно для всей команды благодаря пришедшему вместе с кармой кросс-тестированию, обзору кода и т.п. Раньше эти методики не принимались и не применялись, сейчас очень даже используются.
Как будет о чем рассказать еще, обязательно напишу.
Количество тестов позволяет предположить, что TDD имеет место быть.
Не берусь утверждать, насколько тру-TDD используется, но количество авто-тестов большое.
Например, «тяжело» разработать UI через тестирование.
Для всего остального вполне себе работает.
Из практики, на сервере 1С с 8 ядрами постоянно работают 30 исполнителей, которые выполняют очень ресурсоемкие для задания. Значение было получено экспериментальным методом. Система в равновесном состоянии — уменьшение количества исполнителей приводит к увеличению времени обработки заданий, увеличение — не уменьшает время.
Самый простой способ — провести тесты с разным количеством исполнителей. В качестве отправной точки выбрать значение, которое подсказывает опыт. При этом наблюдать за работой системы и посматривать в журнал регистрации. Заодно можно выявить места для оптимизации.
Сразу становится понятно какое количество боли будет вызывать использование той или иной OpenSource библиотеки.
Интересное у Вас решение по передаче информации между фоновыми. Я в таком направлении даже не думал.
Когда мне нужно между заданиями передать информацию, я использую общее хранилище значений. В качестве идентификатора в хранилище использую ключ задания.
Так же совершенно справедливо, что не каждый алгоритм можно распараллелить.
Что же касается отчетов и NOLOCK (он же READUNCOMMITTED) — хинт используется для не блокирующего чтения. В момент пока выполняется SELECT тысячи других транзакций могут изменять вычитываемые данные. Если же отказаться от не блокирующего чтения, то получим огромные проблемы с производительностью базы данных.
Дело в том, что бизнес-подразделений много и они между собой конкурируют за ИТ ресурс.
Есть такое определение:
Таким образом, ответственность возникает ДО того как что-то было сделано или не сделано. Мы всего лишь хотим, чтобы сотрудники ответственно относились к своим обязанностям и ничего больше.
Задачи менеджера не перекладываются, сотрудник сам принимает решение о том, над какими задачами он будет работать, и ответственность за его своевременное и качественное выполнение.
Сотрудник получает карму за любую работу, которую он выполняет.
Клан я интерпретировал как команду, не знаю насколько я вас правильно понял. Если сформируется относительно фиксированная и, при этом, эффективная команда, то я не вижу в этом проблемы.
Проблема была та же самая. Думали, что Agile поможет повысить качество и скорость разработки. Не помог. На помощь пришла карма. Забавно, что при этом Agile практики сами как то начали применяться.
Раньше мнение о человеке было на уровне «я не доверяю», сейчас на уровне конкретных цифр. Напомню, что показатели общедоступные.
Кроме того это стало очевидно для всей команды благодаря пришедшему вместе с кармой кросс-тестированию, обзору кода и т.п. Раньше эти методики не принимались и не применялись, сейчас очень даже используются.
Как будет о чем рассказать еще, обязательно напишу.