кэширование результатов поиска в сеансе против сохранения кучи больших объектов в чистоте - PullRequest
6 голосов
/ 19 мая 2011

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

После прочтения по управлению памятью .NET я думаю, что определил целый ряд потенциальных причин.Поскольку вещи, которые я делаю, не особенно особенные, мне интересно, есть ли стандартный шаблон для достижения того, чего я хочу сделать, которого я пропускаю.

Итак, у меня есть (довольно дорогой запрос), который дает результаты от 1 до 20000.При последующих запросах мы можем просто перелистывать набор результатов, поэтому я сохраняю этот результат в сеансе.Сессия InProc.Мне интересно:

  • Имеет ли смысл а) сохранять результат б) в сеансе в) в процессе?Я хочу скорость (а).Я не знаю, есть ли более эффективный способ, чем хранить его пользователем (b), и если я использую более сложный сервер состояний - разве он не станет медленнее (c)?Или это может быть решением проблемы более быстрого удаления этих крупных объектов вместо сохранения последнего результирующего набора в ОЗУ до истечения сеанса?

  • Если какой-либо набор результатов> ~ 20000 строк потенциально может оказатьсяиспортить LOH, есть ли общий способ обойти это?

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

Ответы [ 3 ]

1 голос
/ 19 мая 2011

Вам следует избегать сохранения результатов в сеансе. Вероятно, ваше приложение не будет работать нормально, если пользователь использует несколько вкладок браузера в одном сеансе (это происходит).

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

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

1 голос
/ 19 мая 2011

Зачем возвращать всегда все записи ?? Я думаю, что лучший способ ускорить ваш запрос - это возвращать только те данные, которые нужны пользователю ... так что только те данные, которые помещаются на странице!

Попробуйте поискать в Google ROW_NUMBER () (SQL Server) или LIMIT (mySQL).

Вот 2 урока товара

1) Блог ScottGu

2) 15 Второй урок

1 голос
/ 19 мая 2011

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

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

Наконец, возможно, вам следует рассмотреть возможность использования объекта Cache для хранения результатов, а не сеанса.Таким образом, вы позволяете .NET решать, когда удалять объекты, и они не приводят к раздутому сеансу.

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