Comments 22
Монго никогда не использовал. Но по коду, разве тут есть смысл указывать .ConfigureAwait(false)? Я это к тому что в ASP.NET Core это поведение по умолчанию. Источник
По-моему адекватнее фильтры выглядят так (если уж вы любите разделять условия):
var filter = Builders<Machine>.Filter
.Where(x => x.Vin == vin)
.Where(x => x.Timestamp >= startTs && x.Timestamp <= timestamp);
А нельзя yield’ить результаты из базы? Да, минус в том, что Content-Length не будет, так как неизвестна длина ответа, но потребление памяти при таком раскладе должно быть ещё меньше чем при батчинге.
Тогда не получается использовать асинхронность.
А какая разница? Доткор всё равно обработку ответа выполняет на потоке из тредпула. Зато памяти не ест практически.
При выполнении параллельных запросов к серверу асинхронность доступа к СУБД позволяет обработать запросы быстрее.
У вас в коде все запросы асинхронны и последовательны — на скорость выполнения никак не влияет.
В общем случае, асинхронность замедляет исполнение, создаёт дополнительную нагрузку на GC, и увеличивает количество переключений контекста.
При этом она может обеспечивать параллельное исполнение и увеличивать масштабируемость. Но именно может, потому что никогда нельзя забывать про размер «укоренённого» асинхронным контекстом графа объектов.
В общем случае, по закону Литтла, если сервис не успевает обслуживать запросы, то никакая асинхронность ему не поможет.
Экономия же на размере стека потоков не всегда оправдана (см. выше про графы объектов).
А если на сервер придет 100500 запросов? Тогда пул будет неограниченно раздуваться и под каждый новый поток в пуле будут выделяться ресурсы.
Горизонтальное масштабирование.
Пул не будет неограниченно раздуваться, а память закончится по другим причинам :)
Ну всё же хотелось бы увидеть тесты при работе с yield’ами. Если можно.
Yeild return добавил в обновлении. Быстрее немного. Но при множестве запросов асинхронность должна выигрывать.
Попробуйте сменить сериализатор. Например. Хорошо так уменьшить потребеление памяти и быстродействие.
Уже интереснее)
И если не затруднит — то yield без батчинга.
И если не затруднит — то yield без батчинга.
Видимо всё переделать надо.
Что-то мне кажется, тут проблема не в монге, а в скорости сериализации через jsonconvert. Профилировать код пробовали?
А зачем вам такая детализация на клиенте, с точностью до половины секунды? Мне кажется можно упростить отдавать например каждые 10 секунд
Sign up to leave a comment.
Производительность выгрузки большого количества данных из Mongo в ASP.NET Core Web Api