Чем отличается от Node.js событие? Не можем ли мы сделать это в ASP.Net HttpAsyncHandler?

Я не очень разбираюсь в веб-программировании, и я на самом деле ничего не закодировал в Node.js, просто интересуюсь ориентированным на события подходом. Кажется, это хорошо.

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

Нельзя ли это правильно обработать с помощью IHttpAsyncHandler? ASP.Net получает запрос, использует ThreadPool и запускает обработчик (BeginProcessRequest), а затем внутри него мы загружаем файл/базу данных обратным вызовом. Затем этот поток может свободно обращаться с другими запросами. Как только чтение файла завершено, ThreadPool снова запускается в действие и выполняет оставшийся ответ. Для меня это не так уж и отличается, так почему же это не так масштабируемо?

Один из недостатков потоковой системы, который я знаю, - использование потоков требует большего объема памяти. Но только с ними вы можете наслаждаться преимуществами нескольких ядер. Я сомневаюсь, что Node.js вообще не использует нити/ядра.

Итак, основываясь только на управляемых событиями потоках на основе потоков (не привносите аргумент "потому что это Javascript и каждый браузер..." ), может кто-то указать мне, что является фактическим преимуществом использования Node.js вместо существующей технологии?

Это был длинный вопрос. Спасибо:)

Ответы

Ответ 1

Прежде всего, Node.js не многопоточен. Это важно. Вы должны быть очень талантливым программистом для разработки программ, которые отлично работают в многопоточной среде. Нити просто тяжелые.

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

Во-вторых, вся платформа была разработана для асинхронного запуска. Вы видите какой-либо проект ASP.NET, где каждое одно взаимодействие ввода-вывода было асинхронным? просто ASP.NET не был предназначен для управления событиями.

Затем есть место для памяти из-за того, что у нас есть один поток для открытого соединения и вся проблема масштабирования. Исправьте меня, если я ошибаюсь, но я не знаю, как избежать создания нового потока для каждого соединения в ASP.NET.

Другая проблема заключается в том, что запрос Node.js не используется, когда он не используется, или когда он ожидает ввода-вывода. С другой стороны, поток С# засыпает. Теперь существует ограничение на количество этих потоков, которые могут спать. В Node.js вы можете легко обрабатывать клиенты 10k одновременно параллельно на одной машине разработки. Вы пытаетесь обрабатывать потоки 10k параллельно на одной машине разработки.

Сам JavaScript как язык упрощает асинхронное кодирование. Если вы все еще в С# 2.0, то асинхронный синтаксис - настоящая боль. Многие разработчики просто запутаются, если вы определяете Action<> и Function<> повсюду и используете обратные вызовы. Проект ASP.NET, написанный определенным образом, просто не поддерживается средним разработчиком ASP.NET.

Что касается потоков и ядер. Node.js является однопоточным и масштабируется, создавая несколько процессов node. Если у вас есть 16 ячеек, вы запускаете 16 экземпляров вашего сервера Node.js и имеете перед собой один балансировщик нагрузки Node.js. (Может быть, балансировщик нагрузки nginx, если хотите).

Все это было написано на платформе на очень низком уровне с самого начала. Это была не какая-то функциональность, закрепленная позже по линии.

Другие преимущества

Node.js имеет намного больше, чем выше. Выше только почему Node.js 'способ обработки цикла событий лучше, чем делать это с асинхронными возможностями в ASP.NET.

  • Производительность. Это быстро. Очень быстро.
  • Одним из больших преимуществ Node.js является его низкоуровневый API. У вас много контроля.
  • У вас есть весь HTTP-сервер, интегрированный непосредственно в ваш код, а затем переданный в IIS.
  • У вас есть сравнение nginx vs Apache.
  • Вся проблема с C10K хорошо обрабатывается node, но не IIS
  • Связь AJAX и JSON кажется естественной и легкой.
  • Общение в реальном времени - одна из замечательных вещей о Node.js. Это было сделано для него.
  • Хорошо работает с базами данных nosql на основе документов.
  • Можно также запустить TCP-сервер. Может выполнять доступ к файлам, может запускать любую консольную консоль unix на сервере.
  • Вы запрашиваете свою базу данных в javascript, используя, например, CouchDB и map/reduce. Вы пишете своего клиента в JavaScript. В вашем веб-стеке нет контекстных переключателей.
  • Богатый набор открытых модулей с открытым исходным кодом. Все в Node.js является открытым исходным кодом.
  • Малый размер и почти никаких зависимостей. Вы можете самостоятельно создать источник Node.js.

Недостатки Node.js

Это сложно. Он молод. Как опытный разработчик JavaScript, мне трудно писать веб-сайт с Node.js только из-за его низкого уровня и уровня контроля, который у меня есть. Он чувствует себя так же, как C. Множество гибкости и силы, которые могут быть использованы для меня или повесить меня.

API не заморожен. Это быстро меняется. Я могу себе представить, что вам нужно переписать большой веб-сайт полностью через 5 лет из-за суммы Node.js будет изменена к тому времени. Это полезно, вам просто нужно знать, что обслуживание на веб-сайтах Node.js не является дешевым.

дальнейшее чтение

http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

http://blip.tv/file/2899135

http://nodeguide.com/

Ответ 2

Существует много заблуждений относительно node.js против ASP.Net и асинхронного программирования. Вы можете не блокировать IO в ASP.NET. Большинство людей не знают, что инфраструктура .Net использует Windows iocompletion ports ниже, когда вы выполняете вызовы веб-сервисов или другие связанные с ним операции ввода-вывода, используя шаблон начала/конца в .Net 2.0 и выше. Порты ввода-вывода - это способ, которым операционная система Windows поддерживает неблокирующее IO, чтобы поток приложений был освобожден, почему завершена операция ввода-вывода. Интересно, что node.js использует менее оптимальную неблокирующую реализацию ввода-вывода в Windows через Cygwin. Новая версия Windows находится на дорожной карте, которая с руководством Microsoft будет использовать порты ввода IO. В этот момент нет никакой разницы.

Также можно выполнять неблокирующие вызовы базы данных в ADO.NET, но имейте в виду инструменты ORM, такие как NHibernate и Entity Framework. Они все еще очень синхронны.

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

Наличие только одного потока может вызвать голодание во время длительных операций, что может быть связано как с IO, так и с комплексными вычислениями. Таким образом, хотя эмпирическое правило является одним потоком pr. ядро при использовании неблокирующего IO, все равно следует учитывать достаточный размер пула потоков, чтобы простые запросы не истощались более сложными операциями, если таковые существуют. Несколько потоков также позволяют легко распределять сложные операции между несколькими процессорами. Однопоточная среда, такая как node.js, может использовать только многоядерные процессоры через большее количество процессов и передачу сообщений для координации действий.

Я лично еще не видел никаких убедительных аргументов в отношении введения дополнительной технологии, такой как node.js. Однако могут быть веские причины, но они, по моему мнению, мало связаны с обслуживанием большого количества подключений посредством неблокирующего ввода-вывода, поскольку это также можно сделать с помощью ASP.NET.

BTW tamejs может помочь сделать код nodejs более читаемым, похожим на новый .Net Async CTP.

Ответ 3

Легко занизить культурную разницу между сообществами Node.js и ASP.NET. Конечно, IHttpAsyncHandler существует, и он существует с .NET 1.0, поэтому он может быть даже хорошим, но весь код и обсуждение вокруг Node.js - это асинхронный ввод-вывод, который явно не тот случай, когда дело доходит до .NET., Хотите использовать LINQ To SQL? Ты вроде как можешь, вроде. Хотите записать материал? Может быть, "CSharp DotNet Logger" будет работать, возможно.

Итак, у меня есть IHttpAsyncHandler, и если вы действительно будете осторожны, вы сможете написать веб-сервис, управляемый событиями, без отключения какого-либо блокирующего ввода-вывода где-нибудь, но на самом деле у меня не так много впечатлений люди используют его (и это, безусловно, не является заметным способом для написания приложений ASP.NET). Напротив, Node.js - все о событиях ввода-вывода, всех примерах кода, всех библиотеках, и это единственный способ, которым люди его используют. Поэтому, если бы вы делали ставку на то, что одна модель ввода-вывода действительно работала до конца, Node.js, вероятно, будет выбран.

Ответ 4

В соответствии с современными технологиями усовершенствования и чтения ниже ссылок, я могу сказать, что это вопрос экспертизы и выбор идеального сочетания в соответствии с конкретным сценарием, который имеет значение. NodeJS становится зрелым, а ASP.NET - у нас есть ASP.NET MVC, WebAPI и SignalR и т.д., Чтобы улучшить ситуацию.

Node.js против производительности.

http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ и

http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx

Спасибо.