Node.js의 이벤트 중심의 차이점은 무엇입니까? ASP.Net의 HttpAsyncHandler에서 그렇게 할 수 없습니까?
저는 웹 프로그래밍 경험이 많지 않으며 실제로 Node.js에서 실제로 코딩 한 적이 없으며 이벤트 기반 접근 방식에 대해 궁금합니다 . 좋은 것 같습니다.
이 기사에서는 스레드 기반 접근 방식을 사용하여 요청을 처리 할 때 발생할 수있는 몇 가지 나쁜 일을 설명하고 대신 이벤트 기반 접근 방식을 선택해야합니다. 스레드 기반에서 계산원 / 스레드는 음식 / 자원이 준비 될 때까지 우리와 붙어 있습니다. 이벤트 중심에서 계산원은 요청 대기열의 어딘가에 우리를 보내므로 음식을 기다리는 동안 다른 요청을 차단하지 않습니다. 블로킹 스레드 기반을 확장하려면 스레드 수를 늘려야합니다. 나에게 이것은 스레드 / 스레드 풀을 올바르게 사용하지 않는 것에 대한 나쁜 변명처럼 보입니다.
IHttpAsyncHandler를 사용하여 제대로 처리 할 수 없습니까? ASP.Net은 요청을 받고 ThreadPool을 사용하고 핸들러 (BeginProcessRequest)를 실행 한 다음 그 안에서 콜백을 사용하여 파일 / 데이터베이스를로드합니다. 그러면 해당 스레드는 다른 요청을 처리 할 수 있어야합니다. 파일 읽기가 완료되면 ThreadPool이 다시 호출되어 나머지 응답을 실행합니다. 나에게 그렇게 다르지 않은데 왜 확장 성이 떨어질까요?
내가 아는 스레드 기반의 단점 중 하나는 스레드를 사용하는 데 더 많은 메모리가 필요하다는 것입니다. 그러나 이것으로 만 다중 코어의 이점을 누릴 수 있습니다. Node.js가 스레드 / 코어를 전혀 사용하지 않는 것 같습니다.
따라서 이벤트 기반 대 스레드 기반 ( "Javascript 및 모든 브라우저이기 때문에 ..."인수를 가져 오지 마십시오)을 기반으로 누군가가 대신 Node.js를 사용하는 실제 이점이 무엇인지 지적 할 수 있습니다. 기존 기술?
긴 질문이었습니다. 감사 :)
우선 Node.js는 다중 스레드가 아닙니다. 이것은 중요하다. 스레드 환경에서 완벽하게 작동하는 프로그램을 설계하려면 매우 재능있는 프로그래머 여야합니다. 스레드는 어렵습니다.
제대로 설계되지 않은 스레드 프로젝트를 유지하려면 신이 되어야합니다 . 매우 큰 프로젝트에서는 피할 수없는 문제가 너무 많습니다.
둘째, 전체 플랫폼이 비동기 적으로 실행되도록 설계되었습니다. 모든 단일 IO 상호 작용이 비동기적인 ASP.NET 프로젝트를 보셨습니까? 간단히 말해서 ASP.NET은 이벤트 기반으로 설계되지 않았습니다.
그런 다음 열린 연결 당 하나의 스레드가 있고 전체 확장 문제로 인해 메모리 공간이 있습니다. 내가 틀렸다면 수정하지만 ASP.NET에서 각 연결에 대해 새 스레드를 만드는 것을 어떻게 피할 수 있는지 모르겠습니다.
또 다른 문제는 Node.js 요청이 사용되지 않거나 IO를 기다리고있을 때 유휴 상태라는 것입니다. 반면에 C # 스레드는 휴면 상태입니다. 이제 휴면 할 수있는 이러한 스레드 수에 제한이 있습니다. Node.js에서는 하나의 개발 시스템에서 동시에 10k 클라이언트를 병렬로 쉽게 처리 할 수 있습니다. 하나의 개발 머신에서 병렬로 10k 스레드를 처리하려고합니다.
언어로서의 JavaScript 자체는 비동기 코딩을 더 쉽게 만듭니다. 아직 C # 2.0을 사용하고 있다면 비동기 구문이 정말 고통 스럽습니다. 많은 개발자가 콜백을 정의 Action<>하고 Function<>모든 곳에서 사용 하면 혼란스러워 할 것 입니다. 이벤트 방식으로 작성된 ASP.NET 프로젝트는 일반 ASP.NET 개발자가 유지 관리 할 수 없습니다.
스레드와 코어에 관해서. Node.js는 단일 스레드이며 다중 노드 프로세스를 생성하여 확장됩니다. 코어가 16 개인 경우 node.js 서버의 인스턴스 16 개를 실행하고 그 앞에 단일 Node.js로드 밸런서가 있습니다. (원하는 경우 nginx로드 밸런서가 될 수 있습니다).
이 모든 것은 처음부터 매우 낮은 수준에서 플랫폼에 작성되었습니다. 이것은 나중에 추가되는 일부 기능이 아닙니다.
기타 장점
Node.js에는 위에있는 것보다 훨씬 더 많은 것이 있습니다. 위의 이유는 Node.js가 이벤트 루프를 처리하는 방식이 ASP.NET의 비동기 기능을 사용하는 것보다 더 나은 이유 일뿐입니다.
- 공연. 빠르다. 정말 빠릅니다.
- Node.js의 큰 장점 중 하나는 저수준 API입니다. 당신은 많은 통제권을 가지고 있습니다.
- 전체 HTTP 서버를 코드에 직접 통합 한 다음 IIS로 아웃소싱했습니다.
- 전체 nginx와 Apache 비교가 있습니다.
- 전체 C10K 챌린지는 IIS가 아닌 노드별로 잘 처리됩니다.
- AJAX 및 JSON 통신은 자연스럽고 쉽습니다.
- 실시간 커뮤니케이션은 Node.js의 가장 큰 장점 중 하나입니다. 그것을 위해 만들어졌습니다.
- 문서 기반 nosql 데이터베이스와 잘 어울립니다.
- TCP 서버도 실행할 수 있습니다. 파일 쓰기 액세스를 수행 할 수 있으며 서버에서 모든 유닉스 콘솔 명령을 실행할 수 있습니다.
- 예를 들어 CouchDB 및 map / reduce를 사용하여 자바 스크립트로 데이터베이스를 쿼리합니다. 클라이언트는 JavaScript로 작성합니다. 웹 스택에서 개발하는 동안에는 컨텍스트 전환이 없습니다.
- 다양한 커뮤니티 기반 오픈 소스 모듈 세트. node.js의 모든 것은 오픈 소스입니다.
- 설치 공간이 작고 종속성이 거의 없습니다. node.js 소스를 직접 빌드 할 수 있습니다.
Node.js의 단점
어렵습니다. 젊다. A와 숙련 된 자바 스크립트 개발자, 나는 어려움 단지 때문에 낮은 수준의 자연의 Node.js를 가진 웹 사이트와 내가 가진 제어 수준을 쓰기에 직면 해있다. C와 똑같은 느낌입니다. 저를 위해 사용되거나 매달리기 위해 많은 유연성과 힘이 있습니다.
API는 고정되지 않습니다. 빠르게 변화하고 있습니다. 그때까지 Node.js가 변경 될 것이기 때문에 5 년 안에 대규모 웹 사이트를 완전히 다시 작성해야한다고 상상할 수 있습니다. 할 수 있습니다. node.js 웹 사이트의 유지 관리가 저렴하지 않다는 것을 알고 있어야합니다.
추가 읽기
http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
node.js 대 ASP.Net 및 비동기 프로그래밍과 관련하여 많은 오해가 있습니다. ASP.NET에서 비 차단 IO를 수행 할 수 있습니다 . 대부분의 사람들은 .Net 2.0 이상에서 시작 / 종료 패턴을 사용하여 웹 서비스 호출 또는 기타 I / O 바인딩 작업을 수행 할 때 .Net 프레임 워크가 Windows iocompletion 포트를 사용 한다는 사실을 모릅니다 . IO 완료 포트는 Windows 운영 체제가 비 차단 IO를 지원하는 방식이므로 IO 작업이 완료되는 이유를 앱 스레드가 해제됩니다. 흥미롭게도 node.js는 Cygwin을 통해 Windows에서 덜 최적화 된 비 차단 IO 구현을 사용합니다. 새로운 Windows 버전이 로드맵에 있으며, Microsoft의 지침에 따라 IO 완료 포트를 사용할 것입니다. 그 시점에서 차이는 없습니다.
ADO.NET에서 비 차단 데이터베이스 호출을 수행하는 것도 가능하지만 NHibernate 및 Entity Framework와 같은 ORM 도구를 알고 있어야합니다. 그들은 여전히 매우 동 기적입니다.
동기식 IO (차단)는 제어 흐름을 훨씬 더 명확하게하며 이러한 이유로 인기를 얻었습니다. 컴퓨터 환경이 다중 스레드되는 이유는 표면적으로 만 이와 관련이 있습니다. 일반적으로 여러 CPU의 시간 공유 및 활용과 관련이 있습니다.
단일 스레드 만 있으면 긴 작업 중에 기아 상태가 발생할 수 있으며, 이는 IO 및 복잡한 계산과 관련 될 수 있습니다. 따라서 경험의 법칙이 하나의 스레드 pr이지만. 비 차단 IO를 사용할 때, 단순한 요청이 더 복잡한 작업으로 인해 부족해지지 않도록 충분한 스레드 풀 크기를 고려해야합니다. 또한 다중 스레드를 사용하면 복잡한 작업을 여러 CPU간에 쉽게 분할 할 수 있습니다. node.js와 같은 단일 스레드 환경은 작업을 조정하기 위해 더 많은 프로세스와 메시지 전달을 통해서만 멀티 코어 프로세서를 활용할 수 있습니다.
저는 개인적으로 node.js와 같은 추가 기술을 도입해야한다는 강력한 주장을 아직 보지 못했습니다. 그러나 좋은 이유가있을 수 있지만 ASP.NET에서도 수행 할 수 있기 때문에 비 차단 IO를 통해 많은 수의 연결을 서비스하는 것과는 거의 관련이 없습니다.
BTW tamejs는 곧 출시 될 새로운 .Net Async CTP와 유사하게 nodejs 코드를 더 읽기 쉽게 만드는 데 도움이 될 수 있습니다.
It is easy to understate the cultural difference between the Node.js and ASP.NET communities. Sure, IHttpAsyncHandler exists and it's been around since .NET 1.0 so it might even be good, but all of the code and discussion around Node.js is about async I/O which is decidedly not the case when it comes to .NET. Want to use LINQ To SQL? You kind of can, kind of. Want to log stuff? Maybe "CSharp DotNet Logger" will work, maybe.
So yes, IHttpAsyncHandler is there and if you're really careful you might be able to write an event driven web-service without tripping over some blocking I/O somewhere, but I don't really get the impression a lot of people are using it (and it certainly isn't the prominent way for writing ASP.NET apps). In contrast, Node.js is all about evented I/O, all the code examples, all the libraries and it's the only way people are using it. So if you were going to bet on which one's evented I/O model actually worked all the way through, Node.js would probably be the one to pick.
As per current age technology improvements and reading below links, I can say, it is matter of expertise and choosing perfect mix as per the particular scenario that matters. NodeJS is getting mature and ASP.NET side we have ASP.NET MVC, WebAPI, and SignalR etc. to make things better.
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ and
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
Thanks.
'Programing' 카테고리의 다른 글
| Chocolatey와 NuGet의 차이점 (0) | 2020.10.30 |
|---|---|
| C #에서 매일 특정 시간에 메서드를 호출하는 방법은 무엇입니까? (0) | 2020.10.30 |
| Jekyll 및 GitHub 페이지에서 이전 페이지를 리디렉션하는 가장 좋은 방법은 무엇입니까? (0) | 2020.10.30 |
| .bashrc에서 에코 할 때 SCP가 작동하지 않습니까? (0) | 2020.10.30 |
| 다중 값 사전 (0) | 2020.10.29 |