ASP.NET Session - большой объект против множества мелких объектов

Question

У меня есть сценарий для оптимизации того, как мое веб-приложение хранит данные в сеансе и получает их.Я должен отметить, что я использую SQL Server в качестве хранилища сеансов.

Мой сценарий заключается в том, что мне необходимо сохранить список уникальных идентификаторов, сопоставленных со строковыми значениями, в сеансе пользователя для последующего использования.Текущий код, который я унаследовал, использует List<T> с пользовательским объектом, но я уже вижу, что какой-то словарь намного лучше для производительности.

Я проверил две идеи для альтернатив:

1. Сохранение Dictionary<int, string> в сеансе.Когда мне нужно вернуть строки, я получаю словарь из сеанса один раз и могу проверить каждый идентификатор объекта словаря.

2. Поскольку сессия в основном похожа на сам словарь, сохранитестрока непосредственно в сеансе с использованием уникального ключа сеанса, например, Session["MyString_<id>"] = stringValue".Получение значения из сеанса в основном было бы обратной операцией.

Результаты моего теста показывают следующее на основе операции, которую мне нужно сделать, и использования 100 строк:

• Словарь - 4552 байта, 0,1071 секунды для выполнения операции
• Session Direct - 4441 байт, 0,0845 секунды для выполнения операции

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

Итак, мой вопрос: лучше ли для производительности хранить множество меньших объектов в сеансе, чем один большой?Есть ли какой-то недостаток для хранения большого количества меньших объектов по сравнению с одним большим объектом, которого я не видел?

Answer 1

Существуют штрафы за сериализацию и поиск больших объектов (они занимают больше места и процессорного времени из-за необходимости представлять более сложную структуру).

И почему 2 поиска, когда вы можете сделать только один.

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

Answer 2

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

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

Кроме того, имея много объектов сеанса, вам, несомненно, придется писать больше кода для обработки каждого изменяющегося объекта. Это может быть не намного больше, но, безусловно, больше. Это также может затруднить для разработчика подбор вашего кода для понимания ваших рассуждений и т. Д. И, следовательно, для расширения вашего кода.

Если вы можете обрабатывать сеанс в едином базовом формате, таком как IEnumerable или IDictionary, то это, на мой взгляд, предпочтительнее, даже если это связано с небольшими накладными расходами.