Сжатие сеанса. Отрицательные и положительные стороны

Question

В web.config вы можете включить сжатие сеанса.

<sessionState mode="InProc" customProvider="DefaultSessionProvider" compressionEnabled="true" > 

Каковы положительные и отрицательные стороны этого действия?

Answer 1

Ну, с положительной стороны, вам нужно меньше места.
На отрицательной стороне требуется время для сжатия, поэтому оно медленнее.

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

Это не очень хорошая идея, потому что если страница пишет что-то в сеансе, это перезаписывается, если я одновременно открываю одну и ту же страницу в другом окне браузера (это тот же сеанс).
И поскольку сеансы InProc истекают, когда вы что-то изменяете в файле web.config, вы можете создавать неограниченное количество ошибок для КАЖДОГО в настоящее время активного пользователя ...
Плюс вы потеряете сеансы inProc, если VM перемещается на другой сервер (облачные среды, отказоустойчивость, динамический масштаб).

Кроме того, поставщик InProc не требует, чтобы объекты были помечены как сериализуемые. Если вы перейдете, например, на поставщика сеанса SQL, вы получите исключения во всех местах, где вы поместите объект, который не был помечен как сериализуемый в сеанс.

Например, когда нужно запросить все места пользователь может получить доступ (в соответствии с правами ПОРТФОЛИО в T_SYS_LocationRights):

Вы получаете UserID от formsAuth-печенья, а затем использовать его в качестве параметра:

DECLARE @userID integer 
SET @userID = 12435 


SELECT * FROM T_Locations 
WHERE (1=1) 
AND 
( 
    (
     SELECT ISNULL(MAX(CAST(T_SYS_LocationRights.LR_IsRead AS integer)), 0) 
     FROM T_SYS_LocationRights 

     INNER JOIN T_User_Groups 
      ON T_User_Groups.USRGRP_GRP = T_SYS_LocationRights.LR_GRANTEE_ID 

     WHERE T_SYS_LocationRights.LR_LC_UID = T_Locations.LC_UID 
     AND T_User_Groups.USRGRP_USR = @userID 
    ) = 1 
) 

не только запрос что-то после того, как изречение:

, если вы когда-нибудь это нужно, это уже есть.

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

• Если вам это не нужно, не запрашивайте его.
• Если вам это нужно, запросите его.
• Если вам нужно это, не храните его в сессии лучше запросить его снова, если это необходимо

Вы можете выиграть гораздо больше времени, выполняя все операции с базой данных сразу, получить все данные вам понадобится System.Data.DataSet (в одной операции запроса, одно соединение open-and-close), а затем используйте это. Когда страница перезагружается, вы всегда можете перезагрузить данные (по сути, вы даже должны).

• Не используйте сеанс как кэш. Это не кеш