Состояние сеанса ASP.Net SQLServer в сравнении с прямым доступом к базе данных - PullRequest
0 голосов
/ 07 июня 2011

На веб-сайте, который я разрабатываю, у меня есть ряд «пользовательских настроек», которые я сохраняю для своих вернувшихся зарегистрированных пользователей (например, количество сводок продуктов на странице для отображения). Мне любопытно, есть ли какое-либо преимущество в производительности для хранения / извлечения этих данных в состоянии сеанса ASP.Net SQLServer по сравнению с извлечением их по мере необходимости непосредственно из моей базы данных. Большое спасибо заранее!

Ответы [ 2 ]

0 голосов
/ 07 июня 2011

В любом случае вы получаете удар на сервер sql. Таким образом, у вас не должно быть заметного влияния на производительность, а также при использовании сервера sql для состояния сеанса - вам не нужно сильно беспокоиться о деталях реализации - следовательно, это может быть «немного» проще в использовании. Но нет - нет главной выгоды. Можно утверждать, что это зависит от того, как вы храните / просматриваете вашу информацию, но для большинства приложений разница здесь совершенно незначительна - вы сами решаете, как реализовать. Теперь, если вы когда-нибудь отойдете от состояния сеанса сервера sql, у вас будет еще один набор проблем (перезапуск приложения и т. Д.), Но это не в рамках того, что вы спросили:)

0 голосов
/ 07 июня 2011

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

Единственная потенциальная проблема с сеансом - это то, что сеанс поддерживается для каждого пользователя.поэтому, если на вашем веб-сайте слишком много пользователей, состояние сеанса возрастает, но, поскольку вы используете SQL Server в качестве хранилища сеансов, вы в этом хороши.Если бы вы использовали InProc SessionMode, ваша сессия была бы в памяти (критический ресурс на производственных серверах!)

...