Câu hỏi Làm thế nào để quyết định khi nào nên sử dụng Node.js?


Tôi mới đến loại công cụ này, nhưng gần đây tôi đã nghe rất nhiều về cách tốt Node.js Là. Xem xét số lượng tôi thích làm việc với jQuery và JavaScript nói chung, tôi không thể không tự hỏi làm thế nào để quyết định khi nào nên sử dụng Node.js. Ứng dụng web tôi có trong đầu là một thứ như Bitly - lấy một số nội dung, lưu trữ nó.

Từ tất cả các bài tập về nhà tôi đã làm trong vài ngày qua, tôi đã thu được những thông tin sau đây. Node.js

  • là một công cụ dòng lệnh có thể chạy như một máy chủ web thông thường và cho phép một chương trình chạy JavaScript
  • sử dụng tuyệt vời Công cụ JavaScript V8
  • rất tốt khi bạn cần làm nhiều việc cùng một lúc
  • dựa trên sự kiện để tất cả những điều tuyệt vời Ajaxgiống như các công cụ có thể được thực hiện ở phía máy chủ
  • cho phép chúng tôi chia sẻ mã giữa trình duyệt và chương trình phụ trợ
  • cho phép chúng ta nói chuyện với MySQL

Một số nguồn mà tôi đã gặp phải là:

Xem xét rằng Node.js có thể chạy gần như ngoài hộp EC2 của Amazon các trường hợp, tôi đang cố gắng hiểu loại vấn đề nào cần Node.js như trái ngược với bất kỳ vị vua hùng mạnh nào ngoài kia PHP, Python và Ruby. Tôi hiểu rằng nó thực sự phụ thuộc vào chuyên môn có trên một ngôn ngữ, nhưng câu hỏi của tôi rơi vào thể loại tổng quát hơn: Khi nào sử dụng một khuôn khổ cụ thể và loại vấn đề nào đặc biệt phù hợp?


2200
2018-02-21 05:20


gốc


Câu hỏi này đang được thảo luận về meta (meta.stackoverflow.com/q/332386/497418). - zzzzBov


Các câu trả lời:


Bạn đã làm một công việc tuyệt vời để tóm tắt những điều tuyệt vời về Node.js. Cảm giác của tôi là Node.js đặc biệt thích hợp cho các ứng dụng mà bạn muốn duy trì kết nối liên tục từ trình duyệt quay lại máy chủ. Sử dụng một kỹ thuật được gọi là "bỏ phiếu dài", bạn có thể viết một ứng dụng gửi cập nhật cho người dùng trong thời gian thực. Thực hiện bỏ phiếu dài trên nhiều người khổng lồ trên web, như Viên ngọc trên tay vịn hoặc là Django, sẽ tạo tải lớn trên máy chủ, bởi vì mỗi khách hàng hoạt động ăn lên một quá trình máy chủ. Tình trạng này lên đến một tarpit tấn công. Khi bạn sử dụng một cái gì đó như Node.js, máy chủ không cần duy trì các luồng riêng biệt cho từng kết nối mở.

Điều này có nghĩa là bạn có thể tạo ứng dụng trò chuyện dựa trên trình duyệt trong Node.js hầu như không có tài nguyên hệ thống để phục vụ nhiều khách hàng lớn. Bất cứ lúc nào bạn muốn thực hiện kiểu bỏ phiếu dài này, Node.js là một lựa chọn tuyệt vời.

Điều đáng nói đến là cả Ruby và Python đều có công cụ để làm việc nàyeventmachine và xoắn, tương ứng), nhưng Node.js thực hiện điều đó một cách đặc biệt tốt và từ đầu. JavaScript có vị trí đặc biệt tốt với mô hình đồng thời dựa trên cuộc gọi lại và nó vượt trội ở đây. Ngoài ra, có thể serialize và deserialize với JSON bản địa cho cả khách hàng và máy chủ là khá tiện lợi.

Tôi mong được đọc các câu trả lời khác ở đây, đây là một câu hỏi tuyệt vời.

Thật đáng để chỉ ra rằng Node.js cũng rất tuyệt vời cho các tình huống mà trong đó bạn sẽ sử dụng lại rất nhiều mã trong khoảng trống máy khách / máy chủ. Các Khung Meteor làm cho điều này thực sự dễ dàng và rất nhiều người cho rằng đây có thể là tương lai của phát triển web. Tôi có thể nói từ trải nghiệm thú vị khi viết mã trong Meteor, và một phần lớn trong số này là dành ít thời gian suy nghĩ về cách bạn sắp cấu trúc lại dữ liệu của mình, vì vậy mã có thể chạy trong trình duyệt có thể dễ dàng thao tác và truyền lại.

Dưới đây là một bài viết về Kim tự tháp và bỏ phiếu dài, hóa ra rất dễ dàng để thiết lập với một chút trợ giúp từ gevent: TicTacToe và cuộc thăm dò dài với kim tự tháp.


1359
2018-02-21 05:30



Vâng, tôi nghĩ điều quan trọng là phải nghĩ rằng 'node.js đặc biệt phù hợp với các ứng dụng yêu cầu kết nối liên tục từ trình duyệt quay lại máy chủ. - chẳng hạn như các chương trình trò chuyện, hoặc các trò chơi tương tác 'Nếu một người chỉ xây dựng một ứng dụng không nhất thiết cần đến giao tiếp người dùng / máy chủ, việc phát triển với các khung công tác khác sẽ tốt và sẽ mất ít thời gian hơn nhiều. - user482594
Cảm ơn vì điều này ... Great Q và A ;-) Tôi cũng nghĩ về nó trong việc nắm vững một công nghệ tuyệt vời cho cả phát triển trước và sau trên một vài cái khác nhau;) - Stokedout
Tại sao sử dụng phiếu thăm dò ý kiến ​​dài? Điều gì đã xảy ra cho tương lai và ổ cắm? - hitautodestruct
Câu trả lời ngắn của tôi là quá trình nền. Yêu cầu và đáp ứng (bao gồm cả API còn lại) tất cả có thể đạt được với bất kỳ ngôn ngữ và máy chủ nào khác. Vì vậy, đối với những người đang suy nghĩ để chuyển đổi các dự án web của họ trong nút. Hãy nghĩ lại điều tương tự! Sử dụng nút làm quá trình nền như đọc email với imap, xử lý hình ảnh, tải tệp lên đám mây hoặc bất kỳ quá trình dài hoặc không bao giờ kết thúc nào chủ yếu là theo định hướng sự kiện ... - Vikas


Tôi tin Node.js phù hợp nhất với các ứng dụng thời gian thực: trò chơi trực tuyến, công cụ cộng tác, phòng trò chuyện hoặc bất kỳ thứ gì mà một người dùng (hoặc rô-bô? Hoặc cảm biến?) Thực hiện với ứng dụng cần được người dùng khác xem ngay lập tức, mà không cần làm mới trang.

Tôi cũng nên đề cập đến rằng Socket.IO kết hợp với Node.js sẽ giảm độ trễ thời gian thực của bạn thậm chí xa hơn so với những gì có thể với việc bỏ phiếu dài. Socket.IO sẽ quay trở lại trạng thái bỏ phiếu dài như trường hợp xấu nhất và thay vào đó sử dụng ổ cắm web hoặc thậm chí là Flash nếu chúng có sẵn.

Nhưng tôi cũng nên đề cập đến rằng chỉ là về bất kỳ tình huống mà mã có thể chặn do các chủ đề có thể được giải quyết tốt hơn với Node.js. Hoặc bất kỳ tình huống nào bạn cần ứng dụng được điều khiển theo sự kiện.

Ngoài ra, Ryan Dahl nói trong một cuộc nói chuyện rằng tôi đã từng tham dự rằng các tiêu chuẩn Node.js chặt chẽ đối thủ Nginx cho các yêu cầu HTTP cũ thường xuyên. Vì vậy, nếu chúng ta xây dựng với Node.js, chúng ta có thể phục vụ các tài nguyên thông thường của chúng ta khá hiệu quả, và khi chúng ta cần các công cụ hướng sự kiện, nó đã sẵn sàng để xử lý nó.

Thêm vào đó là tất cả JavaScript mọi lúc. Lingua Franca trên toàn bộ ngăn xếp.


410
2018-02-21 06:43



Chỉ cần một quan sát từ một ai đó chuyển đổi giữa. Net và Node, Các ngôn ngữ khác nhau cho các khu vực khác nhau của hệ thống sẽ giúp ích rất nhiều khi chuyển ngữ cảnh. Khi tôi đang xem Javascript, tôi đang làm việc trong Máy khách, C # có nghĩa là Máy chủ ứng dụng, Cơ sở dữ liệu SQL =. Làm việc trong Javascript trong suốt, tôi thấy mình bối rối các lớp, hoặc đơn giản là mất nhiều thời gian hơn để chuyển ngữ cảnh. Đây có thể là một hiện vật làm việc trên .NET stack cả ngày và Noding vào ban đêm, nhưng nó tạo nên sự khác biệt. - Michael Blackburn
Thật thú vị, việc thực hành các cá nhân đa văn hóa chuyển đổi phương ngữ khi di chuyển giữa các nền văn hóa chính thống và bản địa được gọi là "chuyển đổi mã". - Michael Blackburn
Mới hôm nọ tôi đang nghĩ về việc làm thế nào tôi có thể đi về việc gán màu sắc khác nhau cho .js các tập tin bằng cách nào đó. Màu xanh lá cây cho phía máy khách, màu xanh cho phía máy chủ. Tôi tiếp tục bị "mất" bản thân mình. - AJB
Câu trả lời hay nhất. Ví dụ node.js là tuyệt vời cho peer to peer. - cpugourou


Lý do sử dụng NodeJS:

  • Nó chạy Javascript, vì vậy bạn có thể sử dụng cùng ngôn ngữ trên máy chủ và máy khách và thậm chí chia sẻ một số mã giữa chúng (ví dụ: để xác thực biểu mẫu hoặc để hiển thị chế độ xem ở hai đầu.)

  • Các đơn luồng hệ thống hướng sự kiện là Nhanh ngay cả khi xử lý nhiều yêu cầu cùng một lúc, và cũng đơn giản, so với đa luồng truyền thống Java hoặc khung ROR.

  • Hồ bơi ngày càng tăng của gói có thể truy cập thông qua NPM, bao gồm thư viện / mô-đun máy khách và máy chủ, cũng như các công cụ dòng lệnh để phát triển web. Hầu hết chúng được lưu trữ thuận tiện trên github, nơi đôi khi bạn có thể báo cáo một vấn đề và tìm thấy nó cố định trong vòng vài giờ! Thật tuyệt khi có mọi thứ dưới một mái nhà, với báo cáo vấn đề chuẩn hóa và dễ dàng gây khó khăn.

  • Nó đã trở thành môi trường tiêu chuẩn defacto để chạy Công cụ liên quan đến Javascript và khác công cụ liên quan đến web, bao gồm cả người chạy nhiệm vụ, người khai thác, người làm đẹp, linters, preprocessor, bundlers và bộ xử lý phân tích.

  • Nó có vẻ khá thích hợp cho việc tạo mẫu, phát triển nhanh và lặp lại sản phẩm nhanh chóng.

Lý do không phải để sử dụng NodeJS:

  • Nó chạy Javascript, không kiểm tra kiểu biên dịch. Đối với lớn, phức tạp an toàn quan trọng các hệ thống hoặc dự án bao gồm sự cộng tác giữa các tổ chức khác nhau, một ngôn ngữ khuyến khích giao diện hợp đồng và cung cấp kiểm tra kiểu tĩnh có thể giúp bạn tiết kiệm thời gian gỡ lỗi (và vụ nổ) về lâu dài. (Mặc dù JVM bị mắc kẹt với null, vì vậy hãy sử dụng Haskell cho lò phản ứng hạt nhân của bạn.)

  • Thêm vào đó, nhiều gói trong NPM là một chút thô tụcvà vẫn đang trong quá trình phát triển nhanh chóng. Một số thư viện cho các khung cũ hơn đã trải qua một thập kỷ thử nghiệm và sửa lỗi, và rất ổn định bây giờ. Npmjs.org không có cơ chế để xếp hạng các gói, điều này đã dẫn đến sự gia tăng của các gói làm nhiều hơn hoặc ít hơn cùng một điều, trong đó một tỷ lệ phần trăm lớn không còn được duy trì.

  • Địa ngục gọi lại lồng nhau. (Tất nhiên là có 20 giải pháp khác nhau này ...)

  • Gói các gói ngày càng phát triển có thể làm cho một dự án NodeJS xuất hiện hoàn toàn khác từ kế tiếp. Có sự đa dạng lớn trong việc triển khai do có rất nhiều tùy chọn sẵn có (ví dụ: Express /Sails.js/Sao băng/Derby). Điều này đôi khi có thể gây khó khăn cho một nhà phát triển mới để nhảy vào một dự án Node. Tương phản với một Đường ray nhà phát triển tham gia dự án hiện tại: anh ấy có thể làm quen với ứng dụng khá nhanh chóng, vì tất cả ứng dụng Rails đều được khuyến khích sử dụng cấu trúc tương tự.

  • Đối phó với các tập tin có thể là một chút đau đớn. Những thứ không quan trọng bằng các ngôn ngữ khác, như đọc một dòng từ một tệp văn bản, là đủ lạ để làm với Node.js rằng có một câu hỏi StackOverflow trên đó với 80 + upvotes. Có không có cách nào đơn giản để đọc một bản ghi tại một thời điểm từ một tệp CSV. Vv

Tôi yêu NodeJS, nó rất nhanh và hoang dã và thú vị, nhưng tôi lo ngại nó có ít sự quan tâm đến tính chính xác. Hãy hy vọng chúng ta cuối cùng có thể hợp nhất tốt nhất của cả hai thế giới. Tôi háo hức muốn xem điều gì sẽ thay thế Node trong tương lai ... :)


209
2017-11-25 21:47



@nane Có, tôi nghĩ rằng họ có thể giải quyết vấn đề đó, tuy nhiên bạn phải giới hạn bản thân chỉ sử dụng thư viện được viết bằng ngôn ngữ không an toàn hoặc chấp nhận tất cả các codebase của bạn được nhập tĩnh. Nhưng một cuộc tranh luận đi: vì bạn nên viết kiểm tra tốt cho mã của bạn bất kể ngôn ngữ, sau đó là mức độ tin cậy nên bằng nhau ngay cả đối với mã được nhập động. Nếu chúng ta chấp nhận lập luận đó, thì lợi thế của việc gõ mạnh sẽ giảm xuống để hỗ trợ việc phát triển / gỡ lỗi thời gian, tính khả thi và tối ưu hóa. - joeytwiddle
@ kervin, tôi đồng ý một số điểm chuẩn sẽ là tuyệt vời, nhưng tôi đã thất vọng với những gì tôi có thể tìm thấy trực tuyến. Một số người đã lập luận rằng hiệu suất .NET là có thể so sánh với Node, nhưng đó là điều quan trọng bạn đang thực sự làm. Nút có thể là tuyệt vời trong việc cung cấp các thông điệp nhỏ với nhiều kết nối đồng thời, nhưng không quá lớn cho các phép tính toán học nặng. Một so sánh hiệu suất tốt sẽ cần phải kiểm tra một loạt các tình huống. - joeytwiddle
@joeytwiddle sẽ không phải những thứ như Typescript giúp Node.js khi nói đến việc xử lý các chương trình phức tạp hơn và đánh máy tĩnh? - CodeMonkey
@joeytwiddle cho những gì nó có giá trị, bạn có thể sử dụng stillmaintained.com để xác định xem gói npm có được duy trì hay không (vì phần lớn là trên github). Ngoài ra, npm search và npm show sẽ cho bạn thấy ngày phát hành cuối cùng của một gói. - Dan Pantry
Bằng cách so sánh đường ray với nút, bạn đang nhầm lẫn một nền tảng với một khung công tác. Rails là một framework cho Ruby giống như Sails và meteor là các framework cho Javascript. - BonsaiOak


Để làm cho nó ngắn gọn:

Node.js rất thích hợp cho các ứng dụng có nhiều kết nối đồng thời và mỗi yêu cầu chỉ cần rất ít chu trình CPU, bởi vì vòng lặp sự kiện (với tất cả các máy khách khác) bị chặn trong khi thực hiện một hàm.

Một bài viết hay về vòng lặp sự kiện trong Node.js là Blog công nghệ của Mixu: Hiểu vòng lặp sự kiện node.js.


208
2018-01-15 01:48





Tôi có một ví dụ trong thế giới thực, nơi tôi đã sử dụng Node.js. Công ty nơi tôi làm việc có một khách hàng muốn có một trang web HTML tĩnh đơn giản. Trang web này là để bán một mặt hàng bằng cách sử dụng PayPal và khách hàng cũng muốn có một bộ đếm hiển thị số lượng mặt hàng đã bán. Khách hàng dự kiến ​​sẽ có số lượng lớn khách truy cập vào trang web này. Tôi quyết định tạo bộ đếm bằng Node.js và Express.js khuôn khổ.

Ứng dụng Node.js rất đơn giản. Nhận số lượng mặt hàng đã bán từ một Redis cơ sở dữ liệu, tăng bộ đếm khi mục được bán và phân phối giá trị bộ đếm cho người dùng thông qua API.

Một số lý do tại sao tôi chọn sử dụng Node.js trong trường hợp này

  1. Nó rất nhẹ và nhanh. Đã có hơn 200.000 lượt truy cập trên trang web này trong ba tuần và tài nguyên máy chủ tối thiểu đã có thể xử lý tất cả.
  2. Bộ đếm thực sự dễ làm cho thời gian thực.
  3. Node.js dễ cấu hình.
  4. Có rất nhiều mô-đun có sẵn miễn phí. Ví dụ, tôi tìm thấy một mô-đun Node.js cho PayPal.

Trong trường hợp này, Node.js là một lựa chọn tuyệt vời.


127
2018-05-31 06:34



Làm thế nào để bạn lưu trữ một cái gì đó như thế? Bạn có phải thiết lập nodejs trên máy chủ sản xuất không? Trong linux? - Notflip
Có một vài PaaS như nodejitsu và Heroku. Hoặc bạn thực sự có thể thiết lập nodejs trên một hộp linux tức là từ amazon ec2. xem: lauradhamilton.com/… - Sam Ames
200.000 lượt truy cập trong vòng 1,814,400 giây. Không liên quan chút nào. Ngay cả bash cũng có thể phục vụ nhiều yêu cầu, trên máy chủ chậm nhất. Máy chủ cào. VM chậm nhất. - Tiberiu-Ionuț Stan


Những lý do quan trọng nhất để bắt đầu dự án tiếp theo của bạn bằng cách sử dụng Node ...

  • Tất cả các dudes thú vị nhất là vào nó ... vì vậy nó phải hãy vui vẻ.
  • Bạn có thể hangout tại nơi làm mát và có rất nhiều cuộc phiêu lưu của Node để khoe khoang.
  • Bạn là một pincher penny khi nói đến chi phí lưu trữ đám mây.
  • Đã làm điều đó với Rails
  • Bạn ghét triển khai IIS
  • Công việc CNTT cũ của bạn ngày càng trở nên buồn tẻ và bạn muốn bạn có một Start Up mới sáng bóng.

Điều gì sẽ xảy ra ...

  • Bạn sẽ cảm thấy an toàn và an toàn với Express mà không cần tất cả các bloatware máy chủ mà bạn không bao giờ cần.
  • Chạy như một tên lửa và vảy tốt.
  • Bạn mơ ước nó. Bạn đã cài đặt nó. Gói repo của nút npmjs.org là hệ sinh thái lớn nhất của các thư viện nguồn mở trên thế giới.
  • Bộ não của bạn sẽ bị bóp méo thời gian trong vùng đất của những cuộc gọi lại lồng nhau ...
  • ... cho đến khi bạn học cách giữ Hứa hẹn.
  • Sắp xếp lại và Hộ chiếu là những người bạn API mới của bạn.
  • Gỡ lỗi phần lớn mã không đồng bộ sẽ nhận được umm ... hấp dẫn .
  • Thời gian cho tất cả các Noders để làm chủ Chữ viết.

Ai sử dụng nó?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • Đây là lý do họ chuyển sang nút.

105
2018-06-12 13:24



Có, tôi có thể trả lời câu hỏi này theo cách truyền thống. Tôi nghĩ rằng tôi đủ điều kiện để làm như vậy nhưng hầu hết nó đã được nói và tôi nghĩ rằng một số vui vẻ nhẹ nhàng trái tim sẽ phá vỡ sự đơn điệu. Tôi thường xuyên đóng góp các câu trả lời kỹ thuật cho các câu hỏi khác. - Tony O'Hagan
+1 "Gỡ lỗi phần lớn mã không đồng bộ sẽ nhận được umm ... thú vị". - Jackson
các callback lồng nhau có thể tránh được bằng cách sử dụng các trình tạo ES6 cho mã async - refactor
@CleanCrispCode: Có thực sự! ES6 đã áp dụng kiểu C # async/await vì vậy bây giờ chúng tôi có thể tung ra nhiều mã async Node sạch hơn cũng hỗ trợ truyền thống try/catch. Trong năm 2016/17, các lập trình viên JS đang chuyển sang ES6. - Tony O'Hagan
mười nghìn lần điều này "Bạn sẽ cảm thấy an toàn và an toàn với Express mà không cần tất cả các bloatware máy chủ bạn không bao giờ cần" - Simone Poggi


Không có gì giống như Silver Bullet. Tất cả mọi thứ đi kèm với một số chi phí liên quan đến nó. Nó giống như nếu bạn ăn thức ăn nhiều dầu, bạn sẽ thỏa hiệp sức khỏe của bạn và thực phẩm lành mạnh không đi kèm với các loại gia vị như thức ăn có dầu. Đó là sự lựa chọn cá nhân cho dù họ muốn sức khỏe hoặc gia vị như trong thực phẩm của họ. Giống như cách Node.js xem xét để được sử dụng trong kịch bản cụ thể. Nếu ứng dụng của bạn không phù hợp với kịch bản đó, bạn không nên xem xét nó để phát triển ứng dụng của mình. Tôi chỉ đang đặt suy nghĩ của tôi trên cùng một:

Khi nào sử dụng Node.JS

  1. Nếu mã phía máy chủ của bạn yêu cầu rất ít chu kỳ CPU. Trong thế giới khác, bạn đang thực hiện thao tác không chặn và không có thuật toán / công việc nặng mà tiêu thụ rất nhiều chu kỳ CPU.
  2. Nếu bạn từ Javascript trở lại mặt đất và thoải mái bằng văn bản mã Single Threaded giống như JS phía khách hàng.

Khi KHÔNG sử dụng Node.JS

  1. Yêu cầu máy chủ của bạn phụ thuộc vào thuật toán / công việc tiêu thụ CPU nặng.

Xem xét khả năng mở rộng với Node.JS

  1. Bản thân Node.JS không sử dụng tất cả các lõi của hệ thống cơ sở và nó là một luồng đơn theo mặc định, bạn phải tự viết logic của mình để sử dụng bộ xử lý đa nhân và làm cho nó đa luồng.

Các lựa chọn thay thế của Node.JS

Có tùy chọn khác để sử dụng thay cho Node.JS Vert.x có vẻ khá hứa hẹn và có nhiều tính năng bổ sung như cân nhắc đa giác và khả năng mở rộng tốt hơn.


60
2018-04-05 17:17



Tôi không chắc chắn về "Nếu yêu cầu bên máy chủ của bạn bao gồm chặn các ops như File IO hoặc Socket IO" được liệt kê trong "Khi KHÔNG sử dụng". Nếu hiểu biết của tôi là đúng, một trong những điểm mạnh của node.js là nó có phương tiện mạnh mẽ để xử lý IO mà không bị chặn. Vì vậy, Node.js có thể được xem như là "một cách chữa trị" để chặn IO. - Ondra Peterka
@OndraPeterka: Bạn nói đúng rằng Node.js là cách để chặn máy chủ IO, tuy nhiên nếu trình xử lý yêu cầu của bạn trên máy chủ tự thực hiện cuộc gọi chặn đến một số dịch vụ web / thao tác tệp khác, Node.js sẽ không trợ giúp ở đây. Nó không chặn IO chỉ cho các yêu cầu gửi đến máy chủ nhưng không phải cho yêu cầu gửi đi từ trình xử lý yêu cầu ứng dụng của bạn. - ajay
@ajay từ nodejs.org họ nói "không bị chặn I / O", vui lòng kiểm tra "Khi KHÔNG" 2 và 3. - Omar Al-Ithawi
với phiên bản hiện tại, nút thực sự hỗ trợ hỗ trợ đa lõi bằng cách sử dụng cụm. Điều này thực sự thúc đẩy hiệu suất ứng dụng Node ít nhất hai lần. Tuy nhiên, tôi nghĩ rằng hiệu suất nên được nhiều hơn hai lần khi họ stablize cụm lib. - Nam Nguyen
Bạn có thể sử dụng node.js để tính toán nặng. Sử dụng fork. Xem stackoverflow.com/questions/9546225/…. Nút xử lý nhiều lõi rất tốt với cluster mô-đun. nodejs.org/api/cluster.html - Jess