Быть БЫСТРЫМ и обрабатывать много нагрузки - две разные вещи. Сервер, который действительно БЫСТРО обслуживает один запрос в секунду, может полностью работать, если вы отправите ему 500 запросов в секунду (в режиме LOAD ).
Вы также должны учитывать статические (и кэшированные) и динамические страницы. Если вы беспокоитесь о статических страницах, то IIS, вероятно, превзойдет узел, потому что IIS использует кэширование в режиме ядра, что означает, что запросы, запрашивающие статическую страницу, даже не собираются выходить из ядра.
Я предполагаю, что вы ищете сравнение между ASP.NET и узлом. В этой битве после того, как все будет скомпилировано / интерпретировано, вы, вероятно, будете довольно близки по производительности. Может быть, .NET немного БЫСТРЕЕ, или, может быть, узел немного БЫСТРЕЕ , но, вероятно, он достаточно близко, чтобы вам было все равно. Я бы поставил на .NET, но я точно не знаю.
Место, где этот узел действительно интересен, предназначено для обработки LOAD . Вот где технологии действительно отличаются. ASP.NET выделяет поток для каждого запроса из своего пула потоков, и как только ASP.NET исчерпал все доступные запросы потоков, начинают ставиться в очередь. Если вы обслуживаете приложения «Hello World», такие как пример @shankar, то это может не иметь большого значения, потому что потоки не будут блокироваться, и вы сможете обрабатывать множество запросов перед вами. закончились темы. Проблема с моделью ASP.NET возникает, когда вы начинаете делать запросы ввода-вывода, которые блокируют поток (обращение к БД, выполнение http-запроса к службе, чтение файла с диска). Эти запросы на блокировку означают, что ваш ценный поток из пула потоков ничего не делает. Чем больше у вас блокировок,ЗАГРУЗИТЕ ваше приложение ASP.NET будет в состоянии служить.
Чтобы предотвратить эту блокировку, вы используете порты завершения ввода / вывода, которые не требуют удержания потока, пока вы ожидаете ответа. ASP.NET поддерживает это, но, к сожалению, многие из распространенных фреймворков / библиотек в .NET НЕ. Например, ADO.NET поддерживает порты завершения ввода / вывода, но Entity Framework их не использует. Таким образом, вы можете создать приложение ASP.NET, которое является чисто асинхронным и обрабатывает большую нагрузку, но большинство людей этого не делают, потому что это не так просто, как создать синхронное приложение, и вы не сможете использовать некоторые из ваших любимых частей структуры (как linq для сущностей), если вы делаете.
Проблема состоит в том, что ASP.NET (и .NET Framework) были созданы для того, чтобы не думать об асинхронном вводе-выводе. .NET не волнует, пишете ли вы синхронный или асинхронный код, поэтому решение за этим должен принять разработчик. Частично это связано с тем, что многопоточность и программирование с асинхронными операциями считались «сложными», и .NET хотел порадовать всех (новичков и экспертов). Это стало еще сложнее, потому что .NET закончила с 3-4 различными шаблонами для выполнения асинхронного. .NET 4.5 пытается вернуться и модернизировать платформу .NET, чтобы создать самоуверенную модель асинхронного ввода-вывода, но может пройти некоторое время, пока платформы, о которых вы заботитесь, действительно поддержат ее.
Разработчики узла, с другой стороны, сделали выбор, что ВСЕ ввод / вывод должен быть асинхронным. Благодаря этому решению разработчики узлов также смогли принять решение, что каждый экземпляр узла будет однопоточным, чтобы минимизировать переключение потоков, и что один поток будет просто выполнять код, который был поставлен в очередь. Это может быть новый запрос, это может быть обратный вызов из запроса БД, это может быть обратный вызов из запроса http rest, который вы сделали. Узел пытается максимизировать эффективность процессора, устраняя переключение контекста потока. Поскольку узел сделал этот выборный выбор, что ALL I / O является асинхронным, это также означает, что все его фреймворки / дополнения поддерживают этот выбор. Проще писать приложения, которые на 100% асинхронны в узле (потому что узел заставляет вас писать приложения, которые являются асинхронными).
Опять же, у меня нет точных цифр, чтобы доказать, так или иначе, но я думаю, что узел выиграет конкурс LOAD для типичного веб-приложения. Сильно оптимизированное (100% асинхронное) приложение .NET может дать эквивалентное приложение node.js за свои деньги, но если вы взяли среднее значение всех .NET и всех приложений для узлов, то в среднем узел, вероятно, обрабатывает больше НАГРУЗКИ.
Надеюсь, это поможет.