код, состоящий из двух синхронных операций. он в цикле по каждому элементу (200к записей) отправляет СИНХРОННО сообщение в очередь, а потом СИНХРОННО обновляет запись в БД. Работает крайне медленно. Около 1 секунды на одну запись. Цель ускориться.
Отправку в очередь я не могу как либо переделать, могу лишь завернуть в Task.Run.
Обновляение в бд я могу сделать Асинхронным.
Что я придумал: разбивать по странично по N=20 записей и для каждоой записи внутри пакета выполнять ту же самую логику, но асинхронно. То есть получу 20 тасок. И ожидать выполнение всех N тасок через Task.WhenAll. Когда пакет тасок выполнился, то беру следующий пакет и так пока все не обработаю.
Будет ли так побыстрее?
И другой вопрос, а что если я без разбивок на пакеты, просто для всех 200к записей создам СРАЗУ 200к тасок и буду ожидать их выполнения через Task.WhenAll. не произойдет ли истощение тредпула или рейс кондишн?
Если я правильно понял и у тебя после каждой операции в бд летит 200к запросов, то это немного неправильно
У меня для каждой записи летит запрос в Рэббит и потом один в бд. Оба синхронно
А 200к записей как хранятся? В памяти? Используется EF? Он на таких объемах тупит, конечно же. Нужно пагинацию мутить и очищать ChangeTracker после каждой странички. Синхрон/асинхрон не особо важен, если делается в 1 поток (одним пользователем всегда), и нет недостатка в потоках/ядрах. Я к тому, что асинки не дадут прироста во времени выполнения, они дадут возможность больше запросов обрабатывать параллельно, а это не одно и то же
хранятся в памяти. используется даппер. а асинхронность я хотел мутить потому что подумал что если не терять время на ожидание пока один запрос выполнится где-то там, лучше сразу пакетом отправить эти запросы и дождаться от всех от них ответа через Task.WhenAll, тогда много потоков тред пула параллельно как отправят запрос так и обработают ответ. мне останется лишь дождаться их всех для одной пачки. не уверен наверняка но думал что там может быть быстрее. а сейчас планирую как мне посоветовали поизмерять для начала. Если проблема будет в том числе и с бд, в чем я уверен на 100%, то я буду буфферизировать запрос для бд, и выполнять через одну транзакцию сразу 100 команд для БД, а не как щас по одной. тогда как минимум та часть про бд, будет побыстрее
а как часто такие записи грузятся если 200К и по 1 сек на запись, то это 55 часов
я считал что у меня выходит 3600 записей за час. и это примерно 11 дней для 800к записей. а мне по факту надо не 200к а 800к перегнать для прода. 200к для дева где играюся
по Апи обчно очень быстро улетает вопрос как на принимающей стороне устроено если там на каждую запись своя транзакция, то тогда примерно через 30-40К записей начинается ожидание свободных транзакций и естественно всю тупит попробуй отправлять туда в 4 потока и замерь время если будет уходить так же 3600 то проблема с той стороны
А что на принимающей то стороне? Принимающая сторона это кролик и база данных)
а он сколько может переварить записей в минуту?
Без понятия. Я туда кинул через метод, который мне навязали, и забыл про него. Мне дальше все равно что он делает) Мне надо измеРить оба действия а потом уже буду думать 🤔
логика там же такая что то пришло если прошло валидацию запись в БД ответ что записали после чего ты можешь отправить следующую запись ставь логер перед отправкой и после ответа что ок и сравнивай время если в начале будет 0,1 сек а с N отправки 0,5 сек то проблема не у тебя
и уточни у своих, можешь ли ты туда пакетно отправлять
Я ещё раз говорю. Я просто кидаю в кролик. Не жду никаких ответов! Никакой валидации. Ни че го, кроме «я тебе покушать принёс возьми пожалуйста». И нет пакетного апи нет для метода. Все что я могу сделать это изменить второй метод при работе с бд тк он полностью мой, а метод для работы с кроликом максимум могу обернуть в таску. Не более того
ну это же проще, главное что бы там буфер выдержал )) распараллель на 4 потока, в каждом все то что у тебя сейчас и так работает, что бы работало с 1/4 данных и проверяй
Ну вот примерно это и спрашивал… мол я думал сделать по чанкам, а Денис подсказал партишионер)
Обсуждают сегодня