Vladimir
Это единственная проблема
Nikita
На 24 дня даже хватит
Nikita
Короче, для таска "вызывать функцию раз в 12 часов" модуль крона не нужен
KlonD90
хз для стабильности setTimeout и долгие задачи явно не то что надо )
John
А почему не поставить крон задачу на самом хостинге? В каждой си панели там и интерфейс удобный
John
Тем более setTimeout не точно считает, из-за асинхронности как раз, на клиенте, по крайней мере так, в долгосрочной перспективе хз на сколько съедет выполнение
Sergey
John
С чем синхронизировать?
John
Тю
Sergey
Все очень просто
John
Та да)
Nurik
Ребят, помогите, пожалуйста
Что-то не врубаюсь с node cron https://www.npmjs.com/package/cron
var CronJob = require('cron').CronJob;
new CronJob('* * * * * *', function() {
//here's function
}, null, false, 'Europe/Moscow');
Как выполнять функцию каждые 12 часов?
Чтобы разово поставить, можно ручками в crontab. Модуль больше нужен, если нужно постоянно что-то в крон класть используя свою обертку для юзверей. И да это не тот же самый крон.
Sergey
Кто нибудь делал ipc между процессами на одном сервере?
Sergey
Без http
Sergey
Пусть процессы будут на разных языках
Sergey
Какие варианты есть
Sergey
Линух сервер
Nurik
fifo
Nurik
Делал на php. Но были проблемы с форкнутыми процессами.
Nurik
Можно еще прям в оперативке держать. shmop
Sergey
один на ноде, другой на го, например
Serhiy
Кто нибудь делал ipc между процессами на одном сервере?
Один раз нужно было что-то быстро придумать. Сделал на редис pub/sub
Sergey
да вот я тож к этому склоняюсь ((
Nurik
процессы на разных языках
А это не имеет значения. Вы будете работать с бинарными данными напрямую. Просто нужно аллоцировать необходимый размер вроде
xelaok
Может unix sockets
Sergey
так се
Serhiy
Было бы больше времени сделал бы на кроликах. Но его не было.
Sergey
короч pub/sub самое оно
Sergey
ну да, я предполагал так
Nurik
Может unix sockets
Ну если низкоуровневые вещи не подходят тогда лучше сразу брокер сообщений прикрутить. Если еще и приоритезация трафика нужна. aka QoS (но выше уровнем)
Nurik
Можно изощриться и заюзать dbus😝
Vladimir
@sergeysova а почему не http то?
Vladimir
А через редис типа нет оверхеда?)
Evgeny
Mkfifo / mkpipe
Vladimir
Ну естественно нет
Vladimir
У тебя лишний демон плюс дополнительные раундтрипы
Vladimir
Протокол может чуть попроще, да
Nurik
идея мне не оч понятна
Идея, в том чтобы заюзать общую для всего шину dbus, в качестве награды получаем шину для общения поверх тех же unix socket
Sergey
У тебя лишний демон плюс дополнительные раундтрипы
ну вообще да.
Но мне кажется меньше гемора с настройкой этого всего.
+ широковещание проще реализуется
Sergey
Vladimir
Ну dbus как то не для серверов все таки
Sergey
Ну dbus как то не для серверов все таки
ты имеешь ввиду, что он задумывался для общения системных процессов?
Vladimir
Для сервисов на десктопе
Nikita
А ещё на ноде process.hrtime есть, а в браузере — performance.now
Evgeny
Тмпфс и там файло. А триггер чтения - сигналы или айнотифай. Ну если хттп оверхед а редис норм
Nikita
Date.now сползёт при смене системного времени, а эти два — нет.
Sergey
но я в общем-то задал вектор мышления
Nurik
Для сервисов на десктопе
и вроде поэтому и не масштабируется из-за чего и бесполезен будет, если вдруг придётся масшабировать.
Anonymous
6.0 в мастере
Nurik
меньше, насколько мне известно
Если по шине планируется гнать очень много данных. то можно упрёться в redis. Ибо там он однопоточный насколько я знаю. Если не так сильно нужна персистетность то еще можно ZMQ. Но redis всё-же легче и проще. Хотя архитектурно для такой задачи мне кажется ZMQ ближе.
Sergey
zmq?
Sergey
я знаю только rmq
Vladimir
0mq
Anonymous
Ø
Sergey
надо погуглить
Sergey
спасибо
Gleb
Но ZMQ может терять сообщения, в теории. Короче, если что-то говоришь мёртвому процессу и сам умер - сообщения будут потерянны.
Nurik
Но ZMQ может терять сообщения, в теории. Короче, если что-то говоришь мёртвому процессу и сам умер - сообщения будут потерянны.
Ну потому что он не как redis работает запрос-ответ. Он больше как udp.
Gleb
Ну не UDP, по пути он ваше сообщение не потеряет :) Просто потому что он не складывает очередь не ушедших сообщений в некое внешнее хранилище. Это тупо маленькая либа, которая берёт ваш message и шлёт его по TCP напрямую на соседний сервер.
Gleb
Если нужна большая-большая шина, то можно попробовать Kafka. Эта сколько надо, столько и пережуёт. Хотя тут надо взвесить твой сервис, может быть очень уж большим оверкилом.
Denis
Коллеги, а как лучше тестировать REST API сервисы?
1. SaaS тулзы (SOAP UI и пр) vs Скрипты (Node.js, bash, etc)
2. Реальные данные (после деплоя) vs Mock-данные
Sergey
Sergey
фиче тесты
Denis
Одна большая система может состоять из 7-10 микросервисов, которые неплохо бы тоже отдельно тестировать, чтобы понимать природу возникающей ошибки