Это хорошая практика, чтобы большие списки <T>на сеансах ASP.NET MVC? - PullRequest
1 голос
/ 10 августа 2011

Черт, ребята, я очень озадачен тем, какое решение использовать для моего проекта.Что ж, у меня есть большой список, извлеченный из моей базы данных (более 1000 результатов с большими предложениями запросов, поиск в более чем 3 таблицах с более чем 3 000 000 элементов), и я не хочу делать этот запрос дважды без изменений, потому что большеболее 300 пользователей могут сделать этот большой запрос одновременно, поэтому я решил использовать сеанс, чтобы остаться с результатами каждого пользовательского запроса, но я действительно не знаю, хорошая ли это практика.Мой товарищ по команде сказал мне, что лучше делать большой запрос в каждом посте пользователя, потому что нехорошая практика помещать большие списки в сеансы, потому что многие пользователи, использующие сеансы с большими списками, будут тратить больше с нашего сервера, чем делать этот запрос много раз,Итак, является ли хорошая практика помещать большие списки в сеансы ASP.NET MVC?

[EDIT]

у каждого пользователя могут быть разные результаты, они не одинаковыдля всех пользователей.

[РЕДАКТИРОВАТЬ 2]

Мне нужно показать все результаты запроса одновременно, поэтому я не могу разбить его на страницы.

Ответы [ 4 ]

3 голосов
/ 10 августа 2011

во-первых, замечание Брайана Кросби очень хорошее, плюс - пользователю понадобится просматривать 1000 элементов одновременно?
Вы рассматривали подкачку своих данных?

если, однако, вы решите, что должны иметь этот огромный набор результатов, то как насчет этого -
если я правильно вас понимаю, этот запрос одинаков для всех 300 пользователей.

в этом случае правильное место для этого набора результатов - не Session, а Cache.
приложения. это связано с тем, что Session для каждого пользователя, а Cache для каждого приложения (то есть общим для всех пользователей).

поэтому, если вы храните свои элементы в кэше, как только первый пользователь извлечет эти элементы из хранилища, они будут доступны всем последующим пользователям.

несколько вещей, которые нужно иметь в виду, хотя:
1. поскольку кеш является общим для всех пользователей, вы должны синхронизировать свой доступ к нему.
2. вам нужно установить срок действия (элемент кэша имеет эту опцию изначально), чтобы эти 1000 элементов не могли навсегда остаться в памяти вашего приложения.
3. если эти элементы могут измениться, вам нужно аннулировать кеш, когда они это сделают, чтобы пользователь не просматривал устаревшие данные.

удачи

0 голосов
/ 10 августа 2011

Как правило, нет, не рекомендуется хранить большие массивы данных в сеансе ...

Проблема с хранением «больших» наборов информации в состоянии сеанса заключается в том, что каждый раз, когда вы выполняете обратную передачу формы, это состояние сеанса повторно передается клиенту, что замедляет их взаимодействие с пользователем. (Он хранится в скрытом поле в форме и может увеличиваться в размере из-за плохого сжатия данных в зашифрованный с помощью веб-интерфейса зашифрованный текст - обычно следует избегать помещения больших объемов данных в состояние сеанса, если это возможно)

В тех случаях, когда пользователь должен просматривать «большие» наборы информации, можно создавать сессионные хранилища или чейки для хранения информации в памяти сервера, а затем просто выставлять ключ сеанса в состоянии сеанса; привязать обналиченный на сервере элемент для этого сеанса к ключу сеанса и вашему устройству для повторной передачи при необходимости.

Нечто подобное (псевдокод)

Dictinary<Guid, DataSet> serverCache = new Dictionary<Guid, DataSet>;
This.ApplicationState.Add(serverCache, "DataCache");
// Add users session key and local cached data here
serverCache.Add(This.GetUserSessionGuid(), This.LoadData());

Также +1 к посту о подкачке этих данных - теперь, когда они у вас есть в кеше сервера - вы можете легко справиться с подкачкой.

Все это говорит о том, что хранение этих данных в кеше в течение некоторого фиксированного времени может довольно быстро поглотить память вашего сервера (обычно «дешево» решается с большим объемом памяти ... но все же)

Хорошее сопряжение базы данных и внешнего интерфейса должно быть оптимизировано для обработки нагрузки трафика для данных. Как и предлагалось - сделайте несколько метрик, чтобы узнать, если это даже проблема. Я бы предложил разработать запросы к базе данных, чтобы обеспечить подкачку данных, поэтому каждое представление формы каждым пользователем дополнительно ограничено ...

10 запросов, по одной странице за раз, для 1000 пользователей, возвращающих 100 строк за раз (100 тысяч строк за раз по 1 запросу на пользователя в секунду), гораздо более допустимы для производительности БД, чем 1 запрос, все сразу, возвращающий все 10000 строк для 1000 пользователей (1 миллион строк одновременно)

0 голосов
/ 10 августа 2011

Проверка на достоверность: у вас есть данные игрушек.

1000 результатов - ничто, таблицы с 3 миллионами элементов - ничто. Они даже ничего особенного не сделали 10 лет назад - сегодня мой мобильный телефон справляется с этим без пота.

Просто так.

ЭТО СКАЗАЛ: это также идет другим путем. 1000 предметов - это шутка памяти (если только они не являются изображениями), поэтому они МОГУТ храниться в сессии. Если вы не пользуетесь кучей пользователей, возможно, стоит просто сохранить ее в памяти - это выгодно, но, например, для большинства приложений типа нитранет это выполнимо.

Моя главная проблема с этим заключается в том, что однажды состояние сеанса возможно для нескольких окон браузера (таблиц), и сколько раз я был зол на глупого пргораммера, хранящего что-то в сеансе, который убил меня, используя 2-3 вкладки сайт в то же время выше 0. Я был бы осторожен с этим. Например, кто-то использует две вкладки для разных поисков, чтобы сравнить список.

0 голосов
/ 10 августа 2011

Я бы не стал вкладывать что-то такое большое в сессию, если бы вы могли как-нибудь этого избежать. Если бы мне пришлось хранить его в сеансе, я бы не стал хранить объект List. Преобразуйте элементы управления List в Array и сохраните массив, если необходимо сохранить его в сеансе.

Session["mylist"] = list.ToArray();
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...