Оптимизация ресурсоёмкой функции (linq)?

Question

[LuckyReveal]

Добрый день.

Функция, которую нужно оптимизировать, вызывается примерно 100.000 раз в сутки. Проект в облаке азура, сами понимаете…


Вообщем.(Код урезан до нужной фукнции)
www.everfall.com/paste/id.php?wqfnoehtgdp1


Небольшую оптимизацию в виде вынесения запроса к БД в компилированную функцию, как видите, я уже провел.


Есть раблица Exchanger(5.000 записей, прирост 200 в сутки). Она хранит данные о пользователе, Id, поинты, активность лайков и фолловов и некоторые другие данные.

Есть раблица LikeExchanger_Data(500.000 записей, прирост 20.000 в сутки). Она хранит данные о лайках(Дабы одна фотография не показывалась несколько раз одному и тому же пользователю.).

Пользователь поставил лайк, в LikeExchanger_Data внесли данные о лайке, вызвалась LikesList(выше в коде фукнция), которая вернет новый список фотографий, который не будет включать фотографии, на которых уже стоит лайк.


На данный момент, от момента POST запроса с сайта через API до возвращения результата — ~250мс. Нужно сократить хотя бы до 150-180.


Была у меня мысль разнести логику. На самом сервере хранить горячий кэш не только Exchanger, но и LikeExchanger_Data, а запросы к бд отдать на съедение бекенду через Azure Service Bus.

Comments

[LuckyReveal]

Парсер хабра не скушал код.
Код — www.everfall.com/paste/id.php?wqfnoehtgdp1

[lam0x86]

А список _container кем заполняется?

[LuckyReveal]

Lazy-loading'ом :)

[lair]

А профилировать запрос и смотреть, где криво — пробовали? Не может такого быть, что все банальным индексом решается?

PS Не используйте ToList, это лишний оверхед, зачем он вам? ToArray(), а если не использовать явный диспоз контекстов, то вообще ничего не нужно.

[lair]

Но вообще я не понимаю. Если Exchanger хранит данные о пользователе, то почему список фотографий выбирается из нее?

[LuckyReveal]

Запрос то, по сути, не кривой. Он просто тяжелый, так как берет данные из двух таблиц, одна из них довольно-таки большого размера. Я вот и думал, как бы это все обернуть более качественно, так как на «Вы» с LINQ.

[lair]

200k записей — это вообще не размер при правильных индексах. Так что смотрите, что именно тормозит.

[LuckyReveal]

База Azure SQL на что-то влияет?)

[lair]

А что, она индексы не позволяет строить? Вы профилировали свое приложение, смотрели, где именно боттлнек?

Answer 1

[lam0x86]

Может, так?

public class ExchangerProvider
{
    public static IEnumerable<Robofollower.Exchanger> LikesList(int userId)
    {
        using (var context = new DataClassesDataContext())
        {
            return context.Exchanger
                .Where(e => e.UserId != userId)
                .Where(e => e.LikeActive)
                .Where(e => e.Points >= 1)
                .Where
                (e => 
                    context.LikeExchanger_Data
                        .Where(l => l.UserId == userId)
                        .All(l => l.MediaId != e.MediaId)
                )
                .OrderByDescending(e => e.Points)
                .Take(5)
                .ToList();
        }
    }
}

Comments

[LuckyReveal]

ReSharper ругается. По сути, тот же самый запрос, только в куче функций. Зачем? Есть какие-то фичи?

[lam0x86]

В твоём примере сначала выполняется _container.Where. Сложность — O(N).
Потом OrderByDescending. Сложность — O(N*ln(N)).
Потом Where(All). Сложность O(N*M).
Итого, общая сложность — O(N*M*ln(N)), где N — число пользователей, а M — лайки данного пользователя. Это очень медленно.

То, что предложил я, выполняется полностью на стороне БД с использованием индексов, без index scan-ов. Сложность не знаю как посчитать, но должно быть в разы быстрее. :)

[lam0x86]

А кстати, как решарпер ругается? Код не компилируется?

[LuckyReveal]

Ругается, что все можно сократить до одной Where(...)

[lam0x86]

Да это-то можно, не спорю. Просто на мой взгляд, с несколькими Where код получается нагляднее. А Linq2Sql-транслятору пофиг как код будет записан. Он и то, и то одинаково оттранслирует.