Надо пойти от проблемы. Если проблема - медленно идут данные из базы - то вряд-ли вы ее ускорите добавлением еще большего числа читателей. Может база слабенькая. Задыхается от других процессов. Может сетевой канал вы уже вычерпали и запуск еще большего числа соединений не улучшит ситуацию.
Просто вопрос прозвучал так - я бы хотел проходить через многопоточность ... а это не тот мотиватор который должен был бы быть.
P.S. Если база поддерживает partitioning - попробуйте читать одну большую таблицу параллельно независимыми кусками. Например разбив по датам. По годам. Если partitioning был таков.
Вы не проверяете status_code после того как сделали get response = requests.get(url, params=params)
Там скорее всего лезет 404 Not Found и надо как-то вести учет числа таких ошибок да и вообще в логике
парсера надо учитывать.
Максим Абросимов, может эти 500 мб это и есть минимальный футпринт для node-приложений?
Не знаю. Эту проблему можно решать просто последовательно отбрасывая функционал. Тоесть для начала сделать node - main приложение которое ничего не делает. Печатает в консоли "OK! и стоит на паузе". И еще раз промониторить память. Потом сделать 1 коннекшен к БД. И так далее.
Антон, скорее всего ты где-то не закрываешь какие-то ресурсы. Коннекшены. Сетевые сокеты. Дальше я просто не могу говорить у меня фантазия закончилась. Нужны сорцы.
Выложи в гитхаб ну хотя-бы ту ключевую часть которая в стектрейсе.
А сколько штук купонов находит эта функция? const coupons = await db.Post.findAll()
Можно ли на тестовом создать условия чтобы она нашла 1 штуку и померять расход памяти.
А потом померять допустим когда она нашла 500 купонов.
Чтоб система имела какой-то фактор-отклик. Если расход памяти вообще не зависит от числа купонов - тогда мы не там ищем.
1) Разработка формата хранения и обработки диаграмм планирования (Ганта?)
2) Разработка API для отображения этих данных и редактирования в браузере (front-end)
3) Back-end и подсистема хранения. Варианты : файловая система или база.
Мне кажется что 1 пункт - самый важный. Он определяет для 2х следующих пунктов как работать. Во первых что будет внутри диаграммы? Будет ли это 1 документ или сет связных между собой документов. Будет ли документ версионироваться внутри (как Office документы которые хранят историю изменений). Формат. JSON/XML/yaml бинарные форматы BSON, фреймворки бинарной сериализации такие как Apache Thrift, Avro, Protobuf. Будет ли документ блочный или поточный. Блочный например позволяет подгружать данные частично. Как таблица в БД.
Вобщем если-бы я разрабатывал формат - то нарисовал-бы сначала на бумаге картинку. Потом описал спецификацией просто все что есть. Годы-месяцы. Задачи. Исполнители. События. Алёрты. Напоминалки. И вот от этого бы делал.
Ты разработчик? Это твой код? Или ты просто его унаследовал от кого-то и пытаешся разобраться? Я почему спрашиваю. Можно сильно ускорить решение проблемы если знать условия. Просто с 1 поста я посчитал тебя админом или девопсом и дальше мои советы строились из этого.
Sshalun, знаешь как говорят в time-management науке? Все что важно - не срочно. И все что срочно - не важно.
Потерял файл навсегда. В следующий раз не будешь качать на ноуте. Заведи себе нормальный десктоп. И чтоб не выключался. И как говорил мой преподаватель охраны труда - "Книжка по ОТ - написана кровью тех кто ее не выполнял :)"
Обычно когда FileZilla качает - она создает 2 файла. Первый с каким-то рандомных расширением. Туда какраз пишется сетевой траф. А другой - файл нулевой длины. Это реально тот которые тебе будет презентован. После загрузки файлы как-бы меняются местами. Переименовываются. Это файлзилла иммитирует атомарность на уровне файловой системы.
Да забей. Зачем тебе насиловать файловую систему? Скачай еще раз.
Вы заглядывали внутрь токена? Там - json документ который описывает ваши права и привилегии в системе и также список ресурсов куда можно ходить. И срок действия токена.
Токен подписан тем центром выдачи токенов где вы его получали. И изменить его не сломав цифровую подпись невозможно.
Обычно срок действия - 1 час или сутки. За это время токен превратится в тыкву и будет бесполезен для злоумышленника. Я думаю что центр токенов может уменьшать это время вплоть до нескольких минут.
Токены используются не только в браузерах но и вообще в любых back-end системах. Поэтому про coockie можно сразу не говорить а говорить о слабых местах протокола и о том как быстро исправить ситуацию если токен украден или еще бох весть какой сценарий.
Сомнительно что Junior C++ разработчик вообще слыхал про coreutils. Скорее всего вакансию набилава рекрутерка и чего-то пропустила. Типичная ситуация. Слава богу не попутала с C#
https://clickhouse.com/docs/en/sql-reference/state...