За и против использования Сервера Состояния сеанса ASP.NET (вместо InProc)?
Согласно yargs документам, метод command принимает 4 параметра, а не объект;
.command(cmd, desc, [builder], [handler])
, поэтому ваш код должен выглядеть примерно так (обратите внимание, больше нет скобок и ключей объектов):
//create add command
yargs.command(
'add',
'to add note',
function() {
console.log('note has been added')
}
})
Если вы не передаете необязательный builder param, вероятно, должен использовать именованные params для функции-обработчика (не уверен, как yargs назвал params, но я думаю, это handler), как
...
handler = function() {
console.log('note has been added')
}
5 ответов
Вот канонический анализ плюсов и минусов ваших трех вариантов из статьи Роба Ховарда Состояние сеанса ASP.NET :
В процессе . В процессе будет работать лучше, потому что память состояния сеанса хранится в процессе ASP.NET. Для веб-приложений, размещенных на одном сервере, приложений, в которых пользователь гарантированно будет перенаправлен на правильный сервер или когда данные о состоянии сеанса не критичны (в том смысле, что они могут быть переконструированы или повторно заполнены) , это режим, который нужно выбрать.
Вне обработки . Этот режим лучше всего использовать, когда важна производительность, но вы не можете гарантировать, с какого сервера пользователь запросит приложение. В внепроцессном режиме вы получаете производительность чтения из памяти и надежность отдельного процесса, который управляет состоянием всех серверов.
SQL-сервер . Этот режим лучше всего использовать, когда надежность данных имеет основополагающее значение для стабильности приложения, поскольку база данных может быть кластеризована для сценариев сбоя. Производительность не такая быстрая, как вне процесса, но компромисс - более высокий уровень надежности.
Опции вне процесса (также известные как StateServer) и SQL-Server выдерживают перезапуски веб-приложений (включая циклическое переключение пула приложений) и делают данные сеанса доступными для нескольких серверов в кластере / ферме.
Наконец, это может быть само собой разумеющимся, но базовую настройку в процессе проще всего настроить, что является значимым «профи» во многих средах.
ASP Тима Снита.Состояние сеанса .NET: аспекты архитектуры и производительности добавляет некоторую дополнительную информацию, а тема MSDN о режимах состояния сеанса является надежным и актуальным источником.
State Server - это отличный (!) выбор для начала. Зачем? Потому что это означает, что ваше приложение теперь совместимо с любыми внешними режимами хранения.
Если вы в настоящее время разрабатываете свой сайт с InProc и хотите перейти на StateServer или SqlServer позднее, у вас могут возникнуть проблемы с сериализацией. Не всегда, но так бывает.
Некоторые примеры включают в себя (некоторые уже упоминались):
- Операции запускают планирование регулярных циклов повторения пулов приложений IIS без вашего ведома
- Недостаточно памяти на постоянной основе
- Вы будете работать с балансировщиком нагрузки на производстве и не можете гарантировать, что тот же веб-сайт получит тот же запрос.
Поэтому, лучше разобраться с этим раньше, чем позже. Это только изменение конфигурации и запуск службы; Boom!
Что также означает, что если вы решите пойти по совершенно другому маршруту хранения сеанса, например, используя Redis (распределенное хранилище ключей / значений) или RavenDB (база данных документов), вы уже отсортированы ,
Это действительно хорошая инвестиция в 1 минуту работы. Теперь вы готовы к веб-фермам, балансировщикам нагрузки и любым другим системам управления сеансами, для которых вы решили создать прототип.
Я бы сказал, что одним из больших недостатков использования In_Proc является то, что состояние сеанса может быть потеряно в случае перезапуска пула приложений или домена. Это может произойти в любое время, например, если на сервере недостаточно памяти и т. Д. Я лично никогда не полагаюсь на сессию In_Proc для всего, что вы не хотите потерять. Я потратил часы на отладку сайтов со спорадическими проблемами только для того, чтобы найти его, потому что состояние сеанса было потеряно из-за того, что сервер имел мало ресурсов для повторного использования ресурсов (и, конечно, чем больше вы храните в сеансе, тем меньше серверных ресурсов вы Запомните, если это может пойти не так, то, вероятно, в какой-то момент это не так!
Вот почему я теперь обычно использую State Server для чего угодно, кроме простых данных сеанса. Единственный реальный недостаток, который я нашел, это вам нужно пометить классы как сериализуемые, но это обычно тривиально. Это также немного медленнее, но в большинстве случаев это незначительно.
Есть хорошая статья об этом на Блог IIS MSDN.
Еще один недостаток - у вас, вероятно, будет одна точка отказа, если вы сделаете 1 удаленный сервер состояний по всей ферме. Даже если это не ферма, ее все равно стоит запускать локально, чтобы выжить в app_pool IMO. Мы попались на сериализуемую часть, так что следите за этим.
Кроме того, следите за выпуском Windows Server AppFabric, поскольку он будет заменен реплицированным / распределенным сервером состояний. Предположительно RTM в 1П2010.
Преимущества:
1. Вы можете получить доступ к одному и тому же состоянию сеанса на разных машинах.
2. Такое же состояние сеанса доступно после перезагрузки app_pool.
Недостатки:
1. Медленнее, чем в технологическом режиме.
2. Все объекты в состоянии сеанса должны быть сериализуемыми.