Хранение данных в сеансе по сравнению сзаполнить при обратной отправке
Вопрос
Что предпочтительнее: сохранение набора данных в сеансе или заполнение набора данных при каждой обратной передаче?
Решение
Это будет зависеть от многих факторов. Обычно лучше не хранить слишком много элементов в памяти сеанса, если ваш сеанс находится в процессе или на сервере состояний, потому что он менее масштабируемый. Р>
Если ваш сеанс находится в базе данных, может быть лучше просто запросить и повторно заполнить набор данных, если выполнение запроса не является дорогостоящим.
Другие советы
Не используйте сессию !!! Если пользователь откроет вторую вкладку с другим запросом, сеанс будет использован повторно, и результаты будут не такими, как он ожидает. Вы можете использовать комбинацию ViewState и Session, но все равно измеряете, сколько вы можете обработать без какого-либо кэширования, прежде чем прибегнуть к кэшированию.
Это зависит от того, насколько сильно вы будете это делать и где ваши данные сеанса хранятся на сервере.
Сохранение наборов данных в сеансе, безусловно, влияет на использование памяти . Все переменные сеанса хранятся в памяти или на сервере SQL, если вы используете состояние сервера SQL. Вы также можете разгрузить нагрузку на другой компьютер, используя режим State Server.
Сериализация / десериализация. Если вы используете безумно большие наборы данных, это может плохо повлиять на производительность сервера.
С другой стороны, наличие очень больших состояний просмотра на страницах может сильно снизить производительность . Поэтому я буду держать наборы данных в сеансе или в кеше и искать «outproc» способ сохранить эти данные сеанса.
Поскольку мне нужно как можно меньше операций с базами данных, я буду хранить данные в сеансе, но я не уверен, что будет лучшим способом сделать это. Как мне справиться с параллелизмом, а также с тем, что данные совместно используются, когда два пользователя одновременно используют страницу, как я могу убедиться, что у каждого из них есть свой набор данных в сеансе?
Обычно я держу его в сеансе, если он не слишком большой и / или БД далеко и медленно. Если данные большие, в общем, лучше перезагрузить.
Иногда я использую Cache, я загружаю из Db в первый раз и помещаю его в кеш. Во время обратной проверки я проверяю chache и, если он пуст, я перезагружаю. Таким образом, сервер управляет кэшем самостоятельно.
Проблема с сессией в том, что если она в процессе, она может исчезнуть, что не так уж и здорово, если это сервер состояний, то вам нужно сериализоваться, и если это sql sate, вы все равно совершаете обратный путь! Р>
если набор результатов большой, сделайте пользовательский пейджинг, чтобы вы возвращали только небольшое подмножество общих результатов. Р>
тогда, если вы думаете, что несколько пользователей увидят, что этот набор результатов поместит каждую страницу в кеш как пользовательские страницы, убедитесь, что кэш обновляется при изменении данных или через некоторое время, когда к ним не обращаются. Р>
если вы не хотите совершать многократные обходы и думаете, что у вас есть память, поместите весь набор данных в кеш, но будьте осторожны, это не растопит веб-сервер. Р>
использование кеша означает, что пользователям не нужен собственный набор данных, а они используют глобальный набор.
Что касается параллелизма при загрузке страницы вставки / редактирования, вам необходимо заполнить ее свежими данными и обновить кэш после добавления / обновления. Р>
Я большой сторонник разделения и редко, если вообще когда-либо, вижу необходимость выбросить полный набор данных в пользовательский интерфейс.
На самом деле вы должны только передавать объекты в пользовательский интерфейс, который необходимо использовать, поэтому, если вы не показываете большую диаграмму или какую-то структуру данных, которая должна отображать отношения между данными, это не стоит затрат.
Меньшие подмножества данных, когда это применимо, гораздо эффективнее. Действительно ли ваше приложение использует все функции в наборе данных пользовательского интерфейса? если нет, то лучший способ продолжить - передать только те данные, которые вы отображаете. Р>
Если вы привязываете данные к элементу управления, сортируете / разбиваете на страницы и т. д. через него, вы можете реализовать множество интерфейсов, позволяющих поддерживать этот набор данных, в виде гораздо меньшего куска кода.
В этой заметке я бы сохранил данные, которые в основном статичны (например, они не так часто обновляются) в кэше. Поэтому вам нужно посмотреть, как часто данные обновляются, прежде чем вы действительно сможете принять решение.
Наконец, я скажу это снова, я вижу необходимость очень и очень редко использовать набор данных в пользовательском интерфейсе. Это очень тяжелый объект данных и экономическая выгода от рассмотрения ваших требований к данным по сравнению с простотой реализации , может значительно перевесить необходимость кэширования набора данных.
ИМХО, наборы данных довольно плохо использовать, если вы беспокоитесь о производительности или использовании памяти.
Ваш ответ не намекает на использование данных. Это справочные данные? Пользователь активно обновляет его? Предполагается, что более одного пользователя одновременно имеют доступ к обновлениям?
Без какой-либо более качественной информации, чем вы предоставили, придерживайтесь общепринятого мнения, что хранение больших объемов данных в сеансе - это способ гарантировать, что ваше приложение не масштабируется и потребует огромных ресурсов для обслуживания. горстка людей.
Обычно есть лучшие способы управления большими наборами данных, не прибегая к загрузке всех данных в память. Р>
Если этого не произойдет, если данные вашего приложения поистине чудовищны, рассмотрите мощный клиент с серверной частью веб-службы. Это может быть лучше, чем создание веб-страницы.
Как отмечали другие ответы, ответ "зависит". Однако я предполагаю, что вы говорите о данных, которыми обмениваются пользователи. В этом случае вы не должны не сохранять набор данных в сеансе пользователя, а заполнять его при обратной передаче.
Кроме того, вы должны заполнить кэш рядом со слоем доступа к данным вашего приложения, чтобы повысить интерактивность и снизить нагрузку на базу данных. Дизайн вашего кеша снова будет зависеть от типа данных (только чтение и чтение / запись и чтение в основном).
Этот подход отделяет сеанс пользователя (концепция уровня пользовательского интерфейса) от управления данными и обеспечивает дополнительное преимущество поддержки совместного использования кэшированных данных (в тех случаях, когда данные являются общими для пользователей).
Ни то, ни другое - ничего не "сохраняйте"!Отображайте только то, что нужно видеть пользователю, и создайте эффективную схему подкачки страниц для просмотра строк в обратном направлении.
rp
Продолжайте сеанс. При необходимости можно заполнить заново, например, если память сеанса стерта.