часть, которая позволит решить круг следующих задач:
1) прием и обработка ModBusTCP запросов, от 100 до 500 клиентов, каждый клиент должен быть прикреплен к отдельному порту
2) обработку запросов клиента нужно завести в отдельный поток
3) логику обработки запросов клиента нужно занести в отдельный js файл, с возможностью горячего подключения к основному проекту, т.е. без перезагрузки/остановки серверной части
Что можете посоветовать, какие технологии мне подойдут?
По идее мне нужны:
- планировщик задач,
- средства выделения потоков, с возможностью импорта скриптов из js файлов
- инструмент для динамического подключения к проекту новых js файлов
- сервер ModBusTCP
Помогите с выбором модулей
А точно на ноде надо это делать?
В принципе нет. Просто начальство подсело на vue и node и хотела что бы серверная часть была написана на node Если noda не подходит для реализации задач, то можно воспользоваться любым другим вариантом
Динамически подключать скрипты не выйдет, насколько я тебя понял. Только если мутить обертку через eval, что в целом плохая идея. Отдельные потоки на каждый запрос сделать можно, всё для этого есть. Про планировщик задач — тебе очереди нужны, или шедулер? Непонятен масштаб
можно подключать через песочницу VM
скорее всего шедулер, для параллельного приема данных от 100 до 500 контроллеров
Странно когда в одном тз звучит нода и обработка запросов в отдельном потоке. Стоит подумать точно ли подходящий инструмент выбран, и используется ли этот инструмент по назначению Зачем нужны отдельные потоки?
есть соти контроллеров, от которых по ModBusTCP приходят данные, их нужно принять и обработать, записать в БД и вывести пользователю статистику
Ну это не масштаб, надо справится. Но лучше подумай над выносом конкретной обработки запроса, а не всего, ведь сила ноды в асинхронности. Т.е. на каждый запрос нужно сделать свой контекст и по завершению выполнять событие. Это можно очень по разному сделать. Т.е. если каждый запрос будет обрабатываться в отдельном потоке, то сложнее будет разруливать ответы (Нужно будет вызывать асинхронно запуск потока и ждать резолва) Но меня понесло уже
Это не ответ на мой вопрос. Зачем нужны отдельные потоки?
ответа не будет, тут односторонний прием данных, которые после обработки должны попасть в БД. я хотел в поток занести логику: прием данных, их обработку, запись в БД, и последующего ожидания запроса от контроллера. Как бы задачу зациклить
я хотел в поток занести логику: прием данных, их обработку, запись в БД, и последующего ожидания запроса от контроллера. Как бы задачу зациклить
ваши предложения
В теории это может ускорить выполнение, но всё зависит от сложности обработки. Возможно конкуренция тут не нужна
У меня нет предложений, я хочу понять какая цель преследуется выведением чего-то в отдельный поток (или в несколько потоков). Нода предлагает однопоточную асинхронную работу с запросами, почему вы считаете что вам это не подойдёт? Сложные долгие вычисления при обработке запросов? Или какие-то ещё причины?
Читал, что объемные запросы со сложной обработкой могут застопорить работу если не использовать потоки, по этому пришел к выводам использования потоков. В ээтих выводах могу ошибаться т.к. опыта в nodejs у меня мало. Против одно поточности я ничего не имею, и даже за, ибо проще. Тут надо пробовать
Так а обработка данных от контроллеров сложная? Там сложные вычисления, сотни мегабайт данных?
Есть сложные задачи связанные с распаковкой, конвертацией данных, с пересылкой и резервированием, и много чего другого, фантази у начальников велика и извращенна Хотя я все же начинаю склоняться к одно поточности. Хотя остается вопрос, спиваться ли нода со 100 одновременно подключенными и передаваемыми данных контроллерами?
Данные передаются постоянно? Какой вообще трафик ожидается?
если много io, то справится если много cpu, то нужно считать
данные передаются эпизодически, по событию и по времени (один запрос на запись регистров в 10 сек), это с одного контроллера, а их в районе 600 и их количество постоянно растет
что такое io и cpu? я не очень понял ваш ответ
если много работы процессором (сложные трансформации данных, расчёты) - это cpu. io это туда сюда данные гонять: подождать из сокета, например и записать в базу
Тупо программисты этого чата
Звучит как слишком маленькая нагрузка для того, чтобы беспокоиться о многопоточности
Тут разные люди. Некоторые вон русский еле-еле понимают. Так что не надо обобщать
Наверное вы правы, я не знаю пределы node, но на C++ данные задачи были почему то разделены на потоки (разбирал исходники рабочей SCADA)
скорее всего io, моя задача - это получить с сокета данные, распаковать, преобразовать и обработать, записать в БД
Возможно потому что не стали делать асинхронщину на плюсах, возможно по другим причинам Если не получается провести предварительный анализ и оценку, которые подтвердят что один инстанс ноды не потянет нагрузку (пока по описанию выгляди так, что потянет легко), я бы предложил отказаться от идеи нескольких потоков
Обсуждают сегодня