Будет интересно узнать что вы напишите когда и wd у вас помрёт.
Я десятки SSD netac ставил в сборке, у меня в домашнем ПК стоит 2 тераьайтных nvme под игры и прочее не важное. И пока не одной проблемы не было.
Безусловно это не говорит о качестве, так как условия использования максимально простые. Но то что у вас 2 раза подряд выходили из строя SSD выглядит странно. Возможно есть какие-то особенности в сценарии использования/нагрузке/охлаждении.
NETAC же сами не делают контроллеры и чипы просто собирают из того что есть на рынке, точно так же как и WD.
В тех местах где высокая нагрузка и повышенная ответственность ничего кроме Самсунга не использую, да дорого, но они единственные кто все делает сам.
Мне попадались недорогие nvme от wd это абсолютно такой же Китай на тех же контроллерах и Intel tlc чипах что и китайские, сравнимые по цене.
На мой взгляд как раз умеренным гуманитариям в 1с будет сильно комфортнее чем технарям, особенно с хорошей подготовкой.
Так как в 1с сложно быть чистым разработчиком, нужно вникать в предметную область. А из за отсутствия ООП и как следствие примитивной ide для работы в 1с требуется повышенное внимание, отличная память, развитое воображение, умение читать модули по 10-20 000 строк, держать в голове прочитанное так как логика начинается а форме, потом уходит в модуль с вызовом сервера, потом в модуль сервера, затем вызывает процедуры из модуля повт.исп которые в свою очередь вызывают функции ещё из нескольких модулей и все это для одной функции одной сущности.
Это в java/c# ide подскажет тебе какие методы можно применять к данному типу, где он используется. Плюс сам подход ООП снизит сложность ограничив видимость кода и его количество.
К примеру, в других языках программирования вам придётся вручную описывать все атрибуты классов (то есть их поля), писать скрипты для создания таблиц в базе данных, а потом эту базу данных и обновлять (это называется миграцией). Всё это абсолютно рутинная работа, которая вряд ли принесёт большое удовольствие
Для всех enterprise языков есть фреймворки с ORM которые делают эту работу.
От разработчика требуется только описать классы.
Что касается рутины, а порой и отчаянья то это попытка доработать что то в типовой конфигурации, где вся логика размазана по 10 общим модулям в каждом из которых по 15000 строк.
Разработка/сопровождение крупной системы на языке без ООП в т.ч. 1С (особенно 1с с их подходом к общим модулям где нет иерархии) это как постройка дома из пеноплекса. (На Ютубе есть ребята которые это практикуют и других учат как правильно делать).
Зачем производители роутеров делают возможность отключить OFDMA и MU MIMO если это такие хорошие технологии?
И еще вопрос, если у меня к 2х диапазонному роутеру на 2.4 ГГц подключен десяток устройств (пылесос, алиса и.т.п), а на 5 Ггц гарантированно подключено только одно устройство VR Шлем 132 DFS канал + 80Мгц полоса, при этом рядом стоит еще один роутер в котором включен только 5 ГГц на 48 канале с шириной полосы в 40 Мгц к которому подключены еще ~15 устройств, которые генерят трафик (ТВ, Телефоны).
Проблема это все сопровождать, развивать, масштабировать. У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД. В общем все прелести монолита + отношение 1С к СУБД как набору DBF.
Мы покупаем промышленные СУБД за десятки миллионов что бы использовать их на уровне SELECT + максимально примитивный INSERT весь остальной функционал этих СУБД можно использовать только вопреки и с огромными костылями и сложностями.
Ну вот запросами в "бесшовной интеграции" и реализовано, т.е. часть форм из ДО просто скопировано визуально.
А дальше через WEB сервис запрашивается струкутра данных и полученными данными заполняется копия формы.
В то же время если бы это были системы построенные на современных подходах к разработке, мы бы нативно открывали форму из другой системы в едином интерфейсе, т.е. при изменении на стороне ДО нам не приходилось бы дорабатывать копии форм и структуры данных в библиоткеке бесшовной интеграции, да и сама библиотека была бы не нужна.
Ваш пример с "системой" из нескольких конигураций приводит к тому что пользователь должен переключаться между разными интерфейсами если работает с несколькими решниями. Т.е. в нашем примере:
Работаем в ERP, согласовываем в ДО приводит к тому что нужно переходить в разные приложения. Ну или использовать очень ограниченные костыли в виде копий форм из ДО.
Только через COM и с кучей ограничений и условий. Плюс открытие окна одного приложения в другом это только самая вершина, тут хотя бы аналогию можно провести.
Вы действительно не понимаете разницу между РИБ и микросервисной/сервисной архитектурой?
Вот представьте что у вас в компании развернут сервис по работе с контрагентами, все части вашей системы (договора, документооборот и.т.п) при попытке подбора контрагента обращаются к нему, он хранит в своей собсвтенной базе списки контрагентов, отдает отрендеренную форму контрагента и.т.п.
Если у вас стало так много контрагентов что 1 серверне справляется вы разворачиваете еще один сервер и ставите между ними фасад который определяет на какой сервер отправить запрос (например по коду контрагента).
Т.е. вы вот когда в интернете переходите по ссылкам, вы же понимаете что за каждой ссылкой может стоят своя инфраструктура которая вообще в другой стране расположена, это для вас это цельное приложение.
Самый хороший пример того насколько ущербна 1С это библиотека "бесшовной" интеграции с документооборотом. Суть в том что вы можете процессы согласования отдавать в ДО, а результаты и ход процесса отслеживать в своей конфигурации... Вот только на 1С нельзя сделать ничего лучше чем просто продублировать все формы из ДО в эту библиотеку.
Как бы это работало в нормальном виде?
Просто iframe в который подтягиваются данные из системы согласования с офролемением через css. В 1С это могло бы выглядеть как открытие окна одного приложения в окне другого при том что пользователь не понимал бы что сейчас он видит данные из другной базы.
Я как то был на инфостарт и задавал вопрос Олегу Бартунову, можно ли где то ознакомиться с best practices по эксплуатции крупных монолитных баз от 1 Tb и выше.
На что получил ответ:
" best practices по эксплуатции крупных монолитных баз от 1 Tb заключается в том что бы не создавать крупные монолитные базы от 1 Tb"
И что примерно с 2002 года индустрия уходит от монолитов в сторону сервисов, так как объемы автоматизации а так же данных растут, и держать это все в одной базе бессмысленно, так как разные категории данных имеют разную критичность, разные объемы, разную нагрузку. Не просто так придумали разделение OLAP/OLTP.
Любая система на 1С это жесточайший монлит на всех уровнях от кода до субд.
"Готовы на C# и WinForms написать за неделю простую учетную систему? "
Из пластилина легко слепить детскую игрушку. Но самолет из пластилина сделать тяжело.
Никто не спорит что на 1С низкий порог и быстрая разработка ларьков. Но стране нужно не это, стране нужна автоматизация мега корпораций таких как газпром, почта россии, огромных заводов которые являются городами.
Многие 1С специалисты, и вы в том числе мыслите категориями ИП, когда нужно быстро и дешево. Я вот на ютубе смотрю канал одного человека, он там из Пеноплекса дом строит.
Тоже говорит смотрите как быстро получается, и дешево, и даже тепло.
Я за свою карьеру в 1С (18 лет разработки) построил не мало таких вот "домов" из пеноплекса, и пока ты его строишь всё супер, проблемы начинаются ближе к концу, когда нужно возводить перекрытия, крышу, сантехнику, вешать шкафы и полки и много чего другого...
Но база размером в 30 ГБ еле работала у одного, не говоря уж о 10.
В этом и суть многоядерных серверных процессоров. Они оптимизированы под большую нагрузку, а с маленькой работают плохо.
Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.
В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.
(Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).
Сервер 1С однопоточный, в том плане что один сеанс пользователя / фонового задания - один поток. Самих потоков конечно может быть много так как пользователей у вас много, каждый из них генерирует много задач, но каждая такая задача выполняется исключительно одним ядром (одним потоком в случаее с HT).
Соответственно важна для него производительность на одно ядро (а не частота процессора, так как для разной архитектуры IPC разное).
Самый простой способ сравнить процессоры по этому показателю это CPU-Z
В случае пока количество сеансов <= количеству потоков (с учетом HT) ПК с 12900 будет давать результаты в 2,2 раза лучше (см. примечание) чем сервер с 4216.
По мере увеличения количества сеансов 12900 разрыв в производительности будет падать.
Вы не написали сколько пользователей у вас. Если 300 пользователей, то нужно будет или смириться с меделенной работой сервера или подбирать соответсвующие сервера в кластер (5-7 серверов).
Примечание
Тут и дальше под термином "производительность сервера 1С" я имею в виду время выполнения кода.
Очевидно что в реальной работе, например: "формирование отчета СКД, проведение документа, открытие формы списка и.т.п", Прироста в 2 раза не будет, так как там 98% времени работает СУБД и только 2% работает сервер 1С.
Если до 50 человек то под Сервер 1С лучше взять хорошее десктопное железо (12900/12700, старшие ZEN3).
Мало того что сэкономите на серверах, так еще и за счет огромного L2 (1,25МБ на ядро!) и быстрой памяти процессы 1С будут работать очень быстро. В случае ZEN3 там L2 стандартный но зато L3 - 32Mb. (Не знаю что из этого будет лучше но точно знаю что оба покажут себя хорошо)
Из моего опыта если говорить о стандартной бух то сервер 1С на 12900 без проблем будет держать 60-70 пользователей (с учетом того что они работают не равномерно, если у вас работают операторы потокового ввода по всей стране и генерят нагрузку непрерывно то конечно цифры другие будут).
Как убедить заказчика? Если вы +/- крупный франч купите себе один такой системник, и просто показывайте заказчку разницу.
По другому убеждать людей что ПК за 80к будет лучше справляться с сервером 1С, чем сервер за 800к не реально.
Даже под моим сообщением, уверен, будет не один комментарий по этому поводу :).
Приложение "Сервер 1С" в отличии от СУБД не требует серверного оборудования, отлично масшатабируется по количеству ПК, т.е. если у вас 100 пользователей ставьте 2 системника, 150 ставьте 3 и.т.п. требований к диску каких то особых нет, к надежности тоже, особеено если у вас и так кластер из нескольких системников.
Зато с СУБД вам лучше постараться уместить все на одном сервер так как в случае с 1С вам будет ОЧЕНЬ тяжело масштабировать СУБД добавлением еще одного сервера.
Про отключение ядер
Что касается вашего случая, и других случаев работы Turbo boost то все сводится к TDP. У процессоров 4216 TDP 100W и в зависимости от загрузки эти 100W набираются или 8ю ядрами на 3Ггц или 16ю на 2.9 и.т.п. Зеонщики со стажем (сам 2 года дома сидел на 2673v3) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.
Все что вы описали phyton специалист сделает быстрее и лучше за счёт отличных библиотек по работе с xml и паркингу html. Код будет понятнее.
У меня есть опыт написания html парсера и генератора на 1c и это по уровню где то 99й год, собираем текст из строк и шаблонов, и так же парсер, да что говорить даже регулярок нет.
И у тебя удобные структуры данных для работы, и главное простой и понятный код.
В итоге как показала практика, на долгой дистанции выгоднее сделать на питоне парсер и отдавать результаты в 1с через мни http сервер чем реализовывать и что намного более важно сопровождать и развивать парсер на 1с.
Питон как язык можно выучить за 3 дня. Дальше уже библиотеки и ООП, и этому можно учиться всю жизнь.
Нужны будут только ревьюверы, посмотрите на сему доктора. Там есть тот кто придумывает запросы, есть ai который генерирует код.
И есть там ещё человек который проверяет ответы)))
И да что бы придумать запрос не надо быть программистом, программист нужен что бы ответ проверить и поправить))
На мой взгляд цены на такой гаджет не соответсвуют приносимой пользе.
Я еще когда обычную станцию брал за 4500, были мысли на тему что дороговато для игрушки но условно понятно за что деньги плачу.
Сейчас же смотрю на Станция 2 за 18000, которая по сути моно звук дает, смотрю на миди за 15000 и не понимаю кто будущие покупатели таких устройств.
Еще как то была понятна цена в 12к на прошлую станцию с HDMI считай и колонка и приставка для ТВ.
Я бы еще понял цену в 11к с годовой подпиской, с учетом курса доллара выглядело разумно.
На картинке просто диск что не то же самое что память.
В теории объем диска ограничен только форм фактором (количеством чипов).
В статье же рассказывается о чипах и действительно нет информации о том сколько данных теперь помещается на один чип
Нет хранить будет в tlc но запись всегда быстрая будет как slc.
Контроллер всегда в фоне уплотняет запись.
В принципе при наличии dram буфера это будет очень близко к slc как по чтению так и по записи, так что схема рабочая для тех кто хочет SLC.
Будет интересно узнать что вы напишите когда и wd у вас помрёт.
Я десятки SSD netac ставил в сборке, у меня в домашнем ПК стоит 2 тераьайтных nvme под игры и прочее не важное. И пока не одной проблемы не было.
Безусловно это не говорит о качестве, так как условия использования максимально простые. Но то что у вас 2 раза подряд выходили из строя SSD выглядит странно. Возможно есть какие-то особенности в сценарии использования/нагрузке/охлаждении.
NETAC же сами не делают контроллеры и чипы просто собирают из того что есть на рынке, точно так же как и WD.
В тех местах где высокая нагрузка и повышенная ответственность ничего кроме Самсунга не использую, да дорого, но они единственные кто все делает сам.
Мне попадались недорогие nvme от wd это абсолютно такой же Китай на тех же контроллерах и Intel tlc чипах что и китайские, сравнимые по цене.
На мой взгляд как раз умеренным гуманитариям в 1с будет сильно комфортнее чем технарям, особенно с хорошей подготовкой.
Так как в 1с сложно быть чистым разработчиком, нужно вникать в предметную область. А из за отсутствия ООП и как следствие примитивной ide для работы в 1с требуется повышенное внимание, отличная память, развитое воображение, умение читать модули по 10-20 000 строк, держать в голове прочитанное так как логика начинается а форме, потом уходит в модуль с вызовом сервера, потом в модуль сервера, затем вызывает процедуры из модуля повт.исп которые в свою очередь вызывают функции ещё из нескольких модулей и все это для одной функции одной сущности.
Это в java/c# ide подскажет тебе какие методы можно применять к данному типу, где он используется. Плюс сам подход ООП снизит сложность ограничив видимость кода и его количество.
Для всех enterprise языков есть фреймворки с ORM которые делают эту работу.
От разработчика требуется только описать классы.
Что касается рутины, а порой и отчаянья то это попытка доработать что то в типовой конфигурации, где вся логика размазана по 10 общим модулям в каждом из которых по 15000 строк.
Разработка/сопровождение крупной системы на языке без ООП в т.ч. 1С (особенно 1с с их подходом к общим модулям где нет иерархии) это как постройка дома из пеноплекса. (На Ютубе есть ребята которые это практикуют и других учат как правильно делать).
Понимаю что прошло уже много лет...
Но все же вдруг удастся получить ответ :)
Зачем производители роутеров делают возможность отключить OFDMA и MU MIMO если это такие хорошие технологии?
И еще вопрос, если у меня к 2х диапазонному роутеру на 2.4 ГГц подключен десяток устройств (пылесос, алиса и.т.п), а на 5 Ггц гарантированно подключено только одно устройство VR Шлем 132 DFS канал + 80Мгц полоса, при этом рядом стоит еще один роутер в котором включен только 5 ГГц на 48 канале с шириной полосы в 40 Мгц к которому подключены еще ~15 устройств, которые генерят трафик (ТВ, Телефоны).
Нужно ли в этом включать OFDMA и/или MU MIMO ?
Построить можно что угодно из чего угодно.
Проблема это все сопровождать, развивать, масштабировать. У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД. В общем все прелести монолита + отношение 1С к СУБД как набору DBF.
Мы покупаем промышленные СУБД за десятки миллионов что бы использовать их на уровне SELECT + максимально примитивный INSERT весь остальной функционал этих СУБД можно использовать только вопреки и с огромными костылями и сложностями.
Ну вот запросами в "бесшовной интеграции" и реализовано, т.е. часть форм из ДО просто скопировано визуально.
А дальше через WEB сервис запрашивается струкутра данных и полученными данными заполняется копия формы.
В то же время если бы это были системы построенные на современных подходах к разработке, мы бы нативно открывали форму из другой системы в едином интерфейсе, т.е. при изменении на стороне ДО нам не приходилось бы дорабатывать копии форм и структуры данных в библиоткеке бесшовной интеграции, да и сама библиотека была бы не нужна.
Ваш пример с "системой" из нескольких конигураций приводит к тому что пользователь должен переключаться между разными интерфейсами если работает с несколькими решниями. Т.е. в нашем примере:
Работаем в ERP, согласовываем в ДО приводит к тому что нужно переходить в разные приложения. Ну или использовать очень ограниченные костыли в виде копий форм из ДО.
Только через COM и с кучей ограничений и условий. Плюс открытие окна одного приложения в другом это только самая вершина, тут хотя бы аналогию можно провести.
Вы действительно не понимаете разницу между РИБ и микросервисной/сервисной архитектурой?
Вот представьте что у вас в компании развернут сервис по работе с контрагентами, все части вашей системы (договора, документооборот и.т.п) при попытке подбора контрагента обращаются к нему, он хранит в своей собсвтенной базе списки контрагентов, отдает отрендеренную форму контрагента и.т.п.
Если у вас стало так много контрагентов что 1 серверне справляется вы разворачиваете еще один сервер и ставите между ними фасад который определяет на какой сервер отправить запрос (например по коду контрагента).
Т.е. вы вот когда в интернете переходите по ссылкам, вы же понимаете что за каждой ссылкой может стоят своя инфраструктура которая вообще в другой стране расположена, это для вас это цельное приложение.
Самый хороший пример того насколько ущербна 1С это библиотека "бесшовной" интеграции с документооборотом. Суть в том что вы можете процессы согласования отдавать в ДО, а результаты и ход процесса отслеживать в своей конфигурации... Вот только на 1С нельзя сделать ничего лучше чем просто продублировать все формы из ДО в эту библиотеку.
Как бы это работало в нормальном виде?
Просто iframe в который подтягиваются данные из системы согласования с офролемением через css. В 1С это могло бы выглядеть как открытие окна одного приложения в окне другого при том что пользователь не понимал бы что сейчас он видит данные из другной базы.
Я как то был на инфостарт и задавал вопрос Олегу Бартунову, можно ли где то ознакомиться с best practices по эксплуатции крупных монолитных баз от 1 Tb и выше.
На что получил ответ:
" best practices по эксплуатции крупных монолитных баз от 1 Tb заключается в том что бы не создавать крупные монолитные базы от 1 Tb"
И что примерно с 2002 года индустрия уходит от монолитов в сторону сервисов, так как объемы автоматизации а так же данных растут, и держать это все в одной базе бессмысленно, так как разные категории данных имеют разную критичность, разные объемы, разную нагрузку. Не просто так придумали разделение OLAP/OLTP.
Любая система на 1С это жесточайший монлит на всех уровнях от кода до субд.
"Готовы на C# и WinForms написать за неделю простую учетную систему? "
Из пластилина легко слепить детскую игрушку. Но самолет из пластилина сделать тяжело.
Никто не спорит что на 1С низкий порог и быстрая разработка ларьков. Но стране нужно не это, стране нужна автоматизация мега корпораций таких как газпром, почта россии, огромных заводов которые являются городами.
Многие 1С специалисты, и вы в том числе мыслите категориями ИП, когда нужно быстро и дешево. Я вот на ютубе смотрю канал одного человека, он там из Пеноплекса дом строит.
Тоже говорит смотрите как быстро получается, и дешево, и даже тепло.
Я за свою карьеру в 1С (18 лет разработки) построил не мало таких вот "домов" из пеноплекса, и пока ты его строишь всё супер, проблемы начинаются ближе к концу, когда нужно возводить перекрытия, крышу, сантехнику, вешать шкафы и полки и много чего другого...
Вы вообще не понимаете о чем пишите.
У всех процесоров х86 отдельные кэши на каждое ядро, называются они L2.
У интел (в отличии от ZEN2) как раз L3 общий для всех ядер
Остальное даже комментировать не буду, так как вы все равно не поймете.
Спасибо за инфу, привык что MS SQL использует все до чего дотянется, а с PG только недавно...
Если вы ставите PG под Windows (а по косвенным признкам видно что дело было под Windows) то там может быть вообще что угодно.
В этом и суть многоядерных серверных процессоров. Они оптимизированы под большую нагрузку, а с маленькой работают плохо.
Не важно 1 пользователь у вас или 40, на многоядерном сервере скорость работы будет для них +/- одинаковая.
В случае с малоядерными десктопными ПК скорость работы 80 пользоватеелй будет значительно медленее чем скорость работы 1 пользователя. Но скорость работы 1 пользователя будет значительно выше чем скорость работы 1 пользователя на многоядерном сервере.
(Ну и конечно напомню что мы говорим имеено о севере 1С а не о севере СУБД, потому что для СУБД ситуация более сложная, а если СБУД это PG на Windows то и вообще безвыходная).
Сервер 1С однопоточный, в том плане что один сеанс пользователя / фонового задания - один поток. Самих потоков конечно может быть много так как пользователей у вас много, каждый из них генерирует много задач, но каждая такая задача выполняется исключительно одним ядром (одним потоком в случаее с HT).
Соответственно важна для него производительность на одно ядро (а не частота процессора, так как для разной архитектуры IPC разное).
Самый простой способ сравнить процессоры по этому показателю это CPU-Z
Intel Xeon Silver 4216 - 370/8400 (https://valid.x86.fr/bench/lf3a0q)
Intel Core i9-12900K - 800/11400 (https://valid.x86.fr/bench/9ar1d6)
Intel Core i7-12700K - 850/9800 (https://valid.x86.fr/bench/f8003w)
В случае пока количество сеансов <= количеству потоков (с учетом HT) ПК с 12900 будет давать результаты в 2,2 раза лучше (см. примечание) чем сервер с 4216.
По мере увеличения количества сеансов 12900 разрыв в производительности будет падать.
Вы не написали сколько пользователей у вас. Если 300 пользователей, то нужно будет или смириться с меделенной работой сервера или подбирать соответсвующие сервера в кластер (5-7 серверов).
Примечание
Тут и дальше под термином "производительность сервера 1С" я имею в виду время выполнения кода.
Очевидно что в реальной работе, например: "формирование отчета СКД, проведение документа, открытие формы списка и.т.п", Прироста в 2 раза не будет, так как там 98% времени работает СУБД и только 2% работает сервер 1С.
Если до 50 человек то под Сервер 1С лучше взять хорошее десктопное железо (12900/12700, старшие ZEN3).
Мало того что сэкономите на серверах, так еще и за счет огромного L2 (1,25МБ на ядро!) и быстрой памяти процессы 1С будут работать очень быстро. В случае ZEN3 там L2 стандартный но зато L3 - 32Mb. (Не знаю что из этого будет лучше но точно знаю что оба покажут себя хорошо)
Из моего опыта если говорить о стандартной бух то сервер 1С на 12900 без проблем будет держать 60-70 пользователей (с учетом того что они работают не равномерно, если у вас работают операторы потокового ввода по всей стране и генерят нагрузку непрерывно то конечно цифры другие будут).
Как убедить заказчика? Если вы +/- крупный франч купите себе один такой системник, и просто показывайте заказчку разницу.
По другому убеждать людей что ПК за 80к будет лучше справляться с сервером 1С, чем сервер за 800к не реально.
Даже под моим сообщением, уверен, будет не один комментарий по этому поводу :).
Приложение "Сервер 1С" в отличии от СУБД не требует серверного оборудования, отлично масшатабируется по количеству ПК, т.е. если у вас 100 пользователей ставьте 2 системника, 150 ставьте 3 и.т.п. требований к диску каких то особых нет, к надежности тоже, особеено если у вас и так кластер из нескольких системников.
Зато с СУБД вам лучше постараться уместить все на одном сервер так как в случае с 1С вам будет ОЧЕНЬ тяжело масштабировать СУБД добавлением еще одного сервера.
Про отключение ядер
Что касается вашего случая, и других случаев работы Turbo boost то все сводится к TDP. У процессоров 4216 TDP 100W и в зависимости от загрузки эти 100W набираются или 8ю ядрами на 3Ггц или 16ю на 2.9 и.т.п. Зеонщики со стажем (сам 2 года дома сидел на 2673v3) всю эту кухню знают, и так же по себе знают насколько важна однопоточная производительность для приложений которые не умеют в многопоток.
Все что вы описали phyton специалист сделает быстрее и лучше за счёт отличных библиотек по работе с xml и паркингу html. Код будет понятнее.
У меня есть опыт написания html парсера и генератора на 1c и это по уровню где то 99й год, собираем текст из строк и шаблонов, и так же парсер, да что говорить даже регулярок нет.
С питоном: pip install beautifulsoup, pip install requests, pip install pandas
И у тебя удобные структуры данных для работы, и главное простой и понятный код.
В итоге как показала практика, на долгой дистанции выгоднее сделать на питоне парсер и отдавать результаты в 1с через мни http сервер чем реализовывать и что намного более важно сопровождать и развивать парсер на 1с.
Питон как язык можно выучить за 3 дня. Дальше уже библиотеки и ООП, и этому можно учиться всю жизнь.