Node.js vốn đã nhanh hơn như thế nào khi nó vẫn dựa vào Chủ đề trong nội bộ?

Tôi vừa xem video sau: Giới thiệu về Node.js và vẫn không hiểu làm thế nào bạn có được lợi ích tốc độ.

Chủ yếu, tại một thời điểm Ryan Dahl (người tạo ra Node.js) nói rằng Node.js dựa trên vòng lặp sự kiện thay vì dựa trên luồng. Các chủ đề rất tốn kém và chỉ nên để các chuyên gia lập trình đồng thời được sử dụng.

Sau đó, anh ta cho thấy chồng kiến ​​trúc của Node.js có triển khai C bên dưới có nhóm Thread riêng trong nội bộ. Vì vậy, rõ ràng các nhà phát triển Node.js sẽ không bao giờ khởi động các luồng của riêng họ hoặc sử dụng nhóm luồng trực tiếp ... họ sử dụng các cuộc gọi lại không đồng bộ. Điều đó nhiều tôi hiểu.

Điều tôi không hiểu là điểm mà Node.js vẫn đang sử dụng các luồng ... nó chỉ ẩn việc triển khai, làm thế nào nhanh hơn nếu 50 người yêu cầu 50 tệp (hiện không có trong bộ nhớ) thì không cần 50 luồng ?

Sự khác biệt duy nhất là vì nó được quản lý nội bộ, nhà phát triển Node.js không phải mã hóa các chi tiết luồng nhưng bên dưới nó vẫn sử dụng các luồng để xử lý các yêu cầu tệp IO (chặn).

Vì vậy, không phải bạn thực sự chỉ lấy một vấn đề (luồng) và ẩn nó trong khi vấn đề đó vẫn tồn tại: chủ yếu là nhiều luồng, chuyển ngữ cảnh, khóa chết ... vv?

Phải có một số chi tiết tôi vẫn không hiểu ở đây.

Thực tế có một vài điều khác nhau đang bị giam cầm ở đây. Nhưng nó bắt đầu với meme rằng các chủ đề chỉ thực sự khó khăn. Vì vậy, nếu chúng khó, nhiều khả năng, khi sử dụng các luồng đến 1) bị hỏng do lỗi và 2) không sử dụng chúng hiệu quả nhất có thể. (2) là một trong những bạn đang hỏi về.

Hãy suy nghĩ về một trong những ví dụ anh ấy đưa ra, nơi yêu cầu đến và bạn chạy một số truy vấn, và sau đó làm một cái gì đó với kết quả của điều đó. Nếu bạn viết nó theo cách thủ tục tiêu chuẩn, mã có thể trông như thế này:

result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );

Nếu yêu cầu đến khiến bạn tạo một luồng mới chạy mã ở trên, bạn sẽ có một luồng đang ngồi ở đó, không làm gì cả trong khi query()đang chạy. (Apache, theo Ryan, đang sử dụng một luồng duy nhất để đáp ứng yêu cầu ban đầu trong khi nginx đang vượt trội hơn nó trong các trường hợp mà anh ta đang nói đến vì không phải vậy.)

Bây giờ, nếu bạn thực sự thông minh, bạn sẽ thể hiện mã ở trên theo cách mà môi trường có thể tắt và làm một cái gì đó khác trong khi bạn đang chạy truy vấn:

query( statement: "select smurfs from some_mushroom", callback: go_do_something_with_result() );

Đây là cơ bản những gì node.js đang làm. Về cơ bản, bạn đang trang trí - theo cách thuận tiện vì ngôn ngữ và môi trường, do đó, các điểm về việc đóng cửa - mã của bạn theo cách mà môi trường có thể thông minh về những gì chạy và khi nào. Theo cách đó, node.js không mới theo nghĩa là nó đã phát minh ra I / O không đồng bộ (không phải ai cũng tuyên bố bất cứ điều gì như thế này), nhưng nó mới ở cách nó thể hiện hơi khác một chút.

Lưu ý: khi tôi nói rằng môi trường có thể thông minh về những gì chạy và khi nào, cụ thể điều tôi muốn nói là luồng mà nó sử dụng để bắt đầu một số I / O bây giờ có thể được sử dụng để xử lý một số yêu cầu khác hoặc một số tính toán có thể được thực hiện song song, hoặc bắt đầu một số I / O song song khác. (Tôi không chắc nút nào đủ tinh vi để bắt đầu nhiều công việc hơn cho cùng một yêu cầu, nhưng bạn hiểu ý.)

Ghi chú! Đây là một câu trả lời cũ. Mặc dù nó vẫn đúng trong phác thảo sơ bộ, một số chi tiết có thể đã thay đổi do sự phát triển nhanh chóng của Node trong vài năm qua.

Nó đang sử dụng các chủ đề bởi vì:

1. Các tùy chọn O_NONBLOCK của open () không hoạt động trên các tập tin .
2. Có thư viện của bên thứ ba không cung cấp IO không chặn.

Để giả mạo IO không chặn, các luồng là không cần thiết: hãy chặn IO trong một luồng riêng. Đó là một giải pháp xấu xí và gây ra nhiều chi phí.

Nó thậm chí còn tồi tệ hơn ở cấp độ phần cứng:

• Với DMA , CPU giảm tải không đồng bộ IO.
• Dữ liệu được truyền trực tiếp giữa thiết bị IO và bộ nhớ.
• Hạt nhân kết thúc điều này trong một cuộc gọi hệ thống đồng bộ, chặn.
• Node.js kết thúc cuộc gọi hệ thống chặn trong một luồng.

Điều này chỉ đơn giản là ngu ngốc và không hiệu quả. Nhưng nó hoạt động ít nhất! Chúng ta có thể thưởng thức Node.js vì nó ẩn các chi tiết xấu xí và cồng kềnh đằng sau một kiến ​​trúc không đồng bộ hướng sự kiện.

Có lẽ ai đó sẽ triển khai O_NONBLOCK cho các tệp trong tương lai? ...

Chỉnh sửa: Tôi đã thảo luận điều này với một người bạn và anh ta nói với tôi rằng một chủ đề thay thế đang bỏ phiếu với select : chỉ định thời gian chờ là 0 và thực hiện IO trên các mô tả tệp được trả về (bây giờ chúng được đảm bảo không chặn).

Tôi sợ tôi "làm sai" ở đây, nếu vậy hãy xóa tôi và tôi xin lỗi. Cụ thể, tôi không thấy cách tôi tạo các chú thích nhỏ gọn mà một số người đã tạo. Tuy nhiên, tôi có nhiều mối quan tâm / quan sát để thực hiện về chủ đề này.

1) Phần tử nhận xét trong mã giả trong một trong những câu trả lời phổ biến

result = query( "select smurfs from some_mushroom" );
// twiddle fingers
go_do_something_with_result( result );

thực chất là không có thật. Nếu luồng là điện toán, thì nó không phải là ngón tay cái, nó đang làm việc cần thiết. Mặt khác, nếu chỉ chờ đợi hoàn thành IO, thì nó không sử dụng thời gian của CPU, toàn bộ cơ sở hạ tầng điều khiển luồng trong kernel là CPU sẽ tìm ra thứ gì đó hữu ích để làm. Cách duy nhất để "xoay ngón tay cái" như được đề xuất ở đây là tạo ra một vòng bỏ phiếu và không ai đã mã hóa một máy chủ web thực sự là đủ để làm điều đó.

2) "Chủ đề khó", chỉ có ý nghĩa trong bối cảnh chia sẻ dữ liệu. Nếu bạn có các luồng độc lập cơ bản như trường hợp khi xử lý các yêu cầu web độc lập, thì việc phân luồng rất đơn giản, bạn chỉ cần mã hóa luồng tuyến tính về cách xử lý một công việc và ngồi yên khi biết rằng nó sẽ xử lý nhiều yêu cầu và mỗi yêu cầu sẽ độc lập hiệu quả. Cá nhân, tôi sẽ mạo hiểm rằng đối với hầu hết các lập trình viên, việc học cơ chế đóng / gọi lại phức tạp hơn đơn giản là mã hóa phiên bản luồng từ trên xuống dưới. (Nhưng vâng, nếu bạn phải giao tiếp giữa các luồng, cuộc sống trở nên rất khó khăn rất nhanh, nhưng sau đó tôi không tin rằng cơ chế đóng / gọi lại thực sự thay đổi điều đó, nó chỉ giới hạn các tùy chọn của bạn, bởi vì cách tiếp cận này vẫn có thể đạt được với các luồng Dù sao đi nữa, đó '

3) Cho đến nay, không ai đưa ra bất kỳ bằng chứng thực tế nào về lý do tại sao một loại chuyển đổi ngữ cảnh cụ thể sẽ tốn ít nhiều thời gian hơn bất kỳ loại nào khác. Kinh nghiệm của tôi trong việc tạo các hạt nhân đa tác vụ (ở quy mô nhỏ cho các bộ điều khiển nhúng, không có gì lạ mắt như HĐH "thực") cho thấy rằng điều này sẽ không xảy ra.

4) Tất cả các hình minh họa mà tôi đã thấy cho đến nay có ý nghĩa cho thấy Node nhanh hơn bao nhiêu so với các máy chủ web khác bị thiếu sót một cách khủng khiếp, tuy nhiên, chúng bị khiếm khuyết theo cách gián tiếp minh họa cho một lợi thế mà tôi chắc chắn sẽ chấp nhận cho Node (và nó không có nghĩa là không đáng kể). Node không giống như nó cần (thậm chí không cho phép, thực sự) điều chỉnh. Nếu bạn có một mô hình luồng, bạn cần tạo đủ các luồng để xử lý tải dự kiến. Làm điều này tồi tệ, và bạn sẽ kết thúc với hiệu suất kém. Nếu có quá ít luồng, thì CPU không hoạt động, nhưng không thể chấp nhận nhiều yêu cầu hơn, tạo quá nhiều luồng và bạn sẽ lãng phí bộ nhớ kernel và trong trường hợp môi trường Java, bạn cũng sẽ lãng phí bộ nhớ heap chính . Bây giờ, đối với Java, lãng phí heap là cách đầu tiên, tốt nhất, để tăng hiệu năng của hệ thống, bởi vì bộ sưu tập rác hiệu quả (hiện tại, điều này có thể thay đổi với G1, nhưng có vẻ như ban giám khảo vẫn chưa kết thúc vào thời điểm đó vào đầu năm 2013) phụ thuộc vào việc có rất nhiều đống dự phòng. Vì vậy, có vấn đề, điều chỉnh nó với quá ít luồng, bạn có CPU nhàn rỗi và thông lượng kém, điều chỉnh nó với quá nhiều, và nó sa lầy theo những cách khác.

5) Có một cách khác để tôi chấp nhận logic của tuyên bố rằng cách tiếp cận của Node "nhanh hơn theo thiết kế", và đó là điều này. Hầu hết các mô hình luồng sử dụng mô hình chuyển đổi ngữ cảnh được cắt theo thời gian, xếp chồng lên trên mô hình ưu tiên (cảnh báo phán đoán giá trị :) phù hợp hơn và hiệu quả hơn (không phải là phán đoán giá trị). Điều này xảy ra vì hai lý do, thứ nhất, hầu hết các lập trình viên dường như không hiểu quyền ưu tiên và thứ hai, nếu bạn học phân luồng trong môi trường windows, thời gian sẽ ở đó dù bạn có thích hay không (tất nhiên, điều này củng cố điểm đầu tiên ; đáng chú ý, các phiên bản đầu tiên của Java đã sử dụng quyền ưu tiên ưu tiên cho các triển khai Solaris và thời gian trong Windows. Bởi vì hầu hết các lập trình viên không hiểu và phàn nàn rằng "luồng không hoạt động trong Solaris" họ đã thay đổi mô hình thành thời gian ở khắp mọi nơi). Dù sao, điểm mấu chốt là thời gian tạo ra các chuyển đổi bối cảnh bổ sung (và có thể không cần thiết). Mọi chuyển đổi ngữ cảnh đều mất thời gian của CPU và thời gian đó được loại bỏ một cách hiệu quả khỏi công việc có thể thực hiện trong công việc thực tế. Tuy nhiên, lượng thời gian đầu tư vào chuyển đổi ngữ cảnh vì thời gian không nên nhiều hơn một tỷ lệ rất nhỏ trong tổng thời gian, trừ khi có điều gì đó kỳ quặc đang xảy ra, và không có lý do gì tôi có thể thấy rằng đó là trường hợp trong máy chủ web đơn giản). Vì vậy, vâng, các chuyển đổi ngữ cảnh dư thừa liên quan đến thời gian là không hiệu quả (và những điều này không xảy ra trong và thời gian đó được loại bỏ một cách hiệu quả khỏi công việc có thể được thực hiện trên công việc thực tế trong tay. Tuy nhiên, lượng thời gian đầu tư vào chuyển đổi ngữ cảnh vì thời gian không nên nhiều hơn một tỷ lệ rất nhỏ trong tổng thời gian, trừ khi có điều gì đó kỳ quặc đang xảy ra, và không có lý do gì tôi có thể thấy rằng đó là trường hợp trong máy chủ web đơn giản). Vì vậy, vâng, các chuyển đổi ngữ cảnh dư thừa liên quan đến thời gian là không hiệu quả (và những điều này không xảy ra trong và thời gian đó được loại bỏ một cách hiệu quả khỏi công việc có thể được thực hiện trên công việc thực tế trong tay. Tuy nhiên, lượng thời gian đầu tư vào chuyển đổi ngữ cảnh vì thời gian không nên nhiều hơn một tỷ lệ rất nhỏ trong tổng thời gian, trừ khi có điều gì đó kỳ quặc đang xảy ra, và không có lý do gì tôi có thể thấy rằng đó là trường hợp trong máy chủ web đơn giản). Vì vậy, vâng, các chuyển đổi ngữ cảnh dư thừa liên quan đến thời gian là không hiệu quả (và những điều này không xảy ra trongchủ đề hạt nhân như một quy tắc, btw) nhưng sự khác biệt sẽ là một vài phần trăm thông lượng, không phải là loại yếu tố số nguyên được ngụ ý trong các tuyên bố hiệu suất thường được ngụ ý cho Node.

Dù sao, xin lỗi vì tất cả đều dài và rầm rộ, nhưng tôi thực sự cảm thấy rằng cho đến nay, cuộc thảo luận đã không chứng minh được điều gì, và tôi sẽ rất vui khi được nghe từ ai đó trong một trong những tình huống sau:

a) một lời giải thích thực sự về lý do tại sao Node nên tốt hơn (ngoài hai kịch bản tôi đã nêu ở trên, trong đó kịch bản đầu tiên (điều chỉnh kém) tôi tin là lời giải thích thực sự cho tất cả các thử nghiệm tôi đã thấy cho đến nay. ], thực sự, tôi càng nghĩ về nó, tôi càng băn khoăn liệu bộ nhớ được sử dụng bởi số lượng lớn ngăn xếp có thể có ý nghĩa ở đây hay không. Kích thước ngăn xếp mặc định cho các luồng hiện đại có xu hướng khá lớn, nhưng bộ nhớ được phân bổ bởi hệ thống sự kiện dựa trên đóng cửa sẽ chỉ là những gì cần thiết)

b) một điểm chuẩn thực sự mang lại cơ hội công bằng cho máy chủ được lựa chọn. Ít nhất là như vậy, tôi phải ngừng tin rằng các tuyên bố về cơ bản là sai;> ([sửa] có lẽ mạnh hơn tôi dự định, nhưng tôi cảm thấy rằng những lời giải thích được đưa ra cho lợi ích hiệu suất là không đầy đủ nhất, và điểm chuẩn hiển thị là không hợp lý).

Chúc mừng, Toby

Điều tôi không hiểu là điểm mà Node.js vẫn đang sử dụng các luồng.

Ryan sử dụng các luồng cho các phần đang chặn (Hầu hết các node.js sử dụng IO không chặn) vì một số phần khó có thể viết không chặn. Nhưng tôi tin rằng Ryan mong muốn là có mọi thứ không bị chặn. Mở trượt 63 (thiết kế nội bộ) mà bạn nhìn thấy Ryan sử dụng libev (thư viện mà tóm tắt thông báo sự kiện không đồng bộ) cho non-blocking eventloop . Do node.js vòng lặp sự kiện cần các luồng nhỏ hơn làm giảm chuyển đổi ngữ cảnh, tiêu thụ bộ nhớ, v.v.

Chủ đề chỉ được sử dụng để đối phó với các chức năng không có cơ sở không đồng bộ, như stat().

Các stat()chức năng luôn được ngăn chặn, vì vậy Node.js nhu cầu sử dụng một thread để thực hiện các cuộc gọi thực tế mà không ngăn chặn các chủ đề chính (vòng lặp sự kiện). Có khả năng, sẽ không có luồng nào từ nhóm luồng sẽ được sử dụng nếu bạn không cần gọi các loại hàm đó.

Tôi không biết gì về hoạt động bên trong của node.js, nhưng tôi có thể thấy cách sử dụng vòng lặp sự kiện có thể vượt trội hơn so với xử lý I / O theo luồng. Hãy tưởng tượng một yêu cầu đĩa, đưa cho tôi staticFile.x, thực hiện 100 yêu cầu cho tệp đó. Mỗi yêu cầu thường chiếm một luồng truy xuất tệp đó, đó là 100 luồng.

Bây giờ hãy tưởng tượng yêu cầu đầu tiên tạo một luồng trở thành đối tượng nhà xuất bản, tất cả 99 yêu cầu khác trước tiên hãy xem nếu có đối tượng nhà xuất bản cho staticFile.x, nếu vậy, hãy lắng nghe nó trong khi nó hoạt động, nếu không thì bắt đầu một luồng mới và do đó đối tượng nhà xuất bản mới.

Khi một luồng duy nhất được thực hiện, nó sẽ chuyển staticFile.x cho tất cả 100 người nghe và tự hủy, vì vậy yêu cầu tiếp theo sẽ tạo ra một đối tượng nhà xuất bản và luồng mới.

Vì vậy, đó là 100 luồng so với 1 luồng trong ví dụ trên, nhưng cũng có 1 tra cứu đĩa thay vì 100 lần tra cứu đĩa, mức tăng có thể khá bất thường. Ryan là một chàng trai thông minh!

Một cách khác để xem xét là một trong những ví dụ của anh ấy khi bắt đầu bộ phim. Thay vì:

pseudo code:
result = query('select * from ...');

Một lần nữa, 100 truy vấn riêng biệt đến cơ sở dữ liệu so với ...:

pseudo code:
query('select * from ...', function(result){
    // do stuff with result
});

Nếu một truy vấn đã được thực hiện, các truy vấn bằng nhau khác sẽ chỉ đơn giản là nhảy vào băng thông, do đó bạn có thể có 100 truy vấn trong một vòng cơ sở dữ liệu.