Есть ли какое-то ограничение размера сеанса или рекомендуемое значение, чтобы не превзойти?
В моем веб-приложении я создаю несколько DataTables для хранения пользовательских выборов, которые хранятся в сеансе, пока пользователь не одобрит выбор, поэтому я добавляю эти значения в базу данных.
Проблема в том, что я не знаю, достаточно ли сеанса, чтобы содержать несколько объектов или нет?
Спасибо!
больше информации
Размер сеанса составляет около 10-20 КБ.
Да, это надежный. Это просто не очень масштабируемое, поэтому планируйте заранее. Это полностью остановится, когда вы запустите его на более чем 1 сервере.
И есть какой-то предел: Number-of-concurrent-Users * SizeOf-Session < Доступно-Mem
Это зависит, конечно, от размера таблиц, обычно считается приемлемым сохранение нескольких килобайт (хотя сайты с высоким трафиком будут пытаться уменьшить его).
Если ваши пользователи могут совместно использовать таблицы, вы можете поместить эти данные в объект приложения, что значительно экономит.
И объект сеанса ограничен установкой TimeOut, по умолчанию 20 минут. Один из способов оптимизации потребления памяти - это сокращение, но это компромисс с удобством пользователя.
Здесь несколько заметок о состоянии сеанса:
mode="InProc") ограничено объемом памяти, доступной для рабочего процесса. Сохраняются только ссылки на объекты, а не сами объекты.Вне процесса управления состоянием сериализует объекты перед их сохранением:
Управление состояниями вне процесса с использованием сервера состояния сеанса (mode="StateServer") ограничено объемом памяти, доступной для государственной службы.
Управление состояниями вне процесса с использованием SQL Server (mode="SQLServer") привязано только к максимальному размеру типа данных SQL image или максимальному разрешенному размеру базы данных.
Очевидно, что все еще должно быть достаточно памяти для рабочего процесса, чтобы иметь возможность вытащить вне сеанса объект обратно в память и повторно гидратироваться на время HTTP-запроса.
Как я уже упоминал ранее, из процесса управляет сериализацией объектов перед их сохранением.
Это означает, что объекты должны быть сериализованы, которые исключают, например, XmlDocument или все, что наследуется от MarshalByRef.
Попытка сериализации объектов такого типа приведет к следующему исключению:
Невозможно сериализовать состояние сеанса. В 'StateServer' и "SQLServer", ASP.NET будет сериализовать объекты состояния сеанса, и в результате несериализуемые объекты или объекты MarshalByRef не допускается. Такое же ограничение применяется, если аналогичная сериализация выполняется пользовательским хранилищем состояний сеанса в режиме "Пользовательский".
Я предполагаю, что у вас сеанс сохранен в режиме "inProc". В этом режиме сеанс приложений ASP.NET, кеш и т.д. Хранятся в ОЗУ веб-сервера (через процесс aspnet_wp.exe). И .NET не использует все это. Существует параметр в machine.config, который указывает пороговый предел (по умолчанию 60%). Как только этот порог будет достигнут, IIS будет перерабатывать рабочий процесс, и вся информация о сеансе будет потеряна.
Обратите внимание, что если на вашем сервере размещено более одного приложения asp.net, 60% памяти будет использоваться всеми приложениями. Поэтому, если совокупное использование памяти достигает порога, рабочий процесс все еще перерабатывается.
Альтернативой этому, помимо оптимизации использования приложения для использования сеанса, является установка приложения для использования сеанса в нерабочем режиме (с использованием хранилища состояний или sqlserver для хранения информации о сеансе).
В нерабочем состоянии производительность вашей системы снижается.
Обратитесь к этой статье для получения дополнительной информации об управлении состоянием сессии.
Вы всегда должны считать, что сеанс очень ценный и очень ограниченный. Потребление должно быть как можно меньше, потому что вы никогда не узнаете, сколько пользователей приложение будет поддерживать.
DataTable может быть слишком большим для хранения в сеансах, если он не может быть достаточно малым.